Can we optimize parameter of FiberForceLengthCurve with MOCO

[Nicholas Bianco]

Hi Sepehr,

I think I've found the problem. The property 'tendon_strain_at_one_norm_force' is used to initialize an internal variable: https://github.com/opensim-org/opensim- ... e.cpp#L161.

The function where this code lives, 'extendFinalizeFromProperties()', is called when you call 'initSystem()' on the model (or 'finalizeFromProperties()'). But, you probably have the MocoCasADiSolver 'parameters_require_initsystem' disabled for performance, so while 'tendon_strain_at_one_norm_force' is being updated, it's not having any effect on the problem since the internal variable is never updated.

The simplest solution to avoid enabling 'parameters_require_initsystem' is to remove this internal variable and replace that variable with the expression containing the property everywhere in the model.

Creating an issue on GitHub to capture this now.

-Nick

[Sepehr Ramezani]

Hi Nick,
Thanks,
I'm trying to wrap up the project before a dead line, I was wondering if I can apply changes in my fork and try to test it in my system (I have my code in MATLAB). Presumably after fixing the bug in my fork I need to do extra steps to update the API (because I'm running my code with MATLAB) Since this is my first time doing this is there any guidance how can I do that? Or any other solution?
Best
Sepehr

[Nicholas Bianco]

Hi Sepehr,

If you have your own fork with a fix, then you won't have to change anything related to the Matlab interface, but you will need to create a new build (including the bindings) locally and install the build via the normal procedure for Matlab.

There's general instructions for building from source on the main Github repo, but let me know if you have any specific questions.

Best,
Nick

[Sepehr Ramezani]

Hi Nick,
I have learnt how to build from source code. Do you have any recommendation what exactly should change in source (DeGrooteFregly2016Muscle.cpp or other files) to solve this problem?

Best,
Sepehr

[Nicholas Bianco]

Hi Sepehr,

As I said in my previous post, you need to remove the intermediate variable that defines the tendon stiffness everywhere in the model: https://github.com/opensim-org/opensim- ... e.cpp#L161.

In other words, replace m_kT everywhere in the code with the expression defined above. Or at least create a local variable for kT everywhere it is used (to keep the code clean).

Should be pretty straightforward. While you're at it, it would be good to remove all of the other intermediate variables that rely on muscle properties to enable muscle parameter optimization for those parameters too.

Does that all make sense?

[Sepehr Ramezani]

Hi Nick,
Thanks, I changed the intermediate parameter in the DeGrooteFregly2016Muscle.h (here) and MOCO_parameter successfully updated the internal variable (tendon_strain_at_one_norm_force) without enabling set_parameters_require_initsystem.
However, I got a large error of the estimation of tendon_strain_at_one_norm_force. I'm trying to play with optimization parameters to see if I can get it better. I would appreciate it if you have any suggestion.
I'm also cleaning the code (defining local variable) and looking for other muscle's parameters with same problem to report it here or fix it on my fork.
Thanks
Sepehr

[Nicholas Bianco]

Hi Sepehr,

What do you mean by large error of estimation of tendon_strain_at_one_norm_force? Did the solution not converge to the solution you would expect, or did the the problem violate the parameter bounds somehow?

Either way, sounds like an encouraging first step! It is a little hard to parse the code changes right now, but after you clean up the code and take a look at the other parameters in the model we could talk about you submitting a PR for the changes. We usually create tests for any code changes, so if you have a simple problem that solves quickly and verifies that these parameters change that would be a valuable contribution too.

-Nick

[Sepehr Ramezani]

Hi Nick,
Sorry for delay in response, I'm dealing with Ph.D. stuff right now.

What do you mean by large error of estimation of tendon_strain_at_one_norm_force? Did the solution not converge to the solution you would expect, or did the the problem violate the parameter bounds somehow?

Solution converged. Since I have StateTracking problem, I compared the states from FD of the model with optimized parameter and the reference states and it was very close. After looking more deeply in the problem I think I found the source of error. It seems my Task/Trial was not designed properly to estimate that specific parameter, in the other meaning state was not sensitive enough to those parameters. For example, if you run active knee flexion and extension in your experiment, this data is not enrich enough to estimate the maximum-isometric-force of hip flexros. I'm working on getting better data and try the optimization again.

Either way, sounds like an encouraging first step! It is a little hard to parse the code changes right now, but after you clean up the code and take a look at the other parameters in the model we could talk about you submitting a PR for the changes. We usually create tests for any code changes, so if you have a simple problem that solves quickly and verifies that these parameters change that would be a valuable contribution too.

I was working on creating a simple problem for test other parameters and faced with something else. I created more advanced example of Tug of War here with 2 Degroote muscles and trying to optimize most parameters. I figured out when muscle dynamic is set on implicit, the forward dynamic (I used Manager() in the script) does not make sense. It seems it ignores prescribed control. I'm not sure what is the problem. Can you run the .m file from here or download MSD.osim from here to check it. This code/file dose not need any out source file so you should be able to run it pretty straight forward. You are welcome to change the muscle dynamic (implicit/explicit) to see the differences.

Best,

Sepehr

[Nicholas Bianco]

Hi Sepeher,

I figured out when muscle dynamic is set on implicit, the forward dynamic (I used Manager() in the script) does not make sense.

Running forward dynamics with a solution obtained using implicit muscle dynamics won't work because integrators offered by the Manager tool are explicit integrators (i.e., they won't work with implicit dynamics equations), and the muscle isn't currently set-up to work with time-stepping integrators when in implicit mode.

If you want to do forward simulations with a Moco solution, you'll need to generate a solution that has all dynamics (skeletal and muscle) in explicit form. If you have a converged solution using implicit tendon dynamics with DeGrooteFregly2016Muscle, you should be able to use that solution as an initial guess to a problem with the same muscle using explicit dynamics. I have been able to get this to work for my own simulations recently.

-Nick