Slover is very slow

[imihasan]

@itbellix I have run a quick profiler and it sounds that the problem is summarized as follows

Overall Summary

findInducedAccelerationsForceMomentsGH

sqpInterface (Called by fmincon)

org.opensim.modeling.Model

[itbellix]

Hi @imihasan, thanks for reporting this! I got caught up with other things, so cool you identified this already :)

It is also evident that the call to findInducedAccelerationForceMomentsGH is taking long, but I am not sure that reducing its time is so straightforward... So probably trying a new solver might help, I should be able to test OSQP this Friday, and I will let you know!

[imihasan]

@itbellix

I did some edits to induced accelerations function that helped reducing the computational time from ~1320 s to ~750 s. The changes were commenting out import org.opensim.modeling.; to be called every time the function is called. But this limited me to use set reserve actuator forces instead of useControls because acts{k}.setControls(Vector(1, x(k)), modelControls); would require calling org.opensim.modeling.; at every instant the function is called. And that was strange because using forces instead of controls gave me substantially different results from using controls. Do you have any explanation for this?

My thought currently is to exclude matching accelerations of coordinates that may not contribute to the muscle redundancy problem, for instance, locked coordinates. I'm thinking also to include the spinal and neck coordinates up to the inverse kinematics stage and exclude in matching accelerations. I'm not sure how would this affect the muscles eventually.

[imihasan]

@itbellix It sounds that excluding spine, neck and locked coordinates from the optimization problem substantially improved the speed. Now the solver roughly finds a solution in 300 seconds compared to ~1320 minutes before edits.

It can even find a solution faster if I use force as an input to reserve actuators instead of controls. But this leads to a totally different solution, which I don't have an explanation for so far.

[itbellix]

Hi @imihasan! Okay, I think you really found a nice way to do this. I am not exactly sure about the different behaviour between controls and forces for the reserve actuators... Not sure if you want to push your modified code to the repo so I can also try to get a better idea of where the difference might come from.

A thought is that the forces that, when the controls are used, their value is expected to be quite low (as the total force produced by the reserve actuator will be force = control*optimal_force (where the optimal force is a property of the actuator itself). So, in a sense, if you optimize directly on the force values, you loose some uniformity of the problem, as some optimization variables will be activations (values in the [0,1] interval) and other forces (potentially much higher, like 500 N or more). This is generally making it harder for the solver.

[itbellix]

If what I said above is indeed the problem, we could solve it by sort of "mimicking" how the controls work, but without actually using them. So we could extract from the model these optimal_force for each actuator, and use it to scale the value of force that gets commanded to the actuator directly when setting the actuator forces.

[imihasan]

@itbellix That actually adds an insight about the problem. That could be a solution, I don't know. I'm not sure either about the computational speed in that case, however, I think it's worth to try. I also wanted to point out that when I use controls, the muscle activation of specifically the subscapularis looks weird.

I'm not sure about the reason of this so far, what do you think?

I have pushed all the final edits to the repository, have a look and let me know how things work with OSQP.