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

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.

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 ?

Parents

0 Kent West over 8 years ago

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.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Reply

0 Kent West over 8 years ago

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.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Children

No Data