This example shows a rudimentary script for the simulation of contact. It can definitely be enhanced and we are open to specific improvements.

Here, we're using a beam that is clamped on one side. The beam is largely rigid, but near the clamping, it is flexible. The flexible part acts like a hinge. We're using an actuation force of 1 N in x-direction on node 3. Without any contact, the tip of the beam would displace 0.0311 m.

We're imagining a line at x=0.025, representing a contact surface that cannot be crossed. To simulate this, we're creating a custom force on the node of contact (node number 4), whenever it crosses the position of x=0.025. We choose the value of this force to be -stiffn*(pos-x0). This creates a fictitious force that acts like a spring with stiffness stiffn and reference position of x0=0.025. Variable pos is the current value of the suspected node of contact.

This simulation is tricky because it involves iterations to get the system in the right state. We currently have no clear rationale for picking the values of stiffn of the fictitious force (or the precise form of this force, for that matter). Also, it's best to do these iterations within one single Spacar call, seeing as each new SPACAR Light call will make the system start from the undeformed configuration again. The current interface for doing a custom force within Spacar is by means of the usersig interface. This interface hasn't been implemented in SPACAR Light properly, but here are some pointers to get a simulation up and running.

• Get the development version of SPACAR Light that supports the opt.customdyn field
• Use opt.customdyn = 'usersig PUSHSIG' to have Spacar call the m-file PUSHSIG.m (all of this is case-sensitive)
• This m-file will be called repeatedly, depending on the number of opt.loadsteps. This file contains a function with very specific input and output requirements. Within this function, you'll have available the x-vector, which contains the current positions of the nodes. Unfortunately, the node numbering in Spacar (full) is different from SPACAR Light. This is actually by design, and something you usually shouldn't have to come across. Here, you do, though. The conversion is simple and detailed in the file. Note that this simple conversion may not work whenever you use multiple elements per beam with eprops(i).nbeams > 1. (The .dat-file actually shows you what the conversion should be.)
• debug
• loadsteps ignored if no force