hexagon logo
Register Sign in
  • State Not Answered
  • Replies 7 replies
  • Subscribers 11 subscribers
  • Views 98 views
  • Users 0 members are here
Options
Related

ADAMS/View CPU Time Increase When Using A Sensor To End The Simulation

jsph_inc
Hello,
 
I have an ADAMS/View model which consists of only rigid bodies and a lot of contact. When running the load case with a sensor that kills the simulation the CPU time is 32 hours. When the sensor is removed and rerun to the same end time the CPU time is 8.5 hours. As expected the results from these two runs are line-on-line the same.
 
I wasn't aware that a sensor to end a simulation could have such a large impact on the CPU time. Has anyone seen this as well..is this expected?
  • 0
    Hi All,
     
    The sensor is used to stop the simulation. 
     
    The sensor uses a state variable that sums the contact force of two contact pairs in the global X-direction. 
     
    When the value of this state variable goes to zero the simulation ends. 
     
    The value of this state variable is fairly constant until the end of the simulation when it goes to zero.  
     
    Perhaps using contact to define the sensor significantly slows the simulation? I should point the sensor to a different channel and rerun...
     
    joe.
  • 0
    Adams will evaluate the sensor function at each converged time step. If it has triggered the sensor will interpolate to find the exact point where it is triggered (reach zero in your case). I don't see anything in your description that explains why it should take such long extra time.
    There are ways that you may try to limit the effect. For example, if you know that the sensor will not trigger before a certain time, you could deactivate the sensor at the beginning, run up to the "safe" time, activate the sensor and continue the run. Something like this:
    deactivate/sensor,id=1
    sim/stat
    sim/dyn,end=42,dtout=0.01
    activate/sensor,id=1
    sim/dyn,end=1000,dtout=0.01
     
     
    But the best way to find out what is going on is probably to turn on debug/eprint (run external simulation so files are written; you should always run external if simulations take a long time). Run a short simulation with the sensor and then one without the sensor.
    Studying the message file can tell you how the time steps have changed with the sensor active.
    I also have a python script that can be used to extract the time step statistics from a message file from a run with debug/eprint turned on. Let me know if you want it.
     
     
  • 0
    Hi JSlat,
     
    Thanks for the great suggestions. I'll have to dig deeper into the differences in runs as you suggested and delay the activation of the sensor as a short term fix.
     
    That would be great if you could share the python script that can be used to extract the time step statistics from a message file...sounds very helpful.
     
    thanks again,
    joe.
  • 0
    Here is a version that functions in later versions of Adams (2021 -> ). Format changed a bit from earlier version.
    If you have a standalone version of python, you can run this with
    python solver_stat_from_debugmsg.py run.msg run.stat
    where "run.msg" is the name of your message file.
    If you don't have a standalone python use
    "C:\Program Files\MSC.Software\Adams\2022_4_904865\common\mdi.bat" python solver_stat_from_debugmsg.py run.msg run.stat
     
    The output file ("run.stat" in this case) might look a bit strange, but can be opened in any text editor. Copy and paste into Excel should show better formatting.
  • 0
    Thanks JSlat! Thanks for all the help and the attached file. I will have a go at this. joe.
© 2025 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement