MocoCasADiSolver did NOT succeed

OpenSim Moco is a software toolkit to solve optimal control problems with musculoskeletal models defined in OpenSim using the direct collocation method.
POST REPLY
User avatar
Mritula Chandrasekaran
Posts: 94
Joined: Tue Dec 19, 2017 5:36 am

MocoCasADiSolver did NOT succeed

Post by Mritula Chandrasekaran » Mon May 18, 2020 5:52 am

Hi
I am getting the following error when I am trying to run gait prediction(as in example2DWalking.m) for my model. Please find the entire error below. Kindly let me know how to overcome this:

Thanks,
Mritula

iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du alpha_pr ls
1000r 3.5742236e+05 1.43e+01 2.29e+03 -1.4 5.32e+00 - 1.26e-01 7.23e-02f 1

Number of Iterations....: 1000

(scaled) (unscaled)
Objective...............: 3.5742236080410802e-03 3.5742236080410803e+05
Dual infeasibility......: 2.2913762598033854e+03 2.2913762598033853e+11
Constraint violation....: 7.0749741003037458e+00 1.4262685376925276e+01
Complementarity.........: 3.6855009971073222e-01 3.6855009971073218e+07
Overall NLP error.......: 2.2913762598033854e+03 2.2913762598033853e+11


Number of objective function evaluations = 2836
Number of objective gradient evaluations = 406
Number of equality constraint evaluations = 2836
Number of inequality constraint evaluations = 0
Number of equality constraint Jacobian evaluations = 1025
Number of inequality constraint Jacobian evaluations = 0
Number of Lagrangian Hessian evaluations = 0
Total CPU secs in IPOPT (w/o function evaluations) = 376.476
Total CPU secs in NLP function evaluations = 3141.000

EXIT: Maximum Number of Iterations Exceeded.
t_proc [s] t_wall [s] n_eval
callback_fun 0.479 0.469 1024
nlp 3.52e+03 3.52e+03 1
nlp_f 30 30 2836
nlp_g 64.7 64.7 2836
nlp_grad_f 76.9 76.9 407
nlp_jac_g 2.97e+03 2.97e+03 1026

Breakdown of objective (including weights):
effort: 357422

Active or violated continuous variable bounds
L and U indicate which bound is active; '*' indicates a bound is violated.
The case of lower==upper==value is ignored.

State bounds: no bounds active or violated

Control bounds: no bounds active or violated

Multiplier bounds: no bounds active or violated

Derivative bounds: no bounds active or violated

Active or violated parameter bounds
L and U indicate which bound is active; '*' indicates a bound is violated.
The case of lower==upper==value is ignored.

Time bounds: no bounds active or violated

Parameter bounds: no bounds active or violated

Total number of constraints: 4789.

