True it works in this case, but the convergence behavior is very bad (1). Reducing the amplitude to 1e-6 makes it better (2), 1e-7 leads to error “too many cutbacks”. And for 2nd order hexaeder, i think it wouldn’t converge at all.
I really don’t want to complain, but for my understanding “compression only” should be a simpler/cheeper alternative to a contact analysis (of course at the cost of precision), but this seems not be the case for examples, where moment loads needs to be supported (this is just my experience after testing a few models so I can’t generalize it).
On the other hand, the default value of 1 000 000 000 000 N/mm seems to work good for expamles like shown in picture (3).
For comparison (4) with reduced stiffness of 10,000,000 N/mm.
I have obtained a perfect agreement between Compression Only and Surface Springs. You just need to apply enough uniform pressure to guarantee that both plates end up fully supported by the Springs.
Step 1. Evaluate maximum U3 (6.71mm). No uniform pressure now.
right for no uplift cases, “Surface spring” should be identical in results with “Compression only” feature. However, this is limited to simple case not in general, e.g fixed support at both end in models will greatly affect by membrane action of NLgeom in gap element.
Although some disadvantages in nonlinearity, still “Compression only” with gap element is advanced and powerful. Probably another implementation of “Compression only” with nonlinear spring element is needed in the future, as i remember Nlgeom is not mandatory i.e can be deactivated.
of course, it’s specific for case above, but not in general cases. Try to change the parameter of length, thickness, point load, spring stiffness. It should not the same in results of Nlgeom activated or not.
that’s can be another story i seek the possibilities, but it seems nonlinear spring element itself can be run without Nlgeom activated.
It works but linearizes the gap element stiffness to get a linear model. So, you basically have a linear spring instead of nonlinear one.
I tested adding a dummy contact into the problem, and then the gap elements worked in a nonlinear way without the Nlgeom.
Do you think I should automatically add such a dummy contact in the .inp file? Or something else that will trigger the nonlinear solution without the Nlgeom?
to eleminate improperly output result due to some reasons as i experiences before, it seems this predefined dummy contact should be automatically added when Nlgeom is deactivated in menus.
I actually just wanted to point out, as a tip for other users with convergence problems, that the easiest way is probably to start with a lower value and then gradually increase it, if you want to use this constraint as an alternative to hard (frictionless) contact. Of course this comes at the expense of accuracy, but with simplifications this can hardly be avoided.
large stiffness for these model only apply for symmetric condition, the problem in convergences probably due to over-constraint in bolt holes by infinity stiffness (zero displacement).
Here is another example for comparison.
The only difference between the models is that the upper model consists of two parts connected with tie contact while the lower one is just one part. Why does the upper model converge so much faster? The deformation results are exact identical (element type C3D10).
My understanding is that the largest nonlinearity for a gap element is at its zero length, where it changes the stiffness if stretched or compressed. So, the initial direction needs to be found - tension or compression. Then, when this is found, the convergence is much faster.
But I would imagine it depends on the problem. If it is possible to predict the tension region for the gap elements, removing such surfaces or parts of surfaces from the constraint is a very good idea. A lot of calculation goes into nothing there.
Here’s another interesting comparison. First, a contact calculation for reference (1).
What is striking is that separating the Compression only layer and connecting it with tie contact leads to a significant improvement in convergence with higher spring stiffness (3)>(2) - here this leads to stress peaks in the corner nodes.
If additional C3D15 are used instead of C3D20 for the first layer, the simulation even converges with the default value for spring stiffness (4)>(3).
This is incomprehensible to me, but in any case the problem cannot be explained by the boundary conditions only…
The GAP element is created in each node, so the number of gap elements changes when the element type changes. It seems from the figure that more elements were created using C3D15 elements.
When doing this , the linearization can’t be done around d=0. If so, the spring Stiffness is underestimated by exactly ½.
This is what is happening now when one uses Compression Only support without NLGEOM active. The support becomes like a Surface Stiffness where the springs in tension do not deactivate, and Stiffness is ½ the input value. Note first term becomes x/2 in the Taylor expansion.
I think the user should know what is going on with a warning. It will provide a better understanding and leave the final decision to him. If anyway he proceeds, maybe a fix on the K to 2K could minimize the aftermath (Also comunicate).
Thanks, I made further refinements to model (3) → (3b). In fact, this allows higher values for the spring stiffness with approximately the same convergence behavior.
In addition, I increased the element size of the C3D15 in model (4), halved the number of elements → (4b). Also here, the result converges with the standard value for the spring stiffness.
Now I noticed that for C3D15 elements there are no GAP symbols displayed in the PP for the corner nodes, for C3D20 they are shown. Either this is just a graphical error or a possible explanation for the behavior? This could also explain the peak stress at the corner nodes. If that is the case, wouldn’t it be better not to create GAP elements at the corner nodes for 2nd order elements - or better, to add a selection option for this in Prepomax?
it seems does not the same as Nastran, when Nlgeom deactivated results shown have stiff in support and probably similar to linear spring element. In contrast, CalculiX shown softening in support.
CalculiX does the linearization. PrePoMax does nothing of the sort. PrePoMax only prepares the gap elements. The user should be aware that gap elements are nonlinear by definition.
I would not like to open additional warning messages about the 1/2 stiffness or the need to turn on the nlgeom. This is an advanced support, and the user should be aware of how to use it. But we might have to write this into documentation (@FEAnalyst). So I think that the documentation should have the warning that without the nlgeom the compression-only support has 1/2 of the assigned stiffness and that the support acts at a surface spring support. And in order to get the intended behavior of the compression-only constraint one must use nlgeom.
There is a possibility of adding a dummy contact into the .inp file which could be activated by the user in the compression-only constraint editor.
