Have 3 calculation:
- scilab - differential equation;
- ccx with *modal dynamic
- ccx with *dynamic
1 and 2 are ok, *dynamic is not correct. Why it cab be?
One important difference is that you have NLGEOM for *DYNAMIC while *MODAL DYNAMIC is always fully linear. Then in *DYNAMIC you can control the amount of numerical damping with the ALPHA parameter (default is -0.05).
this is 1 D.O.F. system, the task is completely elementary (harmonic loading of mass point). So, why it is weird is not clear. For other loadings it looks ok.
For some reason example with *mass is not working as well
when I am reducing the load, result is similar.
But is kinda strange thing. One degree of freedom means that the mass can’t turn left or right. Newton’s law stay the same during motion.
It means that the motion is under bifurcation and *dynamic card is catching something else. Never saw it before.
*CLOAD,AMPLITUDE=StartAndStop
3,1,0.1
What about *MASS card? Is it working now for all methods?
** based on example spring1.inp
*NODE,NSET=NALL
1,0.,0.,0.
2,1.,0.,0.
*ELEMENT,TYPE=SPRINGA,ELSET=ESpring
1,1,2
*ELEMENT,TYPE=MASS,ELSET=Emass
2,2
*BOUNDARY
1,1,3,0
2,2,3,0
*DAMPING,STRUCTURAL=0
*SPRING,ELSET=Espring
10659.
*Mass, Elset=Emass
120
** amplitude, generated from spreadsheet
*INCLUDE, INPUT=graph.ods.inp
*step, nlgeom, inc=100000000
*dynamic
0.001,10.2,1.0E-08,2.0E-03
*CLOAD,AMPLITUDE=StartAndStop
2,1,1000
**Displacements
*node file
u
*endstep
hm, If that comes from spring behavior, it makes this element very unsafe for real modelling. What if there are many springs at the complex model? Results are completely unpredictable and what is worse than that, they look like real. Not a huge excuse that Abaqus may have the same math issue, as it mentioned in discussion. But from the point of developing, it can be ok to have this, since it is common and described at help manual.
Did you take into account this warning?
> *WARNING: 1-D or 2-D elements may cause problems in modal dynamic calculations
> ensure that point loads defined in a *MODAL DYNAMIC step
> and applied to nodes belonging to 1-D or 2-D elements have been
> applied to the same nodes in the preceding FREQUENCY step with
> magnitude zero; look at example shellf.inp for a guideline.
Changing the node coordinates from 1 to 3 delay the spring snap.
** based on example spring1.inp
*NODE,NSET=NALL
1,0.,0.,0.
2,3.,0.,0.
3,4.,0,0
It happens exactly when the amplitude in the compressive displacements exceeds 3.
I would say it’s the problem I have pointed.
It also makes sense that decreasing the load removes the problem. Amplitude is smaller and do not reach the snap point.
it is explained in the github link you provided
Simulation with real mass elements fails because the eigenvalue solver can’t handle small systems.
there is apost in the forum regarding this issue.
I think Calc_em is right, did you check the eigenfrequencies of the beam? and if you are creating large strains in the beam then the system is no longer linear…in Kraska example is stated
the masses are represented by beam elements which are rigidized by an equation linking their nodes.
that makes the system linear again probably.
I plotted the input load (StartAndStop) but not sure about the units so didn’t checked the resulting strains
Worth clarifying that changing sides as @Disla explained isn’t a bug but a natural consequence of the idealized spring element allowing compression beyond 100% and having its direction determined by its node positions. The closest physical analogy I can think of is this where the cart can snap over to the other side by rotating the spring ~180 degrees.
I guess the SPRING2 element wouldn’t do this because you define the direction in the input.
By the way, it solves much faster if you redirect the output to a file instead of letting it display in the console. I got 99 s with a file and 500 s without, probably because it has such as huge volume of messages.
1 Like
