Restart simulation and add contact

Hi,

I am trying to restart (continue) a CalculiX simulation after the first load step has completed. In this restarted simulation, I want to add a surface interaction (contact) between two surfaces. However, I am getting an error when running the restarted simulation

*ERROR reading *SURFACE: *SURFACE should be placed
        before all step definitions
 *ERROR reading *SURFACE INTERACTION:
        *SURFACE INTERACTION should be placed
        before all step definitions
 *ERROR reading *SURFACE BEHAVIOR:
        *SURFACE BEHAVIOR should be placed
        before all step definitions
 *ERROR reading *FRICTION:
        *FRICTION should be placed
        before all step definitions
 *ERROR reading *CONTACT PAIR: *CONTACT PAIR should
   be placed before all step definitions

This seems to imply that I should have already defined all my contact behaviors in my initial simulation. Unfortunately, I cannot do this because these simulations involve the inflation of a pillow, which starts in a completely flat state, with the upper and lower surfaces coplanar, which directly triggers the contact algorithm and ends up blowing the simulation.

Is there a way to restart a simulation and add a contact definition in the calculix_restart.inp file? Alternatively, can I switch off the contact computation for the n-second of the initial simulation?

Note: I am able to carry out the simulation fine without the contact definition, so I suspect my input files and methodology are correct, except for the contact definition.

Thanks a lot in advance,

Marin


For your reference, my caluclix.inp file looks something like this (I removed a lot of stuff obviously)

**
** calculix initial inflation
**
*INCLUDE, INPUT=geom.inp

*STEP, NLGEOM, INC=1000000
*DYNAMIC
...
*RESTART,WRITE,FREQUENCY=1,OVERLAY
...
*END STEP

and the restart_calculix.inp looks like this

**
** Restart file after initial inflation
**
*RESTART,READ

*SURFACE INTERACTION,NAME=IN1
*SURFACE BEHAVIOR,PRESSURE-OVERCLOSURE=LINEAR
 3000000, 3000, 1e-3
*FRICTION
 1, 1000000

*SURFACE,NAME=SURF_2,TYPE=ELEMENT
 SRF_2,SNEG
*SURFACE,NAME=SURF_7,TYPE=ELEMENT
 SRF_7,SNEG

*CONTACT PAIR,INTERACTION=IN1,TYPE=SURFACE TO SURFACE
 SURF_2,SURF_7

*STEP, NLGEOM, INC=100
*DYNAMIC
 ...
*END STEP

Hi @Marin ,

I don’t think you are allowed to add new surfaces or contact interactions during a restart. One way to handle this would be to define those surfaces ahead of time and simply use a model change during the restart. This approach may be your best option.

Best of luck with your simulation!

@jbr,

Thank you for your reply; I will have a go at this.

Could you clarify what you mean by a model change during restart? If I understand your suggestion, I define all my surface interactions in the initial setup file, but the *SURFACE keyword contains empty element labels. I then populate those with the element IDs from the actual surface in the restart file?

There is a *MODEL CHANGE keyword that can be used to activate and deactivate elements and contact pairs:

*MODEL CHANGE, TYPE=CONTACT PAIR, ADD/REMOVE
slave_surface_name, master_surface_name

@Calc_em

That seems like a very handy keyword, indeed! I will keep you updated on the progress.

Thanks a lot for your help!

Marin

Hi @Marin ,

What you’ve described—using empty element labels for *SURFACE—is not the correct approach. Surfaces must have valid labels in the initial setup because the solver requires proper definitions for initialization.

Instead, the recommended approach is to define all potential surfaces and interactions in the initial setup file with valid and realistic definitions. During the restart, you can then use a model change to update or activate the specific surfaces or interactions as needed. This ensures that all definitions are complete from the outset and avoids issues with undefined or invalid surfaces.

Let me know if you’d like further clarification on implementing a model change or setting up your surface definitions.

@jbr
Thanks, I think I understand now; the answer from @Calc_em also helped a lot.

I am trying something like

*INCLUDE, INPUT=geom.inp

*SURFACE INTERACTION,NAME=IN1
*SURFACE BEHAVIOR,PRESSURE-OVERCLOSURE=LINEAR
 3000000, 3000, 1e-3
*FRICTION
 1, 1000000

*SURFACE,NAME=SURF_2,TYPE=ELEMENT
 SRF_2,SNEG
*SURFACE,NAME=SURF_7,TYPE=ELEMENT
 SRF_7,SPOSS

*CONTACT PAIR,INTERACTION=IN1,TYPE=SURFACE TO SURFACE
 SURF_2,SURF_7

** step, no contact
*STEP, NLGEOM, INC=1000000

*MODEL CHANGE,TYPE=CONTACT PAIR,REMOVE
 SURF_2,SURF_7

