simtk.org

We're running static optimization in a number of subject-specific models using the thoracolumbar trunk model, which is quite complex with many degrees of freedom and several hundred muscle fascicles. In short, we scale the trunk model to match a subject's spine curvature and estimated muscle parameters. We then feed in motion files that mimic quasi-static postures like flexing 75 degrees for a single timepoint (no movement).

I have a few questions about static optimization failures, specifically as it relates to constraint violations.

This is a typical failure message we get when running SOs. On average, I would say only about 5-10% of our SOs fail for a specific posture.

OPTIMIZATION FAILED...

StaticOptimization.record: WARN- The optimizer could not find a solution at time = 0

The model appears unsuitable for static optimization.
Try appending the model with additional force(s) or locking joint(s) to reduce the following acceleration constraint violation(s):
T1_r1R_X: constraint violation = 6.10875e-006
SternumRotZ: constraint violation = -5.3001e-006
SternumRotX: constraint violation = 2.44671e-006
SternumRotY: constraint violation = -1.3608e-006
elv_angle_r: constraint violation = -1.04284e-006
elv_angle_l: constraint violation = -1.38743e-006


time = 0 Performance =2.62315 Constraint violation = 9.00582e-006

In other subjects, this list of constraint violations may be much longer (e.g. 20+ coordinates with tiny constraint violations).

My 2 main questions are:
1. What is the best solution to fix these "failures"? I have read other forum suggestions to use reserve actuators -- but would this require us to add actuators to every DOF in the model? That's a huge set of actuators. Additionally, why do you think for the majority of subjects we don't get these constraint violation failures? In cases where specific muscles are too weak, the message is clear and makes sense. It's a little tougher to make sense of these constraint violation values.

2. The model is very complex with a lot of coordinates/DOFs. Does it make sense to use the default optimizer threshold value and error tolerance in a highly complex model as it would be for something simpler? Is it safe to assume that as you add more DOFs and muscles that the "Constraint Violation" value reported at the timepoint will naturally be higher? The constraint violations we see in our failures is often very small, like the one above. We've seen previously that when we get really low constraint violations (even though SO fails), the forces and loading values that come out look pretty realistic. The higher the constraint violation, the further it seems to not be anywhere close to a valid solution?

Thanks in advance for any thoughts and guidance, and sorry for the length! Regards.

Brett

Looks like you've done a ton of work to understand your model and problem. I haven't worked with a model like this, but I'll try to give my best guesses:

1. I imagine that both your solutions that work and solutions that "fail" are both close to the constraint boundaries, and that since these constraint violations are pretty low, it might just be some "unlucky" solutions. I don't know your model exactly, but my guess is that there are lots of bodies with small (low) mass and inertia values, which might also contribute to this. This might also lead to some of these issues since these small masses could cause the system to be "stiff" since even small-ish forces can cause large accelerations on bodies with small masses/inertias, and the solver could have trouble since the system is so sensitive to force changes. As you mentioned, adding reserve actuators could help to "fix" these violations, or locking some joints if they are less important to your problem could help too.

2. This is a question of validation. It's an interesting point that perhaps the default constraints are too small for your problem. It sounds like some kind of sensitivity analysis might be helpful to help choose a good tolerance, and it sounds like you have also done some of the more important steps on validation by comparing back to some real force values. You might also find some other ideas about validation from this paper: https://nmbl.stanford.edu/publications/ ... ks2015.pdf