simtk.org

Hi Nick,

Thank you for elaborating!
I compared the result (of a zero iteration optimization) both with & without downcasting, there was no difference in my situation. After looking back at the example, I suppose downcasting is necessary because the example model has the muscles under "components", whereas my model doesn't.

I'm still having some trouble assigning the outputs manually ('metabolic_cost/|total_metabolic_rate') didn't work (also not with //|total_metabolic_rate). This is not a problem when using the Bhargava probe, because the regex parser does find the output when I add '.*' in front of it. When I try this with the Umberger probe, it's not finding the correct output, however.

I added each muscle similarly (but with the different muscle parameters that the Probe requires as an input), and then called addProbe (if I write the model, the probe looks to be added to the probeSet). If I call outputPaths.add('.*metabolic_cost_TOTAL'), no output is detected. Is this not the correct output of the probe? This is what I found browsing the outputs of the probe via the api (I couldn't find them in the documentation, but perhaps I looked in the wrong place).

Cheers,
Pasha

I suppose downcasting is necessary because the example model has the muscles under "components", whereas my model doesn't.

Ah, good point. I think you might be right.

I'm still having some trouble assigning the outputs manually

Are you sure you have the right path to the component. You can check the paths to all components in a model by using the following command:

If I call outputPaths.add('.*metabolic_cost_TOTAL'), no output is detected

Looking at the documentation for Umberger2010MuscleMetabolicsProbe, I don't see an output call 'metabolic_cost_TOTAL'. The only output I see is called 'probe_outputs', which is type SimTK::Vector, which we unfortunately don't support with the Moco analysis utilities. But you could always compute the Outputs yourself by converting the MocoSolution to a StatesTrajectory and accessing the Probe directly.

-Nick

Hi Nick,

Yeah you're correct - "metabolic_cost_TOTAL" is what you get when you call '.getProbeOutputLabels()' - I hadn't realized this isn't a regular Output.

But you could always compute the Outputs yourself by converting the MocoSolution to a StatesTrajectory and accessing the Probe directly.

You mean feeding each state to 'computeProbeInputs(state)', yes? I was confused by the name of this function, but it looks like it outputs the total metabolic power.

Are you sure you have the right path to the component. You can check the paths to all components in a model by using the following command: model.printSubcomponentInfo();

This is strange - I'm 100% sure that I've used this in the past to get a nice overview of my model hierarchy - but it doesn't seem to work in my current installation any more. I'm calling it verbatim (but without ';') in a model that definitely exists and works - but there are no outputs in my Matlab console (and also no error message). Are there conflicts that can occuring when setting up the matlab API that could prevent this from working?

Cheers,
Pasha

Hi Pasha,

I think you want 'getProbeOutputs(state)', which returns a SimTK::Vector. You want the element of that vector using the index that returned "metabolic_cost_TOTAL" from 'getProbeOutputLabels()'.

The 'printSubcomponentInfo()' is probably Matlab specific. Certain versions of Matlab have issues with routing information to the Matlab console.

-Nick

Hi Nick,

Sorry it took a while for me to get around to trying this. I gave it a shot, but the following code (reproducibly) crashes my Matlab:

[First perform an optimization with a model which has an Umberger probe attached, giving you a MocoTrajectory named Traj]
I'm not sure what I'm doing wrong here - perhaps I'm not adding the probe to the model correctly? I'm basically doing the same as in the example (create the Probe, loop through the muscleset and call probe.addMuscle( name, twitch ratio, muscle mass), and then call model.addProbe(probe), and model.finalizeConnections). The probe does show up in the model xml if I write the model, but I'm not sure what a correctly added Umberger probe looks like, so I wouldn't know if what I've done is incomplete.

Have you got any ideas?
Thank you!
Pasha

Hi Pasha,

Does Matlab crash for any method of the Umberger probe that takes a SimTK::State, or just getProbeOutputs()?

-Nick

Hi Nick,

I've diagnosed the problems. First off, I should have been calling getProbeInputs(), not getProbeOutputs, but that wasn't causing the crash. What caused the crash was: "state = Traj.exportToStatesTrajectory(model).get(0) %get the first state from the trajectory". For some reason, if you use "state" acquired in this way for the call to the probe, it causes a crash. What worked for me was: statestraj = Traj.exportToStatesTrajectory(model); state = statestraj.get(0).

For anybody interested in doing a similar comparison, here's how I coded it:

Ah, yes. For some reason, chaining methods like that sometimes causes crashes in Matlab and Python.

Glad you figured it out!

Hi Nick,
I'm interested in minimizing metabolic costs during 2D gait using Umberger2010MuscleMetabolicsProbe.

After reviewing the discussion here, I'm uncertain if the current Moco framework can facilitate this.

Since I'm new to Moco, I would greatly appreciate any tips or ideas on how to model it. Specifically, whether to use custom goals or output could be useful? Does it require smoothed version of Umberger2010MuscleMetabolics?

Thanking you.
-Milan

Hi Milan,

Moco will allow you to use any ModelComponent that provides an Output, but if the component that does not provide a smooth function in the optimization, it may not converge reliably. Unfortunately, Umberger2010MuscleMetabolicProbe does not provide an Output for total metabolic cost and can only be used in post-hoc analysis of a simulation result.

Is there a reason you need this model specifically over the Bhargava model? In practice, the Bhargava model performs similarly well to other metabolics models, and might even be a bit faster in optimization compared to the Umberger model.

Best,
Nick