DeGrooteFregly2016 muscle activation and deactivation speeds

[tvdbogert]

The activation dynamics is implemented exactly as in the 2016 paper, but this results in activation and deactivation happening at almost the same speed. The function f is intended as a "soft switch" between activation (a-e < 0) and deactivation (a-e > 0). But it's too soft, the value of f stays very close to 0.5 over the whole range of inputs (a-e ranging from -1 to 1).

I suspect that the tanhSteepness parameter should have been 10 instead of 0.1.

See:

opensim-core/OpenSim/Actuators/DeGrooteFregly2016Muscle.cpp

Line 208 in b4ba7ca

static const double tanhSteepness = 0.1;

I ran some simulations to see the response to a 1 Hz square wave excitation, and this confirms that activation and deactivation speeds are very similar.

I contacted Friedl for input, a few weeks ago, but received no reply yet.

[nickbianco]

Hi @tvdbogert, thanks for bringing this to our attention. Perhaps we could add a property so users could control the amount of smoothing applied by tanhSteepness.

[tvdbogert]

That would be a good solution.

For backward compatibility, you probably want to leave the default value as it is now, so previous results are reproducible, but allow users to change the value.

To make users aware of this issue, maybe put something in the documentation, saying it's recommended to change the value? Or generate a warning when the model is used with the default parameter value?

There is more to this issue though! When you have a substantial difference between activation and deactivation speeds (as intended), a cost function with squared excitation is no longer good, because it favors a solution with infinitely fast on-off switching of the excitation. Indeed that is what I see emerge during mesh refinement. That's not great for accuracy and solution speed of collocation methods. Instead, activation state should be used in the cost function. I'm working on a report about this and will share soon.

Does MOCO use excitation or activation in the effort cost?

[nickbianco]

For backward compatibility, you probably want to leave the default value as it is now, so previous results are reproducible, but allow users to change the value.

To make users aware of this issue, maybe put something in the documentation, saying it's recommended to change the value? Or generate a warning when the model is used with the default parameter value?

Agreed on all this.

Does MOCO use excitation or activation in the effort cost?

You can use MocoControlGoal for an excitation effort cost and MocoSumSquaredStatesGoal if you want an activation effort cost (or both if you want both). I don't think its clear to some users that MocoSumSquaredStatesGoal allows you do have an activation effort cost, I might consider a MocoActivationGoal or something similar.

Interested to read your report on this!