Sudden strong vibrations like hourglassing after some sim time
Hello everyone,
I have a question concerning shell behaviour, more specifically a phenomenon that seems to be hourglassing after a certain simulation duration. I am working with some car crash models from the CCSA and NHTSA sites, modifying them for experiments etc. I noticed that, after some simulation time, the shell elements start to violently vibrate in what looks like hourglassing modes, but this occurs even with fully integrated QBAT shells, all throughout the model and in regions with almost no loads. Below are comparisons of a model with said phenomenon, not even 2ms apart. This specific one includes a blast load, but others in a pure crash situation also start to show this at some point.
The shell properties are all identical apart from the thickness, i.e. P1 shell, Ishell: 12 QBAT formulation, Ismstr: 4 full geometric nonlinearities,, Ish3n: 2 standard triangle, Dm: 0.05, Dn: 0.05, N: 3, Istrain: 1, Ithick: 1, Iplas, 1. The material models are either Law 2, Law 36 or Law 1. I tried QBAT and QEPH elements, different damping factors and Ismstr settings to no avail.
I'd be very greatful if someone could shed some light on this. Is this actually hourglassing and if so, why does it occur with fully integrated elements? The energy plots show no increase in hourglass energy, but a strong, sudden increase in kinetic and external forces work increase. How can it be remedied? Also, is there a way to delete elements that exceed a certain mass change threshold? I'm aware there's the option to delete elements falling below a set time step, but that does not seem to do the trick in certain contact scenarios.
Best Answer
-
Yes exactly that, it even states it in the help:
0
Altair EmployeeAnswers
-
Are you sure it is happening at all?, it may be just graphical?, you have compressed h3d there, I would look at uncompressed h3d or Anim (Annn) files and see what you have there, I have seen this artefacting in compressed h3d before, while 0.01% seems 'not a lot' it is likely too much. The energy plot looks very low frequency output, and may not be unreasonable for a blast load?
0 -
Paul Sharp_21301 said:
Are you sure it is happening at all?, it may be just graphical?, you have compressed h3d there, I would look at uncompressed h3d or Anim (Annn) files and see what you have there, I have seen this artefacting in compressed h3d before, while 0.01% seems 'not a lot' it is likely too much. The energy plot looks very low frequency output, and may not be unreasonable for a blast load?
Hi Paul, good point about it being a graphical issue. Seeing that it occurred in different models which included a 0.01% compression. There are no animation files written to save on disk space, only H3D. The TFILE frequency was indeed too low for this setup, I'll rerun it and see what happens without compression.
I've checked a crash model with the same behaviour using QEPH elements. This also started the same buckling/hourglassing phenomenon all throughout the model after some simulation time, however it's also combined with the corresponding stresses. This would mean that it's not only graphical, wouldn't it?
0 -
Ingeniorator said:
Hi Paul, good point about it being a graphical issue. Seeing that it occurred in different models which included a 0.01% compression. There are no animation files written to save on disk space, only H3D. The TFILE frequency was indeed too low for this setup, I'll rerun it and see what happens without compression.
I've checked a crash model with the same behaviour using QEPH elements. This also started the same buckling/hourglassing phenomenon all throughout the model after some simulation time, however it's also combined with the corresponding stresses. This would mean that it's not only graphical, wouldn't it?
I think it is just the same issue, the stress doesn't look to correspond to the weird deformation, as a rule you should consider 0.001% as a maximum for the /H3D/COMPRESS
If storage disk space is critical, but you can spare it temporarily, you can generate an uncompressed h3d or anim files originally instead, then you can create a compressed h3d using HvTrans after the job has run (also removing steps, and result types if not relevant), check it is ok and then delete your original files, this way you aren't wasting time running a model generating unusable animation output.
0 -
Paul Sharp_21301 said:
I think it is just the same issue, the stress doesn't look to correspond to the weird deformation, as a rule you should consider 0.001% as a maximum for the /H3D/COMPRESS
If storage disk space is critical, but you can spare it temporarily, you can generate an uncompressed h3d or anim files originally instead, then you can create a compressed h3d using HvTrans after the job has run (also removing steps, and result types if not relevant), check it is ok and then delete your original files, this way you aren't wasting time running a model generating unusable animation output.
Okay, I'll keep that in mind. I thought having seen 0.01% as default recommended compression rate, maybe I'll just remove it altogether. Maybe the compression error accumulates over time and causes these odd results.
0 -
Yes exactly that, it even states it in the help:
0 -
Paul Sharp_21301 said:
Yes exactly that, it even states it in the help:
Oh it really is 0.001% after all, then that's surely the root cause. Thanks for digging through that!
0 -
Paul Sharp_21301 said:
I think it is just the same issue, the stress doesn't look to correspond to the weird deformation, as a rule you should consider 0.001% as a maximum for the /H3D/COMPRESS
If storage disk space is critical, but you can spare it temporarily, you can generate an uncompressed h3d or anim files originally instead, then you can create a compressed h3d using HvTrans after the job has run (also removing steps, and result types if not relevant), check it is ok and then delete your original files, this way you aren't wasting time running a model generating unusable animation output.
Rerunning it without H3D compression seems to do the trick, at the same time step no odd buckling can be seen. Thanks again!
0