Surface spring : can not reproduce a case previuosly succeed

[Matej]

The surface spring feature had a bug while using parabolic hexa elements. The reason was that I limited the stiffness values to positive values. But, for a parabolic hexa element the uniform load applied to one of its faces translates to nodal loads in such way that the loads in the main nodes are negative (-1/12) while the loads in the midside nodes are positive (4/12). And for the surface spring the nodal spring weights are computes from these ratios. Now I allowed a negative spring stiffness, and I am able to get a nice uniform stress field under load.

Compression-only support was added mostly with rigid connection in mind. So, I did not scale the nodal gap stiffness values according to the nodal weights. The stiffness is equal for all nodes. Only the spring direction is considered. I can now add these nodal weights to the gap elements, but I cannot imagine if they would work for negative stiffness values. Probably the sign of the load at infinity should alco change if the sign of the stiffness changes?

[synt]

@Matej

The surface spring feature had a bug while using parabolic hexa elements

thanks for the hints and adjustment at mid side nodes, hopefully the source of problem in pressure/length (N/mm3) can be found also.

@Matej

I can now add these nodal weights to the gap elements, but I cannot imagine if they would work for negative stiffness values.

this is a problem also in CalculiX at node to surface contact analysis, midside node value is set to small value or it can be set to zero as in Abaqus.

@Matej

Probably the sign of the load at infinity should alco change if the sign of the stiffness changes?

Gap element using linear pressure-overclosure as shown in graph below (change pressure to force). At tension force is in limited fashion, make it different with compression.

*edited
sorry, maybe i misunderstand. Did it mean the sign of spring stiffness at input value can be changed from negative to positive to switch the behavior? interesting, did not know before.

[Matej]

Yes, the sign of the stiffness. For the hex elements to work with surface springs, the stiffness of the spring attached to the main nodes must be negative (very strange imagining such a spring in real life). So, I was wondering what happens if I use gap elements. It seems the stiffness of gap elements would also need to be inverted. And that would mean that the diagram you pasted should be inverted in the negative y direction. So, maybe inverting the stiffness and force values in the gap section definition would also invert the diagram.

[synt]

i’m only do quick test for review: add minus sign in gap and spring element stiffness, load direction also reversed for compatibility. Did not further check result correctness, but the behavior of both model are similar except in the edge ends due to uplift.

Surface spring case,

Compression only,

[synt]

i still trying to understand gap element in CalculiX, probably it’s not truly contact element. When i left the sign in positive, but the load direction is uplift, theoretically all gap element spring force are zero since there’s no compression occurs. CalculiX solver does not work like these, it seems the gap element direction is auto reversed.

*edited
modeling pressure and uplift force in a single file, result shown identical.

[Matej]

I think I solved the problem with the springs and implemented the same force division for gap elements.

The result of the scaled stiffness of gap elements for the stress field looks like this:

The problem is that I checked the stress in the integration points, which is the same for all surface elements in all integration points. So, I think the color (value) change comes from averaging stress values in the nodes attached to the gap elements.

I don’t think this averaging can be turned off, but @mkraska proposed a solution for that where the nodes are duplicated, and *Equation is used to connect them.

I tried implementing it and got the following result: a constant stress field. How is it implemented? First, a node (A) where the compression only constraint is defined is coped two times (B, C). Between nodes B and C the gap element is created in the precomputed direction. Then node B is connected to node A using *Equation.

The question is if this approach is appropriate in most cases. Does the *Equation keyword and duplicating the nodes introduce any unwanted behavior when using other types of constraints, MPCs,…

[mkraska]

I think the separation approach is quite robust. Did you limit it to the surface nodes? That would be really smart because otherwise the frd files get blown up. No changes, however, are introduced to the global system of equations, because the dofs of the copied nodes are eliminated by the equations. No pre-existing dof ever is on the dependent side of such an equation, therefore I’d bet that there can’t be any overconstraints which aren’t there without separation.

I’d also recommend to introduce this approach at material or element set boundaries, because averaging across a material boundary usually is inappropriate. Just think of the bending stress in a sandwich structure.

[synt]

@Matej

I think I solved the problem with the springs and implemented the same force division for gap elements.

