Integrator step size

[Jiang Ping]

hi all,

I have a question about how integrator selected the step size.
I run the same simulation for several times, finding that the integrator choose
different step size. Sometimes step size was big and simulation time is short, but
sometimes step size is very small and simulation time is very long.
I could not understand for a simulation with the same inputs and same system why the
integrator selected different size.
Any help would be much appreciated! thanks a lot!

Jiang

[Michael Sherman]

Hi, Jiang. Step size choice in Simbody is completely deterministic. If you run the same simulation twice you should get exactly the same sequence of steps. If that is not happening there is something random in your program. This could be because you have a custom force element that is applying random forces, or more likely because of a bug, for example something that is referencing uninitialized memory which has random contents at program startup.

I suggest you simplify your model (remove model elements) until you are able to get deterministic behavior, then add things back in one at a time to find out what model element is causing the problem.

Regards,
Sherm

[Jiang Ping]

hi Sherm,

Thanks very much for your reply. I have checked my code and found the udot vector
in state vector has some elements whose value are NaN. Do you have any idea about
this problem?

Thanks in advance

jiang

[Michael Sherman]

Since udots are calculated from inverse mass properties and forces, NaNs in udots are a symptom of problems elsewhere. Most commonly they come from using uninitialized data, such as a State that has not been set to anything. They can also arise due to non-physical mass properties (zero mass or inertia) or because a custom force element is injecting NaNs into the force arrays.

These problems can be debugged by simplifying your code until you have a working system, then adding in new elements one by one until you find the one that is causing the NaNs.

[Jiang Ping]

hi Sherm,

Thanks for the reply. I found it worked well if I removed the delay component.
I wonder if the Measure::Delay needs to be initialized, and how delay component affects
system initialization and the cache values?

Thanks in advance,
Jiang

[Michael Sherman]

I found it worked well if I removed the delay component.
I wonder if the Measure::Delay needs to be initialized ...

Hmmm. These are a little tricky to initialize, but that gets done automatically when the integration gets initialized. What happens is that before the integration start the Measure::Delay initialization method calls the getValue() method of its source measure and records that as the initial value for the delay buffer. If for some reason the source measure returned a NaN or other bad value, that would cause problems. Some random thoughts: custom source measure with a bug in the "depends on" stage it claims; Delay measure and source measure are in different Subsystems and get evaluated in the wrong order; bug in Delay measure.

As usual the best way to debug this would be to create a very simple test case, perhaps with just the source and delay measure in it, to see if the initialization problem still occurs, and then trace it to the source of the problem. Also it would be good to check the values of the source and delay measures right after calling initialize() on the integrator or time stepper.

Regards,
Sherm

[Jiang Ping]

hi sherm,

I am still confused with the system initialization.
Does method buildSystem() and initializeState() initialize the cache value such as
Qdotdot, QdotError, Zdot, etc. before forward dynamics simulation?
Seems that those values were not initialized before simulation even I disconnect
all constraints, controller and handler.

Thanks a lot,
Jiang

[Michael Sherman]

Hi, Jiang. Anything in the State cache that isn't initialized is marked invalid, so accessing them too early should produce a good error message. However, in Release builds a lot of validity checking is turned off for performance reasons -- if you haven't tried running a Debug build that could be very helpful in diagnosing the problem.

I am somewhat confused now about whether you are asking about Simbody or OpenSim. The methods buildSystem() and initializeState() are OpenSim methods, not part of Simbody although of course they make use of Simbody. You may want to post on the OpenSim forum to get OpenSim experts involved.

Sherm

[Jiang Ping]

Hi Sherm

Thank you for your reply. As you said, cache values are not initialized to NaN in release mode, which caused
the "Conditional jump or move depends on uninitialised value(s)" error in valgrind. Now my code works well.
Thanks again for your help

Jiang