Tackling time step problem
Hello everyone,
i had a question about time steps and i'm having some difficulties in tackling that problem. I'm running a simulation with a duration of 0.2s and i have checked the time steps for the different type of elements on Hyperworks. It is as follows:
Shells: 3.17e-16
Springs: 1.581e-6
The output of the simulation is either RUN KILLED: ENERFY ERROR LIMIT REACHED or RUN KILLED: TOTAL MASS ERROR. I've attached a screenshot of my output file to understand it better. I am not really understanding the message actually. Does it mean that interface ID 17 is causing a problem?
Interface 17 is a type 7 self contact and i've tried everything i know to prevent that failure. there are also no penetration when i checked. I tried increasing the gaps, increase/decreasing the stiffness as well but nothing seems to be working.
I tried using different methods for time steps (SHELL, NODA, INTER) but with Shell and Inter, i'm having a really large simulation time. The only thing that's running the simulation is DT/NODA/CST/0 with a timestep of 5e-7.
What i saw on the forum is, that DT/NODA/CST/0 adds masses to the nodes in order to keep a stable time step but hence leads to a mass error and energy error. how is it possible to control the mass being added, for it not to be too big?
It will be really helpful to me, if you could help me with that problem.
Thank you very much,
Umehr
Answers
-
Few things here! If you share your model I can give more specific insight but in general:
If you use /DT/NODA/CST to add mass for the stable timestep, there isn't really a way to 'control' how much mass is added is to the run during the run (except for specifying a lower timestep). You can stop and resubmit restart without cst and it will be fixed at the level you had.
In your image, you can see added mass is at 52% at t0 (already very high) and increases to 43000% by cycle 500, where it stays until the model blows up.
That is a lot (too much!) of added mass for a small timestep, do you have any tiny elements? you say e-16 for shells in your introduction? Is that a typo? If not, you have a sliver or something. The 0000.out lists your timesteps at model initiation.
It is the interface that controls the timestep eventually, but sometimes this is symptom rather than cause (e.g. an element blew up and shot through the interface)
What do you see at the final animation file written after the model stops?
0 -
Hi Paul, thank you for your reply.
the time step for the shell being e-16 was not a typo because i've got a dummy with density of approx e-29 t/mm3 (also void material) hence the time step being so small. But this problem was actually solved
i had another question regarding units in my model.. So i've read that Radioss does not actually consider units being used hence the number being input must be coherent! I'm actually using a Ton, mm, s unit system and would really like to know, if the value input in Inivel/Impvel must also be in 'mm/s'.
I've searched through a whole lot of radioss examples but they are all using kg,m,s as units...
I would really appreciate it if you can help me here!
Thanks,
Umehr0 -
Umehr Beebeejaun said:
Hi Paul, thank you for your reply.
the time step for the shell being e-16 was not a typo because i've got a dummy with density of approx e-29 t/mm3 (also void material) hence the time step being so small. But this problem was actually solved
i had another question regarding units in my model.. So i've read that Radioss does not actually consider units being used hence the number being input must be coherent! I'm actually using a Ton, mm, s unit system and would really like to know, if the value input in Inivel/Impvel must also be in 'mm/s'.
I've searched through a whole lot of radioss examples but they are all using kg,m,s as units...
I would really appreciate it if you can help me here!
Thanks,
UmehrYes, if you are using T, mm, s, then velocity should be in mm/s (because the units should be consistent). But you can define a different units systems for imposed cards if you want and use another system for them if you prefer (will be scaled vs units defined for model)
see also: units consistency in help
0