Comparative simulation of two beams producing nonsense result, or failing to simulate

simulation - “corner fillet test”

I am trying to do something very simple - compare the simulation of an accurately modelled square steel tube with corner radii against a simplified model with perfectly square corners. I have included in the model two cubes at one end of each beam for the purpose of applying loads.
Depending on how I set up the simulation, i either get incorrect results, or the the simulation fails to run.

When the simulation runs, there is either a single connection definition with both beams and loads, or no connection definition, and the loads are constrained.
When the simulation fails, there have been two separate contact definitions for each load and beam.

The results show that there is stress at the corner points between the simplified beam and the load block, even though they are supposed to be separate. It appears as though the meshing operation has stitched the two objects together, which presumably is causing the error when I attempt to define a connection, because it is already connected.

Why are these separate geometries connected?
How do I fix it?


Hi @curator23,

can you elaborate the problems you had and what results you would expect for this type of simulation? I have a slight idea of what you want to do but I am not completely sure :slight_smile:

First thing that came into my mind was the Fictitious Clearance option where you can artificially close or open a gap depending on the value you give it (explained by @rszoeke in this post: Fictitious Clearance)

The problem I have is finding the right model since you have 9 models or so.

Hope I can help you there!



Hi, thanks for your speedy response.
The base geometry is “corner_fillet_error_test”
I’ve meshed it twice with slightly different options, both are called “corner_fillet_error_test mesh”
This is a static analysis with (or without, for no load) simple contacts. No over- or under-lapping of geometry.
I’m expecting to see very similar stresses in each of the two beam profiles, but with greater stress in the corners of the perfectly square beam.
In the first simulation run (“self load”) this is more or less what happens, except that the perfectly square beam is stressed where the corners of the load block meet with it. As the load block and the beam are separate geometries, I was expecting there to be no interaction until I created contact definition between them. When I do create a contact, the simulation fails.
Compare to the beam with the rounded corners where there is no contact until it is defined.

Now, I suppose I could work around this by defining only the contact for the rounded beam. But I’d like to know if this automatic contact is correct and expected behaviour, or erroneous? If it is correct, how do I specify that they are separate?
For instance, in the future if I have a similar model where I would like a Physical Contact, this would not be possible because the two geometries are already joined.

I hope that clears things up.
Thanks again.


Hi @curator23,

this always depends on which contact you are using.

• Penalty-contact implies penetration of the contact \rightarrow increasing the penalty coeff. will decrease penetration

• Augmented Lagrange contact “augments” the contact force calculation with a variable \lambda that makes the method less sensitive to the contact stiffness

Both have pros and cons:


  1. Good convergence behaviour
  2. Useful for any type of contact behaviour

Hint: Penalty coeff. should be ~5-50 times as high as the materials Young’s Modulus

Augmented Lagrange:

  1. Bad convergence (especially when friction is activated)
  2. No contact penetration
  3. Contact detection at integration points

Then there is also a tool that you can use in your contact definition called fictitious clearance.

Explanation by @rszoeke:

When adding a Fictitious Clearance to a contact surface, we add a layer of a fictitious material (with no additional stiffness) with the defined clearance as thickness. On an algorithmic point of view, when it comes down to compute the (signed) contact distance, the solver removes from the actual geometrical distance the fictitious clearance and the result will be used to evaluate the contact state (open/closed) and the contact forces.

So, if your geometry originally has a gap of 2mm and you apply a fictitious clearance of 1mm, the solver would compute a remaining gap of 1mm. After moving one part for 1mm the contact will become active and contact forces will start acting. Using an exact contact algorithm (Lagrangian), the gap will never be smaller than 1mm.

Furthermore you used bonded contact which is the default option for contact.

@afischer described the function of this option:

The solver does not test on contact faces or even interpenetration except if you define physical contacts for those face pairs. If you define a bonded contact, the nodes of the slave surface that should be bonded to the master surface are calculated via a maximum distance (taking the master face element normal into account).
You can define this distance manually by setting the positional tolerance value for the bonded contact

You can play with those options and see what impact they have on your simulation.

This might be a good example to see how @ahmedhussain18 set a tolerance value for a bonded contact:

If you need more help or encounter any problems, feel free to ask.


Global contact setting

Hello @curator23,
thanks for reporting this! You are right, there was a problem in the mesher which caused in your case a merge of certain nodes (2x2 nodes) of the mesh.

We investigated the bug and it it was fixed a few minutes ago.

For the fix to take effect in your mesh you need to restart the meshing operation.

If you don’t want to waste your time restarting the mesh and running the simulation again, you can copy my project where I already updated the mesh and sim:

As a side note: if you want do do serious static simulations, you should use the static analysis - advanced, it has much more constraint and load types and better contact controls.

Best regards,



is the meshing log explicitly giving information if illegal merges occur?


No, merging of nodes from different solids should never happen.
It was only possible to happen in rare cases because of a regression introduced 2 days ago.
It is fixed and we added a test so it won’t happen again.



Super, thank you very much.