Is it normal that Radioss solver showing huge amount of time remaining to solve a problem.
Altair EmployeeDear all
I need a help regarding understanding the HyperWorks Solver summery for RADIOSS. I am new to this software and does not have good amount of knowledge, and am trying to solve an Explicit analysis problem. While giving all the necessary inputs in Radioss for a model, I am trying to run the solution. I had tried to run the solver 2 times previously for 10 hrs but couldn't understand how long should I keep waiting. While reading the solver summery, I had seen that it shows 'Remaining Time as 950000 Sec'. Which means it might take 263 hrs (about 10 days) to get the solution done by the HyperWorks solver. Is this a normal TIME which Radioss takes to solve some problems? Whenever I try to do some other work in my laptop, the solver time increases rapidly. At about 'Remaining time 90000 s' the solver works very slow.
My model is a mechanical component, with approximately 30000 elements, used type7 contact at 4 locations. I tried to check it through Model Checker and found almost all parameters getting passed through the check except two errors - 'lsensor for Cload not defined' and 'Skew for Cload not defined' . The image can be seen in the attachment for the detail. While running through solver, I can see '0 Error and 5 Warnings'.
Can any one advice me on urgent basis about 2 of my queries:'
1. Am I doing some mistake because of which such a long expected time is showing to complete the solution? Is there any thing which I can do to solve it sooner. By reading few posts of this forum, I tried to apply 'ENG_DT_INTER/del' option to avoid possible divergence.
2. My error % initially increased to 24% than came down to 14% when I previously run my solver for the same problem for 10 hrs. Does this Error % shows that I had done some mistake? or is it fine to vary it so much? Is there any limit for Error % which I should consider?
Regards
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?>
Answers
-
Hi,
in explicit method the timestep is affected by characteristic element length, stiffness and density. Please go through the timestep chapter in Free eBook: Crash Analysis With RADIOSS – A Study Guide. Also recommended is 2017 Radioss user guide starting from page 30.
Review what is causing very low time step in the engine out file:
•For an element, check the related material (especially its Young modulus and density in case of an elastic-plastic material; and its viscosity in case of a visco-elastic material). There must not be an error in the units system that this data is given in.
Check the size of the element, since elemental length is proportional to time step. If some elements are distorting badly during simulation it will lead to very low time step and the run will terminate. In this case use small strain formulation (in the property card).
•For a node, check the characteristics of connected elements. If the node is on the master side or the slave side of an interface, this interface must be verified.
•For an interface, the gap of the interface must be verified if some failure happens on the master or the slave side of the interface. Check the interfaces defined in the model for any penetrations.
To reduce solving time use mass scaling (DT/NODA) or advanced mass scaling (AMS). Any targeted model for AMS application should run first in /DT/NODA/CST with a reasonable energy error (ERROR < +2%) and acceptable added mass (MAS.ER < 0.02) along its simulation time. A model unable to run with /DT/NODA/CST will not run with AMS either. Output the number of AMS iterations per cycle via /DT/AMS/Iflag - Iflag =2 may help to monitor convergence quality at no extra CPU cost.
Maximum allowed iterations before the divergence stops is 1000. 75 to 100 iteration per cycle is a sign of a poor convergence 50 still may provide some speedup
30 iterations or less is considered a good convergence.There should be only a few cycles where INTER is controlling the timestep.
Use Multi-Domain Technique if your model has different subdomains characterized by different mesh sizes and consequently very different minimal time step.
Additionally, you can use single precision (Radioss panel options: -sp) to speed up computation.
Run time remaining can increase during the run even if the timestep does not drop. This happens when available CPU power is used during the run for other tasks (use Windows task manager to check how much CPU is utilized).
Negative Energy Error represents energy dissipated from the system and this can be from many sources including plastic deformation and Hourglass energy.
If you have included coefficient of friction then the energy error is due to coefficient of friction which is justified. If this amount of energy error is there when no coefficient of friction is defined, then it may be a case of penetration which is problematic. The combined energy error (contact + hourglass) should be less than 15% of the total energy.
The following contact settings are recommended for type 7:
Istf=4
Igap=2
Fscale_Gap=0.8
INACTI=6
Gap_min=1
Fric = 0.1
Iform=2
You can try increasing the Gapmin in your TYPE7 interface which will allow the contact to work sooner and prevent deep penetration. It is also possible to use /DT/INTER/DEL in the engine file to release slave nodes from the interface when time step drops below the value given in this option /DT/INTER/DEL- however, if there are many nodes released during the run the results can be questionable.
0 -
Altair Forum User said:
Hi,
in explicit method the timestep is affected by characteristic element length, stiffness and density. Please go through the timestep chapter in Free eBook: Crash Analysis With RADIOSS – A Study Guide. Also recommended is 2017 Radioss user guide starting from page 30.
Review what is causing very low time step in the engine out file:
•For an element, check the related material (especially its Young modulus and density in case of an elastic-plastic material; and its viscosity in case of a visco-elastic material). There must not be an error in the units system that this data is given in.
Check the size of the element, since elemental length is proportional to time step. If some elements are distorting badly during simulation it will lead to very low time step and the run will terminate. In this case use small strain formulation (in the property card).
•For a node, check the characteristics of connected elements. If the node is on the master side or the slave side of an interface, this interface must be verified.
•For an interface, the gap of the interface must be verified if some failure happens on the master or the slave side of the interface. Check the interfaces defined in the model for any penetrations.
To reduce solving time use mass scaling (DT/NODA) or advanced mass scaling (AMS). Any targeted model for AMS application should run first in /DT/NODA/CST with a reasonable energy error (ERROR < +2%) and acceptable added mass (MAS.ER < 0.02) along its simulation time. A model unable to run with /DT/NODA/CST will not run with AMS either. Output the number of AMS iterations per cycle via /DT/AMS/Iflag - Iflag =2 may help to monitor convergence quality at no extra CPU cost.
Maximum allowed iterations before the divergence stops is 1000. 75 to 100 iteration per cycle is a sign of a poor convergence 50 still may provide some speedup
30 iterations or less is considered a good convergence.There should be only a few cycles where INTER is controlling the timestep.
Use Multi-Domain Technique if your model has different subdomains characterized by different mesh sizes and consequently very different minimal time step.
Additionally, you can use single precision (Radioss panel options: -sp) to speed up computation.
Run time remaining can increase during the run even if the timestep does not drop. This happens when available CPU power is used during the run for other tasks (use Windows task manager to check how much CPU is utilized).
Negative Energy Error represents energy dissipated from the system and this can be from many sources including plastic deformation and Hourglass energy.
If you have included coefficient of friction then the energy error is due to coefficient of friction which is justified. If this amount of energy error is there when no coefficient of friction is defined, then it may be a case of penetration which is problematic. The combined energy error (contact + hourglass) should be less than 15% of the total energy.
The following contact settings are recommended for type 7:
Istf=4
Igap=2
Fscale_Gap=0.8
INACTI=6
Gap_min=1
Fric = 0.1
Iform=2
You can try increasing the Gapmin in your TYPE7 interface which will allow the contact to work sooner and prevent deep penetration. It is also possible to use /DT/INTER/DEL in the engine file to release slave nodes from the interface when time step drops below the value given in this option /DT/INTER/DEL- however, if there are many nodes released during the run the results can be questionable.
Dear Ivan
Thanks a lot for giving me your valuable time to reply with such a detailed insight about my stated problem. It gave me new perspectives to work on for solving the issue with simulation. I will be looking into each of your precious advice and will try to get it done. Your help means a lot to me and thanks once again for your help.
Regards
1 -
Hi,
Lot of good advice given by Ivan. As he mentioned you need to understand why your timestep is so low.
It would be useful to understand what type of analysis you are doing. Is it a drop test, impact crash, quasi-static imposed force or displacement loading? For quasi-static loadings, you can shorten the run time by applying the load faster but you have to make sure the load isn't so fast it causes dynamic effects by checking the kinetic energy in the model.
Typically it is important to see what your energy error is at the end of the simulation.
Last, please find the number of cores in your CPU by searching for it. For example, mine is an Intel i7-4910MQ.
Note that this page says my CPU has # of Cores = 4. Then take the # of Cores and use it with the -np option when you submit the job. This will cause Radioss to use 4 cores when it solves.
So if you submit from the command line you can use radioss -np 4 test_0000.rad or put '-np 4' in the solver run manager window.
While running the 'Remaining Time' is an estimate that will change depending on the model and how much you use your PC for other things while it is running.
Thanks,
Andy
1 -
I am doing a rollover analysis of a bus frame. I applied the command line -np 8 and -sp for the analysis as you mentioned. Still the solver summary shows remaining time as 731304.35 seconds. I have a total of 1678667 elements in my model. My out file size is around 50mb so I have not attached it here. Can u give any suggestions. Thanks in advanceAndy_20955 said:Hi,
Lot of good advice given by Ivan. As he mentioned you need to understand why your timestep is so low.
It would be useful to understand what type of analysis you are doing. Is it a drop test, impact crash, quasi-static imposed force or displacement loading? For quasi-static loadings, you can shorten the run time by applying the load faster but you have to make sure the load isn't so fast it causes dynamic effects by checking the kinetic energy in the model.
Typically it is important to see what your energy error is at the end of the simulation.
Last, please find the number of cores in your CPU by searching for it. For example, mine is an Intel i7-4910MQ.
Note that this page says my CPU has # of Cores = 4. Then take the # of Cores and use it with the -np option when you submit the job. This will cause Radioss to use 4 cores when it solves.
So if you submit from the command line you can use radioss -np 4 test_0000.rad or put '-np 4' in the solver run manager window.
While running the 'Remaining Time' is an estimate that will change depending on the model and how much you use your PC for other things while it is running.
Thanks,
Andy
0