simtk.org

Hi all,

I do most of my Moco simulations on a still-fairly-recent, fairly powerful desktop computer (2020 iMac, 3.8-GHz 10-core Intel Core i9 CPU). When I simulations of walking that have a MocoTrack goal defined plus other goals and constraints, e.g. periodicity, speed, control effort, metabolic cost, a single iteration in IPOPT with a 3-D full-body model takes 1-2 minutes.

Normally when I do "predictive" simulations of walking, I still retain the MocoTrack goal in the code, but I'll set its weight to zero or to some very small value. This retains the same computational performance, 1-2 minutes per iteration.

However, if I remove the MocoTrack goal, the computational performance gets much worse, a single iteration takes about ~10x longer.

Has anyone else experienced this? Is this expected? If it's not expected, have I possibly stumbled onto a bug, or is there something in my code that could be causing this? I checked on the parallelism options in the solver and it is enabled in all three cases. I think the default option is to use all available cores anyway.

Thanks!
Ross

Hi Ross,

Do you mean that you create a MocoStudy and add the MocoStateTrackingGoal to its problem or that you create a MocoTrack that has the implicit StateTrackingGoal and MocoControlCost term? How do you remove the goal from a problem? Would be interested if you still get poor performance if you use MocoStudy

-Sunny

Hi Sunny,

By "remove the MocoTrack goal" I just mean I create a MocoStudy that does not have a tracking goal, e.g. a problem that only minimizes metabolic cost with no tracking. This iterates slowly.

If instead, for example, I create a problem with a tracking goal and a metabolic cost goal and set the weight on the tracking goal to zero, this iterates much faster.

Ross

Hi Ross,

That is definitely strange. It makes sense that there's a performance boost when using a small weight on the tracking goal, as then it is somewhat like a regularization term (Ton always includes these terms to improve his predictive simulation results). But I'm surprised setting the weight to zero produces the same benefit. Definitely possible that this is a bug, but I wonder if just having the trajectory variables in the cost function (even if zero-weighted) provides some benefit during IPOPT's gradient calculations under the hood.

I've been considering adding a solver option to easily add a regularization term to the cost function, similar to the options to minimize controls introduced for implicit dynamics.

-Nick

Hi Ross,

I have run into that exact timing issue with "purely" predictive optimizations when compared with optimizations with kinematic tracking terms. I was confused by this discrepancy, but dismissed it (maybe naively) as due to some sort of underlying computational process in the gradient that was different between MocoStudy and MocoTrack. I haven't tried to use a tracking weight of zero for a MocoTrack problem, but I would definitely be curious to try this potential 'hack'.

Curious: since you've run each version, have you compared the solutions from the MocoStudy prediction versus the MocoTracking with a weight of zero? Are they the same?

Thanks,
Russell

Hi Russell,

The solution you described (set it up with MocoTrack and just set the weight to zero) is the one I've been using.

I've not let a MocoStudy without MocoTrack run to completion to see if both approaches give the same result. The MocoStudy approach takes quite a bit longer (roughly 10x time per iteration). I could try it with a smaller model that doesn't take ~a day to converge normally but haven't done that yet.

I fussed around with the parallelization settings and that doesn't seem to be the problem, or at least it does not affect the speed of the MocoStudy iterations. Nick, wasn't there an issue in a very early version of Moco where parallel was being disabled for certain problems? Is it possible that's happening here?

Ross

Hi all,

Just an update here that I think I found the source of the speed discrepancy here. MocoTrack generates some settings for the CasADi solver that are different from the default solver settings. When I match those settings between MocoTrack and MocoStateTrackingGoal, I get similar speed and convergence performance. In particular, the settings for sparsity pattern detection and finite difference scheme seem to have a big effect on iteration speed and convergence.

The cost function scores are still a little different when I try to replicate the MocoTrack problem using MocoStateTrackingGoal (in the same ballpark but not exactly the same). I haven't done a deep dive into the cpp code to find the source of that yet.

So, if you are doing "predictive" simulations and getting slower iteration and poor convergence vs. MocoTrack, try checking the solver settings generated by MocoTrack and copying them to your predictive problem, it might help.

Ross

Hey Ross,

Good catch! Yes, the finite difference scheme can have a big effect on iteration speed. (Note for anyone reading: this finite difference scheme is to specify how CasADi computes gradients for the optimization problem; it is not related to how defect constraints are handled in the transcription scheme).

I haven't played around much with the sparsity pattern options. Is there a setting that usually gives you the best performance?

-Nick

I haven't played around with it much either but have had the best results (convergence) with "none" for the sparsity pattern detection, which I think is the MocoTrack default. I tried "random" recently and that didn't work well (poor convergence).

Ross