will be simple and powerful of advanced features, so many thanks.

in addition to discussion: currently, gap element is connected directly to node of element, so it makes uneven in plot results. Required separation nodes and connecting them by *Equation to avoid averaging,

below sketch of examples problem, i add some distance or length for clarity in presentation only.

gap direction is already computed and known, so it’s a translation dof’s need to be transmited.

*Element, Type=GAPUNI
1, 2, 3
...
*Gap, Elset=Compression_Only
0, 0, 0, 1, 11250, 0.001

to connecting of nodes 1 and 2 in Z translation,

*Equation
2
1, 3, 1, 2, 3, -1

as i know, general constraint using equation is work normally as continues of mesh element sharing the same nodes, but i did not test further with another constraint e.g rigid body.

*edited
sorry, maybe i miss reading carefully. Latest figures and description shown *Equation is already tested but still shown uneven in result. It’s need me to investigate further.

[synt]

it seems, using separated nodes and connecting by constraint was eliminated stress averaging, below sample problem from CaculiX forums.

[Matej]

@mkraska

Did you limit it to the surface nodes?

Yes, only the nodes selected for the constraint are duplicated.

@mkraska

I’d also recommend to introduce this approach at material or element set boundaries, because averaging across a material boundary usually is inappropriate. Just think of the bending stress in a sandwich structure.

I was thinking of this case, but I have to figure out what will happen if a single node would have to be duplicated due to the material boundary and compression-only support.

@synt

Latest figures and description shown *Equation is already tested but still shown uneven in result.

Actually, the result is the same as for the spring elements. The difference in the stress field is very small and can only be detected on the 5th significant digit.

[Matej]

I have released a new developer version for testing.

[ANYS]

I was waiting for it.

Solid elements

[ANYS]

I know shells are not supported but I tried the shell model and it is failing.
I feel this new dev kind of laggy. ?¿?. Is it just me?¿?

[synt]

it seems Compressio Only by stiffness overrides is working normally, result shown as expected and reasonable. Individual spring stiffness was properly calculated based on tributary areas and total spring stiffness. Maybe some note is required to clarify at implementation in PrePoMax, it used total spring stiffness and force instead of individual as manual documented of CalculiX input definition.

However, it seems surface spring with option stiffness per area (N/mm3) still have a problem in precalculated value of individual spring stiffness. This value should be the same in numbers as Gap element in Compression Only and Surface Spring with total stiffness options (N/mm).

*edited
seems the value of all individual spring has been multiplied by factor of 300, shown consistently in this case.

[synt]

probably these problems in calculations of individual springs are specific to shell element models only. It seems has properly defined in case of solid element models.

[synt]

another test on Compression Only which known working properly, result as expected and reasonable.

Shell quadratic element

Non Layered,

Layered (Composite)

[synt]

another test on Compression Only which known working properly, result shown as expected and reasonable. Unexpected result can occur when some edge is restrained at inplane movement, i.e not the same behavior as Surface spring. Probably, this is due to overconstraint since DOF’s in *Equation has been applied to all translation, i.e not only in gap direction.

Solid element linear (C3D8)

Solid element quadratic (C3D20R)

problem in overconstraint,

result without edge node restrained at inplane movement,

but, there’s workaround to solve the problem by add another restrained inplane movement in edge nodes of opposite side.

[synt]

@ANYS

I know shells are not supported but I tried the shell model and it is failing.

try in similar cases, i can not reproduce the problem.

[synt]

another test on Compression Only which known working properly. The model is fairly complex since *Rigid body is in used, layered (composite) shell also. Even its complexity, still all result shown as expected and reasonable.

Non layered

Layered (composite)

In my several tests, it seems all feature of Surface springs and Compression only are working well, result as expected and reasonable. Some problem still existed, a minor in overconstraint of Compression only feature (but can be ignored by additional restraint). Major problem is in model of Shell element, improperly calculated values of individual spring in Surface springs feature when Stiffness per area is active (Yes, N/mm3)

[Matej]

@synt

Surface springs feature when Stiffness per area is active (Yes, N/mm3)

Can you prepare a simple example where things don’t work?