Radioss: Engine trouble shooting
Altair EmployeeIntroduction
The original article is this,
This article explains how to determine the cause of an error when the engine _0001.rad fails to run to the end. This is my own method, and it is not the best or the only way to find the cause of the problem.
You can modify my methods and find your original better way.
Methods
A, run in double precision version (mandatory)
Precision and stability are closely related. Double-precision versions is more stable. Some models will run just with double precision version.
If you are unsure about double precision version, skip this method because you have already used double precision version.
B, Smaller time step or smaller time step factor
When time step is smaller and smaller to simulation critical time step, the run becomes more and more stable. Thus, keeping enough gap between time step and simulation critical time step is important.
When you are not using mass scaling (/DT/NODA/CST), add /DT to _0001.rad like this,
/DT 0.5 ########## 0.5 is a scale factor to simulation critical time step. the default is 0.9
When using /DT/NODA/CST, modify it like this,
/DT/NODA/CST 0.5 1e-7 #################### 1e-7 is just an example. This is your target time step #################### 0.5 is the scale factor. The default is 0.9
Many models will run just with this setting.
C, Check energy history for all parts, all materials and all properties
You can add /TH/PART to _0000.rad to output energy history for all parts,
While this is output request for parts, in HyperGraph, you can check not only energy history by part but also by material and by property.
If there is negative energy or non-reasonable huge jump, something wrong is there.
I recommend to add this always.
D, Watch the moment when things go wrong.
When a model fails, the analysis has been broken. We cannot find the cause. We need to watch the moment when the simulation turns to wrong direction.
1st, check _0001.out and find suspicious timing,
(Sorry, this is a normal simulation. I don't have good example…)
And then, re-run the simulation at the suspicious time or cycle. You can change /RUN in _0001.rad, or create a _0001.ctl file on the same folder as _0000.rad, _0001.rad soon after submitting the run. The _0001.ctl should be like this,
/CYCLE/7000 /STOP ############ 7000 is just a example. This should be the cycle just before suspicious point.
And continue the run with _0002.rad. We have to output everything for each cycle, thus /PRINT, /ANIM/DT, /TFILE should be modified like this,
/PRINT/-1 /ANIM/DT 0 1e-30 /TFILE 1e-30
Check unexpected suddenly change for all cycles.
E, Begin a model just with mesh, material and property and then return analysis conditions step by step
1st, we remove all analysis conditions. In the model, there are only mesh, materials and properties. Include file is useful for this method,
As example, I explain it in a drop simulation. There are conditions of initial velocity, rigid wall, contact, tie and sometimes gravity. If the mesh only model runs, we can return one of those conditions. If works, return another one. We can repeat it to detect what condition makes the simulation unstable.
If you find the suspicious condition, you shall check _0000.out warning messages to find out suspicious setting.
Combination and order
There is no right order, no right combination. It depends on your own experience and inspiration.
Here is my order and combination. There is no guarantee whether it works always. You can find your own better combination and order.
- I first do A (double precision) + B (smaller time step) + C (energy history for all parts) because it is not difficult to do them and the combination has pottential to make my model run.
- If #1 is not enough, I do E (start from mesh only model) and check suspicious setting and warning messages in _0000.out. During #2, I also keep #1.
- If #2 is not still enough, I finally go to D (watch the moment). During #3, I also keep #1