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

Anyone tested the RealTime Solver with their own models in A/Car ?

Martin Kieltsch
I had the crazy idea to use the RT Solver to speed up a set of analysis (using FTire and dtout=1e-3 s)
So I tested the MSC Demo vehicle for one typical case and found the benchmark time was 2:05 min for everything on default settings.
 
Then after a week of hazzle with updating the license file I finally tried with different settings for FIXIT and HRATIO.
After some experiments I even found 1 and 2 being some 26 s slower than the standard-settings.
RT_Test
Furthermore the RT solver did not work with my own (even simpler model). It simply would not start running the dynamics with the RT option.
(Model works just fine with GSTIFF)
 
Calling this disappointing would be a compliment from the user point of view.
At the end you guys require buying a license for making my analysis unstable and slower ?
  • 0
    Yes, I've been running 3-axle truck models with FSI.
    I got pretty good, but sort of confusing results.
    FSI
    Using PAC2002 tires with 3D enveloping. (Later found out that there was a bug in the 3D enveloping that makes it much slower, will be fixed for the final release.)
    T_out=0.01, hmax(baseline)=0.001, 15 second simulation.
    But cut the time with a factor of 3 with 3 iterations.
    3,4,5 iterations seems good. Increasing the number of iterations above that will produce diverging solutions and fail.
    Peak accelerations are not too much off. If I study absorbed power, results are very much off, because just a small change in an acceleration peak can change the absorbed power a lot.
  • 0
    So this was actually posted under the right sub-sub forum. Interesting. Still shows up on the top level. Will take time to get used to this new format.
    If the Beta test group had existed, I guess that is where this would have belonged.
  • 0
    Just FYI that you can tag, or associate, an entire question/answer thread with a keyword by using the hashtag character. So if I put #Beta in here then this entire thread will be associated with that. If we had a defined sub-topic at the top named "Beta" (likely a good idea?) then this thread would appear under the main feed AND the sub-topic feed..
    #Car
  • 0
    My colleague (Mike C.) in our Product Development group has the following comment as a starting point for this discussion:
     
    In our experience with Fixed Step Integrator we have found it to be slower or more unstable with FTire. Unfortunately, we don’t document this as a limitation or Known Issue on our documentation. We will need to correct this even though models with FTire are not intended to be run with FSI in RT.
     
    We do provide cautions in using this integrator. Modeling discontinuities and initial transients will  be magnified with FSI, and exercising care in choosing DTOUT, HRATIO and FIXIT combinations with the existence of sensors, contacts or discrete GSE in your model. A combination of these could be the cause of issue #2. I have included a couple of paragraphs from the INTEGRATOR statement that may be relevant.
     
    Thanks,
    Mike
     
    Suggested modeling practices with the fixed step integrator:
    Discontinuities in Adams Solver, especially in the 0th and 1st derivatives, whether from function expressions or from user-written subroutines, etc. are common source of solution failures even using the traditional variable step integrators. Problems with discontinuities will likely be exacerbated when using the fixed step integrator. Below is a list of suggested modeling practices in this regard:
    • Do not use non-holonomic constraints
    • Manually remove/resolve redundant constraints as opposed to letting Adams Solver automatically remove these
     
     
    • Scrutinize any IF statements in function expressions and, if they cause discontinuities, replace them with STEP functions
    • Consider analytic type alternatives to any surface-surface contacts
     
     
    • Check the damping specifications in CONTACT and IMPACT elements against units. Strongly consider avoiding damping penetration distances that are <0.001 length unit and damping values that are >.01 * stiffness values.
    • Avoid velocities which oscillate around zero. This can be common in certain kinds of friction scenarios as well as bringing vehicle models to a stop.
     
     
    Handling sensors, contacts and discrete GSEs with the fixed step integrator:
    The fixed step integrator supports the contact, sensors and the discrete GSEs. However, it does not honor any step size change requests coming from these elements. The user should choose the constant step size (using DTOUT and HRATIO combination) carefully when the model contains one of these elements. The discrete GSE states will be updated every time step. For example, when Adams Smart Driver is used it is the user's responsibility to select the 'fixed' step size such that it will be smaller than (or equal to) the discrete GSE (in this case, 'SamplePeriod' in the driver control file).
     
    Amplification of initial transients with the fixed step integrator:
    Users should take extra care with models exhibiting initial transients in their results from the traditional variable step integrators. If the model/event is not corrected to eliminate such initial transients they may very likely be amplified when running the model with the fixed step integrator. Even relatively small amplitude initial transients in the variable step integrator which a user might not deem important enough to worry about normally can become amplified and problematic in the fixed step integrator.
     
    Integrator restarts with the fixed step integrator:
    It should be noted that the fixed step integrator option does not support 'integrator restarts.' This is done intentionally to avoid the extra amount of computation associated with integrator restarts and also to guarantee the fixed amount of work per integration time step. Integrator restarts are generally caused by i. Singular or ill-conditioned Jacobian, ii. Discontinuity in forces, iii. Sensors forcing the integrator restart, or iv. Euler Singularity. Ideally the user should avoid all these conditions when the fixed step integrator option is selected. Note that the Euler singularity case is supported in the fixed step integrator option without forcing an integrator restart.
  • 0
    Well my application strongly depends on FTire and as FTire has a real time mode, I was expecting that the RT solver may speed this up.
    Well I guess you guys always leave potential for improvement.
  • 0
    Martin, did you have the FTire realtime mode activated? Does it use one core per tire?
  • 0
    More background from my colleague in our Product Development group that verifies what you are seeing: currently FTire RT is not integrated with our Fixed Step Integrator; we have an open task to work with Cosin to resolve this issue. 
     
     
     
     
  • 0
    The effect occurs without using the run_time_mode option.
    Find the test case with the MDI Demo and the example tire from the acar_shared attached.
    Attached Files (1)
  • 0
    Martin,
    We discussed FTire RT integration in our Fixed Step Integrator with Cosin some time ago and will work with Cosin to resolve the issues.
  • 0
    BTW: Michael Gipser complained to me about not being able to access this new community platform.
    His user was not automatically ported to the new system and after contact with MSC support he was told that he'd receive a new user/password (which did not happen,  yet)
    Obviously that process is not as professional and reliable as you'd wish it to be.
    No wonder it's even more quiet here than in the old forum.
© 2025 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement