Simulations never converge

[Carlos Gonçalves]

It has been close to one year of learning and running Moco, but to be true, I never got it converging before running out of iterations.

I was only able to get it right running the examples. There are some guidelines to it?

I already tried in 2D and 3D walking, and also in rowing (https://www.linkedin.com/posts/carlos-g ... 73632-jnEM) but the program always run out of iterations.

I already tried loosening the convergence parameters, using guess trajectories, with and without tendon compliance, and most recently with explicit and implicit muscle dynamics.

Any help? I usually use 50 mesh points and 2000 max iterations. Most of the time in predictive simulations. I think that tracking is easier to converge?

Best regards.

[Ross Miller]

Hi Carlos,

What value are you typically using for the tolerances? I think the constraint_tolerance is important and should be pretty low but convergence_tolerance is less important. I typically use constraint_tolerance = 1e-04 and convergence_tolerance = 1e-02. In my experience the iterations to convergence is very sensitive to convergence_tolerance and not much is gained by using smaller values for it.

The constraint_tolerance here means, I think, that for example the smallest permissible violation of the explicit dynamics would be 0.0001 rad/s^2 (pretty small), smallest permissible violation of periodicity constraint would be 0.0001 rad, smallest permissible speed constraint violation 0.0001 m/s, etc. What value for convergence_tolerance is "small" probably depends on your cost function though, but I think it means that if for example the cost function is metabolic cost (J/m/kg), the optimizer would see no difference between 3.99 J/m/kg and 4.00 J/m/kg. Maybe Nick can clarify if I'm mistaken on these things.

Predictive simulations definitely seem to take more iterations (sometimes a lot more) than tracking simulations. I'm not sure why this is but it's been the case for every simulation I've ever done, in Moco or in other software. I think it helps to start from a tracking solution, when it's possible to generate one.

Ross

[Pasha van Bijlert]

Hi Carlos,

In addition to Ross's suggestion (using a tracking solution as an initial guess), there are some other strategies you could consider. If your model is very complex (many DoF but especially, many controllable muscles), the search space is very large. Assuming you don't have an initial guess that's already "pretty good" (i.e. dynamically consistent, or even a converged optimal solution), it's not necessarily that surprising that you need many iterations for convergence. For reference: if I start a 14Dof 22 muscle prediction optimization with a random/bad initial guess, it can quite literally take 7000-8000 iterations before the optimizer converges (although the converged solution is hit or miss in my experience, if the initial guess was completely random). If I have a "good" converged solution, for instance at 1.5 m/s, and I use it as the initial guess for 2.0 m/s, I might get convergence anywhere between 100-1500 iterations. So basically: it might be worth having the optimizer run for more iterations, next to playing with the tolerances as Ross suggested.

In my situation, I don't have access to tracking data on which I could base my initial guess for a predictive simulation. A strategy that worked for me was to start off with simplified musculature (so if there are two muscles crossing the same joint, remove one of them and make the remaining one stronger). Reducing the number of controls will drastically reduce your search times. Once you find a good solution with simplified musculature, you can use this as an initial guess for a more complex model.

Lastly, minimizing auxiliary derivatives improved convergence for me when using implicit tendon dynamics, and there are two specific goals pre-programmed to enforce tendon force & velocity equilibrium. These last two are redundant, I think, if you're enforcing activation or controls periodicity, but in certain cases I found that they still reduced optimization times.

Hope this helps!
Pasha

[Ross Miller]

This is the hard part about simulating dinosaur locomotion I guess (no data for tracking targets!)

Similar to Pasha's suggestion, another approach I've had good results with is to start with a simple model that works, e.g. one of the Moco examples, then gradually add complexity to the model, using my result from the simpler model as the initial guess. Trying to generate simulations with a bad guess on a 31-DoF, 84-muscle model generally does not work well, but I could get a good result on a 2-D armless model, then replace the tracking targets with my own data, then gradually add DoF and muscles. This is also nice because then when the result is not good or the convergence doesn't happen, I know what I added that resulted in this change.

Ross

[Carlos Gonçalves]

Ross and Pasha, thanks a lot for the answers. Really appreciate it.

@Ross, since the begging, I started my solver settings using the examples. I started with 1e-04 for convergence and constraint (2D gait examples), then reduced both a little bit to 1e-03, and finally I'm trying to use your settings from goWalk_v2.m

solver.set_optim_constraint_tolerance(1e-04);
solver.set_optim_convergence_tolerance(1e+01);

In all that cases I could get the solver to converge only in tracking. But as you both mentioned, I was focusing on impaired gait with a lot of goals, making muscles weak, and maybe the problem got more difficult for the solver.

@Pasha, I totally agree that is a "leap of faith" to start the simulation with no guess and expect something. But even using "possible" results from previous simulations I still can't get the solver to converge. But I will try increasing the iterations and focusing on the constraint_tolerance.

If I could ask you both, how do you manage to use results from simpler models to more complicated ones? I had a hard time in the beginning until I realized that the coordinates values AND all the controls and muscle states (explicit mode) should be all in the guess. How do you create this new guess with all that "missing" data? I saw a thread in the forum talking about something similar from using explicit results as a guess for an implicit simulation.

And how should I interpret the solver results per iteration and at the end of the simulation? What references should I check for that?

I will try to come back to this topic with new results. Nowadays I'm working on two projects: one for impaired 3D gait simulations, and the other for predictive simulations in sports. For the first, there are path constraints established in the code (periodicity, symmetry, and so on), for the second the random guesses work well, but there are a lot of constraints in the OpenSim model.

Best regards.

[Pasha van Bijlert]

Hi all,

This is the hard part about simulating dinosaur locomotion I guess (no data for tracking targets!)

Yup, very little ground truth so lots of sensitivity analysis and careful interpretation. There are some cool EMG studies done on birds and crocodiles while walking, which can at least give you something to compare activation patterns with.

If I could ask you both, how do you manage to use results from simpler models to more complicated ones?

It kind of depends on what you've added to the model. Lets say you have a converged trajectory for a simpler model ('simple_traj'). You can load that trajectory, and then loop through all of the kinematic states (so joint angles and velocities, pelvis translations, etc) which you can set as the initial guess for your new, more complex problem. You can do the same thing for all of the muscle states, the controls, and auxiliary derivatives (if you're using implicit tendons). This trajectory will not be complete yet, because your new more complex model might have more muscles or more joints or something. I get around this by first generating a bounded initial guess for the complex problem, and then looping through everything that I can repurpose from the simpler problem to populate the bounded initial guess. What you're left with is an initial guess that uses multibody dynamics & muscle states from the simpler model, and values within bounds for the other states. Here's an example snippet code for matlab:

Code: Select all

simple_traj = MocoTrajectory('simple_traj.sto') %this is a converged solution for a simpler model

solver.setGuess('bounds'); %This is a bounded initial guess for your more complex model
guess = solver.getGuess;

%%% loop through the states you have in your simple trajectory, and populate the new guess with it
for h=1:simple_traj.getNumStates()
    state_name=simple_traj.getStateNames.get(h-1);
    guess.setState(state_name, simple_traj.getStateMat(state_name))
end

%%% loop through controls
for h=1:simple_traj.getNumControls()
    cont_name=simple_traj.getControlNames.get(h-1);
    guess.setControl(cont_name, simple_traj.getControlMat(cont_name))
end

%%% loop through derivatives (if you're using implicit formulations)
for h=1:simple_traj.getNumDerivatives()
    der_name=simple_traj.getDerivativeNames.get(h-1);
    guess.setDerivative(der_name, simple_traj.getDerivativeMat(der_name))
end

It's not the most sophisticated way to approach the missing states, but it's worked for me so far. I'll give the caveat that I've only attempted planar motion for now. If you're using explicit tendon dynamics, you might have to play around with it some more (i.e. setting activations and normalized tendon forces to a relatively low value manually).

Hope this helps,
Pasha

[Carlos Gonçalves]

Thanks a lot Pasha, that is something that I should try next.

This approach is way better than setting everything to random, .

After I sent the message yesterday, I thought of another approach (but I have never done it):

1- get a converged motion from a simpler motion with a model with markers
2- extract the positions of the markers to a .trc file
3- create a more complicated model
4- do a tracking simulation with a MocoMarkerTrackingGoal
5- use the new solution as a guess for the next simulations

What do you all think?

Best regards.

[Pasha van Bijlert]

Hi Carlos,

I've never tried doing a tracking simulation first, although that's definitely one of the things I was planning trying if what I described above wouldn't have worked. I think you'd still want an initial guess for the tracking simulation, so you could still use the code snippet for that.

Does tracking only work with markers? Wouldn't you be able to simply track the actual joint angles, because in this case measurement error isn't much of an issue? I'm not sure because I've actually not done any tracking simulations in moco.

Cheers,
Pasha

[Carlos Gonçalves]

Great! It is very good to discuss those approaches and realize they actually make sense

Regarding tracking, there is a MocoStateTrackingGoal. I think it should work with the coordinates. There are some examples using MocoTrack also:

Code: Select all

# Construct a TableProcessor of the coordinate data and pass it to the 
# tracking tool. TableProcessors can be used in the same way as
# ModelProcessors by appending TableOperators to modify the base table.
# A TableProcessor with no operators, as we have here, simply returns the
# base table.
track.setStatesReference(osim.TableProcessor("coordinates.sto"))
track.set_states_global_tracking_weight(10)

This discussion made me realize that I need to invest time in creating and editing those STO files. "There is no free lunch".

Thanks a lot for the time.

[Nicholas Bianco]

Hi everyone,

Regarding IPOPT settings: the Moco constraint tolerance sets the IPOPT option "constr_viol_tol" which is the absolute tolerance on the problem (unscaled) constraint violation (ref: https://coin-or.github.io/Ipopt/OPTIONS.html). So there seems to be a close numerical relationship between this tolerance and constraint errors.

However, this is not true for the Moco convergence tolerance that controls the "compl_inf_tol" and "dual_inf_tol" settings, which represent the complementarity and dual infeasibility tolerances. These conditions arise from interior point algorithm that IPOPT is built on (IPOPT is short for Interior Point OPTimization). The complementarity tolerance enforces the KKT conditions of the optimization, which includes the objective gradient and the complementary slackness conditions (constraints and Lagrange multipliers). The dual infeasibility tolerance (I think) is the tolerance on the changes in the variables of the dual problem, which provides a lower bound for the objective and helps determine convergence. (Check out Boyd's Convex Optimization book, the bible for non-linear optimization, for more details: https://stanford.edu/~boyd/cvxbook/bv_cvxbook.pdf).

-Nick