*DYNAMIC
 0.01, 10.0, 0.00005, 0.1
...
*END STEP

It seems to be doing what I expect. I will try add the contact for a 2nd step.

Marin

Well, actually, this is stalling,

I am getting very large numbers of iterations for every step, and the timestep reduces below the minimum time step, although all contact should be removed (which means it should run like the non-contact simulation) is seems that something is still done differently.

Is there a way to share your input file completely to take a look? Or even the portion of concern. I may have some time this weekend.

@jbr

Unfortunately, I cannot share the geometry itself. I will see if I can develop a MWE of my case if you want to check it.

Marin

1 Like

Hi,

Just an update. I made an MWE, and the contact switches off/on worked. My case is a bit more complex, but the main difference is that some nodes have prescribed displacements as boundary conditions via an amplitude card. This is what seems to mess up the contact switch off.

Best,

Marin

Another update, @Calc_em @jbr

I have managed to generate an MWE that has the same behavior as my real case.

The issue occurs only if surface interactions are added. Even when those are turned off. The issue seems to be between the contact definition and the inhomogeneous boundary conditions. Removing one or the other solves the issue. See the case file here: GitHub - marinlauber/Calculix-test.

The uploaded verion works as expected. If you switch on the contact by uncommenting lines 44-47 and 52-56, you get a completly different behaviour, the solver stalls (iter>50) and finally diverges.

I am using CalculiX Version 2.22 on Arch.

Best,

Marin

1 Like

From page 550 of the manual:

One- and two-dimensional elements which are expanded in CalculiX (such as plane stress
or shell elements) cannot be removed in the first step (to circumvent this
restriction a dummy first step doing nothing can be inserted)

Here is a possible fix:

** Do-nothing step per page 550 of the ccx manual:
*STEP
*STATIC, SOLVER=PARDISO
 1.0,1.0
*BOUNDARY, AMPLITUDE=A0
*INCLUDE, INPUT=BCs_EDGE_BOTTOM.nam
*INCLUDE, INPUT=BCs_EDGE_TOP.nam
*NODE FILE, OUTPUT=2D
 U
*EL FILE
 E, ME, S, ENER
*END STEP
**----

@jbr

Thanks for the quick reply.

I have tried the dummy step, but it makes no difference, I get the same behaviour as before.

What I fail to undertsand is that switching off all the inhomogeneous BC (in the step after this dummy step), really has an effect on obtaining the convergence, and the contact is deactivated/activated as expected like this, regardless of weather I perform a dummy step or not.

Best,

Marin

Hi again,

From some more tests, I am not sure what happens in this dummy step.
There are some iterations performed if I keep the contact defintion, although there are no loading or time-dependent BCs. If I remove the contact definition, the dummy step doesn’t iterate and goes on as expected.

It raised the following questions:

  1. Why is the dummy step iterating? I suppose this are due to contact calculation, but can we then really have a dummy step if my master-slave surfaces are touching at the start?
  2. Is there a limitation in using inhomogeneous BC (boundary with amplitude card) and contact in the same step?
  3. If an inhomogeneous BC is used in one particular step, should it also be set to an inhomogeneous value in all other steps (assuming the problem is anchored)?

Best,

Marin

ccx is establishing the contact with the expanded elements, that’s what is going on.

 Determining the structure of the matrix:
 Using up to 16 cpu(s) for setting up the structure of the matrix.
 number of equations
 8622
 number of nonzero lower triangular matrix elements
 181230

 increment 1 attempt 1
 increment size= 1.000000e+00

 iteration 1

 Number of contact spring elements=4116

 Determining the structure of the matrix:
 average force= 0.000356
 time avg. forc= 0.000356
 largest residual force= 0.000000 in node 886 and dof 3
 largest increment of disp= 8.538872e-05
 largest correction to disp= 8.538872e-05 in node 712 and dof 3

 no convergence

 iteration 2

 Number of contact spring elements=2104
......

It is iterating on the contact springs created for the contact pairs of the expanded elements. You need this dummy step as stated in the manual for the expansion of the 2D elements.

I don’t believe so. It may be just a limitation due to your 2D model, that you may need an extra step.

What system of units are you using?

I am using {cm, g, seconds}, but why is that relevant?

Okay, but then a dummy step will never solve my issue because it is precisely in the first step. I can try to offset slightly the surfaces that touch in this initial step so that the initial step is really not doing any contact.

Another idea: Is it possible to restart with a deformed geometry and initial condition and add the contact condition to that? This will mean that all my boundaries are homogeneous, and I don;t have this issue that the inhomogeneous BC will the sim.

Thanks a lot for your help,

Marin

Nothing, it’s just me.

ÂżIs your density, right? The densest metal I know is 22.6 g/cmÂł