Different Static Optimization Results with Differing Start Times

[Jonathan Mortensen]

Hi Everyone!

I have a fairly long inverse kinematics file that I am running static optimization on. I was able to get static optimization to run the whole kinematics file, but it took a long time. I have been experimenting with segmenting the kinematics file into smaller periods of time and running them through static optimization in parallel. This runs much faster for me. When I compare the results, the muscle activations are similar between the two approaches, but not identical.

Does anyone know why static optimization results would be slightly different when running a smaller segment of motion as compared to the results from the same time period when running a larger segment of motion?

I have checked that the time points match up perfectly between the two results, and can't find anything different in the setup of my simulations other than the starting and stopping time. Is it an effect of how the optimizer solves the problem? Is there an element of randomness that is determined by when the entire simulation is started? My understanding is that static optimization solves for each time point without any regard for previous time points. Is inverse dynamics being solved differently? Any insights would be welcome.

I've attached an example of the differing results:

Screenshot 2022-08-31 101322.png (19.35 KiB) Viewed 629 times

[Ayman Habib]

Hello,

As you suggested, Static Optimization is ran on a frame by frame basis, so in theory the answers should be the same. One possible caveat is that if filtering is used, then there could be end-effects and that may cause the stitching to be imperfect.

Please let us know if that explains the differences you see.

Best regards,
-Ayman

[Jonathan Mortensen]

Thank you for your reply!

I was able to get it working. Filtering was not the issue, as I am filtering the data before segmenting it. The issue was in my code that segmented the kinematics. My code was writing a file flagged for being in degrees instead of radians. The only reason the data was so close is that most of my coordinates have kinematic constraints on them that force everything to be read as radians anyway.

But the important thing is that the two approaches now perfectly overlap, and static optimization works as we would expect.