Differential equation defects:
L2 norm across mesh, max abs value (L1 norm), time of max abs
/jointset/groundPelvis/pelvis_tilt/value 8.97e-06 3.59e-06 0.000000
/jointset/groundPelvis/pelvis_tx/value 9.54e-08 2.49e-08 0.196001
/jointset/groundPelvis/pelvis_ty/value 3.77e-09 9.50e-10 0.084001
/jointset/hip_l/hip_flexion_l/value 3.36e-06 1.65e-06 0.000000
/jointset/hip_r/hip_flexion_r/value 3.81e-06 1.51e-06 0.000000
/jointset/lumbar/lumbar/value 2.22e-05 1.90e-05 0.164001
/jointset/knee_l/knee_angle_l/value 9.44e-07 3.68e-07 0.028000
/jointset/knee_r/knee_angle_r/value 7.69e-07 2.11e-07 0.028000
/jointset/ankle_l/ankle_angle_l/value 3.41e-07 7.01e-08 0.148001
/jointset/ankle_r/ankle_angle_r/value 6.38e-07 2.11e-07 0.156001
/jointset/groundPelvis/pelvis_tilt/speed 2.82e-01 1.16e-01 0.048000
/jointset/groundPelvis/pelvis_tx/speed 1.13e-02 4.20e-03 0.048000
/jointset/groundPelvis/pelvis_ty/speed 2.01e-02 8.34e-03 0.048000
/jointset/hip_l/hip_flexion_l/speed 3.64e-01 1.20e-01 0.020000
/jointset/hip_r/hip_flexion_r/speed 3.58e-01 1.13e-01 0.020000
/jointset/lumbar/lumbar/speed 3.21e-01 1.02e-01 0.020000
/jointset/knee_l/knee_angle_l/speed 1.13e-01 3.82e-02 0.012000
/jointset/knee_r/knee_angle_r/speed 1.28e-01 4.46e-02 0.012000
/jointset/ankle_l/ankle_angle_l/speed 4.08e-01 1.71e-01 0.192001
/jointset/ankle_r/ankle_angle_r/speed 1.93e+00 6.35e-01 0.128001
/hamstrings_r/activation 2.29e-03 1.55e-03 0.196001
/bifemsh_r/activation 1.21e-04 4.82e-05 0.152001
/glut_max_r/activation 1.26e-03 4.68e-04 0.008000
/iliopsoas_r/activation 1.54e-03 7.99e-04 0.016000
/rect_fem_r/activation 7.46e-04 4.70e-04 0.148001
/vasti_r/activation 2.42e-03 7.24e-04 0.004000
/gastroc_r/activation 1.00e-03 4.79e-04 0.012000
/soleus_r/activation 9.65e-04 3.14e-04 0.120001
/tib_ant_r/activation 1.11e-03 6.63e-04 0.124001
/hamstrings_l/activation 2.34e-03 9.37e-04 0.196001
/bifemsh_l/activation 1.87e-04 1.01e-04 0.016000
/glut_max_l/activation 1.38e-03 5.94e-04 0.052000
/iliopsoas_l/activation 1.45e-03 8.56e-04 0.020000
/rect_fem_l/activation 6.60e-04 3.06e-04 0.040000
/vasti_l/activation 1.69e-03 8.15e-04 0.052000
/gastroc_l/activation 4.94e-04 2.46e-04 0.020000
/soleus_l/activation 7.80e-04 1.89e-04 0.196001
/tib_ant_l/activation 1.27e-04 8.10e-05 0.000000

Kinematic constraints: none

Path constraints: none
-------------------------------------------------------------------------------
Elapsed real time: 3520 second(s) (58 minute(s), 40 second(s)).
18/05/2020 13:10:10
MocoCasADiSolver did NOT succeed:
Maximum_Iterations_Exceeded
===============================================================================
Error using example2DWalkingGaitPred_CM (line 114)
Java exception occurred:
java.lang.RuntimeException: This trajectory is sealed, to force you to acknowledge the solver failed; call
unseal() to gain access.
Thrown at MocoTrajectory.cpp:1347 in ensureUnsealed().

at org.opensim.modeling.opensimMocoJNI.createPeriodicTrajectory__SWIG_4(Native Method)

at org.opensim.modeling.opensimMoco.createPeriodicTrajectory(opensimMoco.java:145)

User avatar
Ross Miller
Posts: 372
Joined: Tue Sep 22, 2009 2:02 pm

Re: MocoCasADiSolver did NOT succeed

Post by Ross Miller » Mon May 18, 2020 9:21 am

Hi Mritula,

In this case it failed because it reached the value you have set for solver.set_optim_max_iterations() without IPOPT converging. You could increase this value above 1000 and try again, but my experience has been that if a problem hasn't converged in 1000 iterations, it probably won't converge in 2000+ iterations, and even if it does it won't necessarily be a good solution.

Some things I try when IPOPT won't converge are:

