Error when attempting parameter optimisation in Matlab

[Daniel Gordon]

Hi,

I've set up a MocoStudy tracking prescribed kinematics and minimising muscle activations as well as penalising deviations from reference control values in the cost term. This runs fine.

However, when I try to add a MocoParameter to optimise the max isometric force value for a muscle, like so:

Code: Select all

param = MocoParameter('tib_force', '/forceset/tib_ant_l', 'max_isometric_force', MocoBounds(100, 905));
problem.addParameter(param);

I no longer see the usual output to the Matlab command window, rather this message is displayed over and over:

Old version storage/motion file encountered
.. assuming rotations in Degrees.

Then, eventually I get this error message:

Java exception occurred:
java.lang.RuntimeException:
D:\a\opensim-moco\opensim-moco\dependencies\casadi\casadi\core\function_internal.cpp:137: Error calling
CallbackInternal::init for 'endpoint_constraint_initial_activation_endpoint':
D:\a\opensim-moco\opensim-moco\dependencies\casadi\casadi\core\callback_internal.cpp:77: Error calling
"get_jacobian_sparsity" for object endpoint_constraint_initial_activation_endpoint:
SimTK Exception thrown at MeasureImplementation.h:860:
Error detected by Simbody method Measure::Result::markAsValid(): This Result Measure cannot be marked
valid in a State where this measure's Subsystem has been realized only to stage Model, because its
value was declared to depend on stage Velocity. To mark it valid, we require that the State have been
realized at least to the previous stage (Position in this case); that is, you must at least be
*working on* the dependsOn stage in order to claim this result is available.
(Required condition 'subsystemStage >= getDependsOnStage().prev()' was not met.)

Just wondering if anyone has any idea how to fix this as I can't immediately see how I've differed from the examples in the MocoParameter implementation?

Cheers

[Christopher Dembia]

Daniel:

My guess is that this is working just fine, but that optimizing a parameter causes the MocoCasADiSolver to slow down to a crawl.

You can try setting `solver.set_parameters_require_initsystem(false)`, but this may lead to incorrect results.

See the section on "Parameter variables" here: https://opensim-org.github.io/opensim-m ... olver.html

[Daniel Gordon]

Thanks for the quick help. I'll try that or maybe using the Tropter solver without prescribing kinematics.

Out of interest, is there an easy way to know which model parameters require calls to initSystem() and which don't?

Thanks again

[Christopher Dembia]

Out of interest, is there an easy way to know which model parameters require calls to initSystem() and which don't?

There is no easy way to know; you have to understand a bit about how a property is used. Sometimes, a property affects what is added to the underlying SimTK::System, and the parameter has no effect after `model.initSystem()` is invoked. This is true for a Body's mass properties. Other properties are used to initialize a member variable of a component (in `Component::extendFinalizeFromProperties()`); this is true for some properties in `DeGrooteFregly2016Muscle`, and those member variables won't be updated correctly if `model.initSystem()` is not invoked. My guess is that a muscle's `max_isometric_force` does not require `model.initSystem()`.

[Aaron Fox]

Hi Chris,

I've also wondered if there is a simple way to determine whether the CasADi solver is appropriate for certain parameter optimisations (i.e. navigating the initSystem issue). I wonder if limiting the solver to a short few iterations with the initSystem parameter set to false, and then examining the results would yield any use? In this instance, if an initSystem was required to actually alter the parameter would it staying the same across each iteration indicate that things aren't going to plan?

Aaron

[Christopher Dembia]

Aaron, good questions.

In this instance, if an initSystem was required to actually alter the parameter would it staying the same across each iteration indicate that things aren't going to plan?

The property in the model would still change, but it would not have an effect (or it might have some weird distorted effect). You could solve 5 (or any small number) iterations with the `parameters_require_initsystem()` true and false, and see if the 5th iterate/trajectory is the same in both cases. If so, `initSystem()` is not required.