Yes I did. That was my first step in doing dynamic mesh with rigid body motion. I am using same method for plastic deformation using file "plasticStrainVsYieldStress".

So I made this change:

1. Made "floor" patch as master instead "falling_obj". Previously it was other way around with rigidMaster set to no.
2. Added relaxation for DD equation as well.
3. Added alternativeTolerance and materialTolerance to constant/solidProperties
4. I am using infoFrequency as 1, to see how the convergence of res and relRes is going


Still the issue was there, only the relRes is going down, res remains 1 and after a few timesteps relRes diverges in around 150-200 correctors. I have given a high value for correctors to check whether it comes down at some point.




From the previous example I did, the falling_obj started from rest and moved with effect of gravity only. Now from the impactBar case I used setFields and gave some velocity. Now it runs perfectly fine, atleast it came beyond the point it had crashed before and the mesh also moves.







Thanks for your help.

Another query.. How to select a proper time step for solids only simulation?

When using an implicit solid solver, then temporal accuracy is the main concern.

A quick check is to re-run your simulation where you double or half (or do both and run two extra simulations) and see if your results change much.
If you want to perform a more formal check, then you can use the Grid Convergence Index (GCI) method (Roache 1996) using the results from three time-step sizes to estimate the time-step independent solution.

Hi Phillip, thanks for your response.


My concern was the simulation crashes within a few or few hundred timesteps if I use a lower one. The run is not stable and I have tried varying DD relaxation. The mesh is clean with few non-ortho cells, other than that it passed all mesh checks. All are tet cells generated using Salome meshing.

Also is there is ordering syntax to follow when having a multi contact body in solidContact BC?

The solidContact boundary condition uses a node-to-segment type of approach, where it calculates the distance between the "slave" vertices (so called nodes) and "master" faces (so called segments).
As a result, if you switch the master and slave definitions, you may end up with a slightly different solution; however, this difference should dissapear as the mesh is refined.

In terms of deciding which patch should be the slave, you can use trial-and-error to find which works best, or, if one patch has a finer mesh then that tends to be a good choice for the slave (as the algorithm uses the slave vertices).

I am closing this behemoth of a thread.

If you would like to reply to one of the posts above, please send me a private message with a link to the post and I will move that post to its own new thread. You will then be able to reply to the post there.