simtk.org

Hi, is it normal that OpenSim Moco simulations run faster compared to when activation dynamics is ignored? As can be seen in a small example (from exampleMocoInverse.py), the number of variables and constraints are lower, but it took longer to converge. I was expecting to see speedups by ignoring activation dynamics.

Stats when activation dynamics is included: Stats when activation dynamics is ignored: (other stats were zero)

Thank you, and I'm looking forward to hearing from you.
-Mohammadreza

Hi Mohammadreza,

How many iterations did each optimization take? It seems like including activation dynamics required less.

Just because a problem has less variables, doesn't mean that it will converge faster. Activation dynamics might be adding some useful convergence properties in this case.

-Nick

Hi Nick, thanks for your response.

I tested more and found that the residual actuators play an important role here. I tested subject_walk_armless model provided in the example3DWalking directory. (I also reduced the time and the number of meshes for simplicity).

test 1: 10 and 1 were the optimal values for residual forces and moments, respectively.
activation dynamics included: 30 iterations (8.9345709e+02) in 57.14s
activation dynamics excluded: 36 iterations (8.9339992e+02) in 59.77s

test 2: 1000 was the optimal value for all residual forces and moments.
activation dynamics included: 32 iterations (1.4798545e-01) in 55.9s
activation dynamics excluded: 11 iterations (1.9132318e-01) in 20.2s

Please let me know your insights about it. Does it make sense to use strong-enough residual actuators for MocoInverse? What about MocoTrack?

Thank you for your help.
-Mohammadreza

Ideally, you want reserve only as strong as you need them, but sometimes you can achieve better convergence using strong reserves that are penalized heavily in the cost function.
It's difficult to say why excluding activation dynamics is slower here. Ultimately, these are nonlinear problems, and activation dynamics might be adding some "smoothness" to the dynamics that helps convergence.

Ideally, you want reserve only as strong as you need them, but sometimes you can achieve better convergence using strong reserves that are penalized heavily in the cost function.

Thanks Nick, I understand the importance of penalizing reserve actuators in muscle-driven simulations. I had used reserve actuators with 1Nm optimal force for all coordinates with muscles in the both tests.

I was testing residual actuators, those appended to the ground-pelvis coordinates which have no muscles. Is there any downside of using strong residual actuators as in the test 2?

Sorry I didn't explain clearly.

Ah, apologies, I read your post too quickly!

In MocoInverse, the residual forces in the model are fixed, so you only need optimal force values strong enough to achieve dynamic consistency.

It's a different story for MocoTrack. The model kinematics predicted by MocoTrack will depend on the values of the residuals. You may want to modify the kinematics to reduce the residuals, but for that you need to find the right relative weight between kinematic tracking terms and the residuals.

In MocoInverse, the residual forces in the model are fixed, so you only need optimal force values strong enough to achieve dynamic consistency.

I do appreciate your response. So, the test 2 (MocoInverse study with very strong residual actuators) could make sense. As expected, ignoring the activation dynamics in this test converged much faster than when activation dynamics was included. Perhaps this should be addressed somewhere in the exampleMocoInverse as a comment, because the subject_walk_armless model has relatively weak residual actuators. Also, the objective function in test 2 is very much lower than test 1:

test 1: 10 and 1 were the optimal values for residual forces and moments, respectively.
activation dynamics included: 30 iterations (8.9345709e+02) in 57.14s
activation dynamics excluded: 36 iterations (8.9339992e+02) in 59.77s

test 2: 1000 was the optimal value for all residual forces and moments.
activation dynamics included: 32 iterations (1.4798545e-01) in 55.9s
activation dynamics excluded: 11 iterations (1.9132318e-01) in 20.2s

I also found this:

When using weak residual actuators, the number of nonzeros in equality constraint Jacobian would be 34592, while this is 34263 in a model with strong residual actuators. Is it normal? Why does the optimal force of residual actuators affect this number?

Thanks again and sorry for continuing this topic.

Perhaps this should be addressed somewhere in the exampleMocoInverse as a comment, because the subject_walk_armless model has relatively weak residual actuators.

Good idea! The model is used for other examples (e.g., exampleMocoTrack), so I wouldn't want to change the strength of the residuals in the model, but the strengths could be changed in exampleMocoInverse.

When using weak residual actuators, the number of nonzeros in equality constraint Jacobian would be 34592, while this is 34263 in a model with strong residual actuators. Is it normal? Why does the optimal force of residual actuators affect this number?

Hmm, changing the strength of actuators should not change the problem structure. Are you sure you didn't add any extra actuators or change the problem in any other way?

Hi Nick, thanks for your response.

Good idea! The model is used for other examples (e.g., exampleMocoTrack), so I wouldn't want to change the strength of the residuals in the model, but the strengths could be changed in exampleMocoInverse.

It was merely a suggestion. Generally, a comment about the strength of the residual actuators in the exampleMocoInverse would be beneficial for users.

Hmm, changing the strength of actuators should not change the problem structure. Are you sure you didn't add any extra actuators or change the problem in any other way?

I just re-tested with latest opensim-core artifact, and this happened again. Please see this test case (the IPOPT outputs are also included in the script):
Thanks for your follow-up.
-Mohammadreza

Thanks Mohammadreza,

I'm still not sure what's going on here. I'll file an issue for now and take a deeper look into it when I get a chance.

-Nick