- Make sure the model can be used to generate a tracking solution (if you haven't already done this) with good tracking of data for the movement you are trying to predictively simulate and with reasonable constraint tolerance (I like 1e-04 but 1e-03 is probably okay for some problems).

- It looks like the only term in the cost function was Effort. I usually get more consistent convergence in "predictive" simulations if I leave the tracking term in the cost function but with a very light weight, e.g. multiply it by 0.0001 compared to the tracking problem.

- Check if there are any large discontinuities in the model's moment arms during the ranges of motion expected, e.g. from wrapping geometry or conditional path points engaging/disengaging.

- On Nick's advice, I recently replaced all CoordinateActuators in my model with ActivationCoordinateActuators. This seems to help the speed of convergence especially in predictive simulations. You just have to add one additional parameter to the actuator, <activation_time_constant>.

Hope this helps,
Ross
Last edited by Ross Miller on Wed Jun 10, 2020 7:45 am, edited 1 time in total.

User avatar
Mritula Chandrasekaran
Posts: 94
Joined: Tue Dec 19, 2017 5:36 am

Re: MocoCasADiSolver did NOT succeed

Post by Mritula Chandrasekaran » Tue May 19, 2020 10:50 am

Thanks Ross.
Can you help me with an overview of how Gait tracking and prediction works hand in hand in MOCO with model and static and motion files as input.

Thanks again
Mritula

User avatar
Ross Miller
Posts: 372
Joined: Tue Sep 22, 2009 2:02 pm

Re: MocoCasADiSolver did NOT succeed

Post by Ross Miller » Tue May 19, 2020 5:10 pm

Hi Mritula,

I have some files for both 2-D and 3-D tracking simulations posted here:

https://simtk.org/projects/umocod

Creating a tracking problem (MocoTrack) also adds an effort term (MocoControlGoal) to the cost function. To do what I described, you would adjust the weights on these terms, e.g.:

J = w1*J_track + w2*J_effort

As w1 gets larger, the optimizer will emphasize good tracking. As w2 gets larger, it will emphasize low effort, usually at the expense of good tracking. The weight for tracking is specified by MocoTrack.set_states_global_tracking_weight, or you can set the weight for each state individually. The weight for control effort is specified by MocoControlGoal.setWeight and, indirectly, by MocoControlGoal.setExponent, e.g. setWeight(1.0) and setExponent(2) minimizes the sum of squared muscle excitations.

The example2DWalking Matlab code may be a better place to start if you are already using that. It has a tracking problem in it. My codes were created starting from that code as well.

Ross

User avatar
Mouaad BOUFADNA
Posts: 22
Joined: Mon Mar 16, 2020 3:24 am

Re: MocoCasADiSolver did NOT succeed

Post by Mouaad BOUFADNA » Wed Jun 10, 2020 1:58 am

Hi Ross

I have the same problem.

I removed the tracking part because I only need the predictive part of the code in my case.
I also removed the solver.setGuess(gaitTrackingSolution). Maybe I still need an inital guess ? But from where if I only want a predictive solution withing tracking problem ?

I also tried to remove some cost but it failed. Fox example the PeriodicityGoal because I 'd like to simulate only one step, and the modify the position bounds for my desired movement.

I added the FinalTimeGoal but no difference.
Since there is no kinematic constraints, should I add some of them , How ?

Thank you for your help

Mouaad

User avatar
Ross Miller
Posts: 372
Joined: Tue Sep 22, 2009 2:02 pm

Re: MocoCasADiSolver did NOT succeed

Post by Ross Miller » Thu Jun 11, 2020 7:24 am

Hi Mouaad,

An initial guess is always needed. If the optimization is running then an initial guess of some sort is being created and used. Moco's documentation probably describes what the initial guess is if none is specified. The initial guess for a predictive simulation doesn't necessarily have to be a tracking solution but I find that's the best way to consistently get convergence. It perhaps biases the result to being similar to the tracking solution but I don't think that's a major problem since we are typically interested in predictions that at least roughly resemble a tracking solution anyway.

If you are simulating locomotion and especially if there's no tracking term in the cost function, I think you will want the PeriodicityGoal. If you're using the code I posted in SimTK, you will need to modify the setup of the PeriodicityGoal in that code to enforce periodicity over one step rather than over two steps. The example2DWalking code included with Moco shows how to do that.

Hope this helps,
Ross

User avatar
Nicholas Bianco
Posts: 1003
Joined: Thu Oct 04, 2012 8:09 pm

Re: MocoCasADiSolver did NOT succeed

Post by Nicholas Bianco » Thu Jun 11, 2020 10:26 am

Hi Mouaad,

To echo Ross' comment: I highly recommend starting from the example2DWalking code to set up the periodicity constraints, as these can be somewhat tricky to define correctly.

The default initial guess used by Moco takes the midpoint value form the bounds of each trajectory variable. I'll sometimes solve an intermediate problem with all cost function terms disabled, so I'm just solving for the problem constraints. You may get funny looking solutions, but you'll then have an initial guess that is a feasible solution of the optimization, which can often be a good starting point.

-Nick

POST REPLY