Springs from Compression to Tension

1

Hi,

I’m finding what looks like a bug. I would like if someone could confirm before posting on Github.
It may seem an strange situation but I think this could be involved in the convergence issues present in one of my pretension tests.
Springs passing from compression to tension show a nonlinear behavior that makes them to suddenly jump and end up at an incorrect position.

Spring in the example has:

K= 1 N/mm.
Initial length 1000mm.
Ramped compression force from 0 to 2000N
Expected elongation: 2000N/1N/mm=2000mm.
Expected final length 1000 mm = 1000N invested to compress 1000mm + 1000N invested to Stretch 1000mm (passing through a singular point with zero lenght)
Resulting final length = 3000mm

screenshot.99
screenshot.991614×861 76.8 KB

** Generated by Mecway 24
*NODE
1,0,0,0
2,0,0,-1
*ELEMENT,TYPE=SPRINGA
1,1,2
*ELSET,ELSET=Springs
1
*SPRING,ELSET=Springs

1.000000000000E+003
*BOUNDARY
1,1,,0
1,2,,0
1,3,,0
2,1,,0
2,2,,0
*AMPLITUDE,NAME=Az_2_1
0,0
0.5,1000
1,2000
*STEP,NLGEOM=YES,INC=100,AMPLITUDE=STEP
*STATIC,DIRECT,SOLVER=PARDISO
0.01,1,0,0
*CLOAD,AMPLITUDE=Az_2_1
2,3,1
*NODE FILE,GLOBAL=YES
U,RF
*EL FILE
S,NOE
*END STEP

A second situation is when the spring passes from compression to tension but now one of the nodes is offset such that the load is not colinear. Convergence in this situation directly fails.

screenshot.100
screenshot.1001612×871 73 KB

** Generated by Mecway 24
*NODE
1,0,0,0
2,0,0.1,-1
*ELEMENT,TYPE=SPRINGA
1,1,2
*ELSET,ELSET=Springs
1
*SPRING,ELSET=Springs

1.000000000000E+003
*BOUNDARY
1,1,,0
1,2,,0
1,3,,0
2,1,,0
2,2,,0
*AMPLITUDE,NAME=Az_2_1
0,0
0.5,1000
1,2000
*STEP,NLGEOM=YES,INC=100,AMPLITUDE=STEP
*STATIC,DIRECT,SOLVER=PARDISO
0.01,1,0,0
*CLOAD,AMPLITUDE=Az_2_1
2,3,1
*NODE FILE,GLOBAL=YES
U,RF
*EL FILE
S,NOE
*END STEP
2

The second one doesn’t converge in Abaqus either, throwing the “FIXED TIME INCREMENT IS TOO LARGE” error. Direct incrementation is risky.

3

That probably come from my different testing options.
The result with automatic fails with maximum time step and converges to the wrong value in automatic.

imagen
imagen1607×862 25.8 KB

** Generated by Mecway 24
*NODE
1,0,0,0
2,0,0.2,-1
*ELEMENT,TYPE=SPRINGA
1,1,2
*ELSET,ELSET=Springs
1
*SPRING,ELSET=Springs

1.000000000000E+003
*BOUNDARY
1,1,,0
1,2,,0
1,3,,0
2,1,,0
2,2,,0
*AMPLITUDE,NAME=Az_2_1
0,0
1,2000
*STEP,NLGEOM=YES,INC=110,AMPLITUDE=STEP
*STATIC,SOLVER=PARDISO
0.01,1,0,0.01
*CLOAD,AMPLITUDE=Az_2_1
2,3,1
*NODE FILE,GLOBAL=YES
U,RF
*EL FILE,OUTPUT=2D,SECTION FORCES
S,NOE
*END STEP
4

The new input reaches 27.5% in Abaqus and gives the displacement magnitude of 718 mm for this load level.

The first input results in (displacement magnitude [m]):

spring
spring1228×702 7.14 KB

From CalculiX User’s Manual:

Note that a spring under compression, if not properly restrained, may change its direction by 180°, leading to unexpected results.

5

ooooh. Of course. The spring rotates and it’s suddenly loaded. How to control that???. Springs doesn’t have rotational degrees of freedom right?
If pretension by force has anything to do internally with springs , that could be the reason why in some cases, it suddenly fails when tension (operational load) exceeds pretension load.

6

With a displacement control instead of a force control but I guess it’s not a satisfying solution in your case.

It shouldn’t. Pre-tension is internally handled by linear MPCs.

7

Then, maybe it’s is my compression only support.
I have to do more testing.

Thanks .

8

probably, this is similar to truss element. In stability purpose and eliminate spurious mode, it’s required rotational restraint in longitudinal axis (torsion) of element.

1 Like