Hello,
According to the documentation the force in the parallel elastic element is not considered during static optimization. Does anybody know the reasons, why the the forces in the PEE is neglected and is there a possibility to include it?
Any answer would be highly appreciated!
Why does static optimization does not consider the force in the parallel elastic element
- dieter heinrich
- Posts: 7
- Joined: Sun Feb 14, 2010 6:08 pm
- Ton van den Bogert
- Posts: 166
- Joined: Thu Apr 27, 2006 11:37 am
Re: Why does static optimization does not consider the force in the parallel elastic element
That's a great question and I don't see a fundamental reason why it can't be done. You would need to know the elastic properties of the PEE and SEE, though.
If you want to use the fact that PEE forces exist but have no cost, you want a cost function J only based on the contractile element forces Fce, of the form:
J = sum( f(Fce) ) where the function f is stress squared, cubed, or whatever.
Use Fce = Fsee - Fpee to transform this to a problem where you find the muscle forces Fsee to minimize:
J = sum( f(Fsee - Fpee(Lm - Lsee(Fsee)) )
subject to the usual constraints R*Fsee = M and Fsee>0
where Fpee() and Lsee() are the force-length and length-force relationships of the elastic elements, assumed to be known functions. Lm is muscle-tendon length which Opensim can calculate from the joint angles so it's known.
That new cost function is still a function of the muscle forces Fsee, albeit more complex than in the traditional form where the second term is left out.
With a numerical optimizer, that problem should not be any harder than the original static optimization problem. However, the result will now depend on the assumed elastic properties so error can be introduced.
I have not seen this done before.
However I have seen previously modeled passive joint moments subtracted from M before doing the static optimization. The passive moments come from passive muscle properties, so this is somewhat equivalent. The difference is that this effectively uses a muscle model where the parallel elasticity spans the whole muscle (CE + SEE), not just the CE. So it's computationally easier. The answer may be close enough. I can find a reference if needed.
Ton van den Bogert
If you want to use the fact that PEE forces exist but have no cost, you want a cost function J only based on the contractile element forces Fce, of the form:
J = sum( f(Fce) ) where the function f is stress squared, cubed, or whatever.
Use Fce = Fsee - Fpee to transform this to a problem where you find the muscle forces Fsee to minimize:
J = sum( f(Fsee - Fpee(Lm - Lsee(Fsee)) )
subject to the usual constraints R*Fsee = M and Fsee>0
where Fpee() and Lsee() are the force-length and length-force relationships of the elastic elements, assumed to be known functions. Lm is muscle-tendon length which Opensim can calculate from the joint angles so it's known.
That new cost function is still a function of the muscle forces Fsee, albeit more complex than in the traditional form where the second term is left out.
With a numerical optimizer, that problem should not be any harder than the original static optimization problem. However, the result will now depend on the assumed elastic properties so error can be introduced.
I have not seen this done before.
However I have seen previously modeled passive joint moments subtracted from M before doing the static optimization. The passive moments come from passive muscle properties, so this is somewhat equivalent. The difference is that this effectively uses a muscle model where the parallel elasticity spans the whole muscle (CE + SEE), not just the CE. So it's computationally easier. The answer may be close enough. I can find a reference if needed.
Ton van den Bogert
- Dimitar Stanev
- Posts: 1096
- Joined: Fri Jan 31, 2014 5:14 am
Re: Why does static optimization does not consider the force in the parallel elastic element
Hi,
A very good question and very good answer as well. Ton I was curious if the optimization can be solved efficiently (less iterations to converge by IPOPT) as follows:
minimize f(am) w.r.t. am
s.t. R * fm(am) = tau
0 <= am <= 1
where fm(am) = fmax * (am * fl * fv + fpe) * cos(alpha)
The fl, fv, fpe and cos(aplha) are calculated without solving the muscle dynamics, ignoring tendon compliance. Do you think that this would be a good approach?
A very good question and very good answer as well. Ton I was curious if the optimization can be solved efficiently (less iterations to converge by IPOPT) as follows:
minimize f(am) w.r.t. am
s.t. R * fm(am) = tau
0 <= am <= 1
where fm(am) = fmax * (am * fl * fv + fpe) * cos(alpha)
The fl, fv, fpe and cos(aplha) are calculated without solving the muscle dynamics, ignoring tendon compliance. Do you think that this would be a good approach?
Last edited by Dimitar Stanev on Wed Apr 29, 2020 11:48 am, edited 1 time in total.
- dieter heinrich
- Posts: 7
- Joined: Sun Feb 14, 2010 6:08 pm
Re: Why does static optimization does not consider the force in the parallel elastic element
Hi,
thanks very much for the detailed answer and the very interesting approach to include the force in the PEE.
Dimitar's approach would be a straight forward extension of the present apprach implemented in OpenSim based on ignoring tendon compliance. However, this option is currently not available and I was wondering about the possible reasons why this option is not available in the static optimization framework.
Any further answer would be highly appreciated!
thanks very much for the detailed answer and the very interesting approach to include the force in the PEE.
Dimitar's approach would be a straight forward extension of the present apprach implemented in OpenSim based on ignoring tendon compliance. However, this option is currently not available and I was wondering about the possible reasons why this option is not available in the static optimization framework.
Any further answer would be highly appreciated!
- Ton van den Bogert
- Posts: 166
- Joined: Thu Apr 27, 2006 11:37 am
Re: Why does static optimization does not consider the force in the parallel elastic element
Dimitar presented an elegant extension of what is already in Opensim, but as Dieter said, this requires a rigid tendon, so that the fiber velocity can be calculated from the joint motion. The tendon compliance is probably not critical, although there is evidence that the fiber velocity is sometimes much lower than the muscle-tendon velocity (e.g. Kurokawa's ultrasound data https://physiology.org/doi/full/10.1152 ... 00219.2003).
Dimitar's answer made me think of an improvement of my proposed approach which takes tendon compliance into account.
First, I forgot pennation angle. For now, let's keep Fsee as the unknowns, and a cost function based on Fce. The cost function is still a static function of the unknowns Fsee, I think. Let's calculate it in steps:
Is it worth while to have this extra complexity? Predictions would need to be compared to EMG. My prediction: neglecting the parallel elastic element is probably fine, because there are other issues with static optimization and muscle modeling that create larger errors. And neglecting the parallel elastic element may even be better than including it with an imperfect model of the passive elements that can introduce error.
That may well be the reason why Opensim does not have this capability. Results become more sensitive to modeling errors. It's already questionable whether the available "force-length-velocity relation" option gives improved results. Antoine Falisse did a sensitivity analysis in his paper from last year (https://journals.humankinetics.com/view ... e-p496.xml) and found very little difference (Supplementary material, figures 5-8). Below an example. Red is ideal force generators, black is with force-length-velocity properties. This is walking.
Ton
Dimitar's answer made me think of an improvement of my proposed approach which takes tendon compliance into account.
First, I forgot pennation angle. For now, let's keep Fsee as the unknowns, and a cost function based on Fce. The cost function is still a static function of the unknowns Fsee, I think. Let's calculate it in steps:
- calculate Lsee from Fsee using series elastic element model
- solve Lce from: Lce*cos(phi) = Lm - Lsee, where phi comes from the constant-volume assumption: sin(phi) = sin(phiopt)*Lceopt / Lce. That becomes a quadratic equation for Lce which has an analytical solution.
- calculate Fpee from Lpe (=Lce) using parallel elastic element model
- calculate Fce = Fsee/cos(phi) - Fpee
- calculate cost function from Fce
Is it worth while to have this extra complexity? Predictions would need to be compared to EMG. My prediction: neglecting the parallel elastic element is probably fine, because there are other issues with static optimization and muscle modeling that create larger errors. And neglecting the parallel elastic element may even be better than including it with an imperfect model of the passive elements that can introduce error.
That may well be the reason why Opensim does not have this capability. Results become more sensitive to modeling errors. It's already questionable whether the available "force-length-velocity relation" option gives improved results. Antoine Falisse did a sensitivity analysis in his paper from last year (https://journals.humankinetics.com/view ... e-p496.xml) and found very little difference (Supplementary material, figures 5-8). Below an example. Red is ideal force generators, black is with force-length-velocity properties. This is walking.
Ton
- Attachments
-
- FigS5_small.jpg (176.37 KiB) Viewed 455 times