Hi all,
I'm doing static optimization for gait trials,
but rarely, static optimization gives 1.#QNAN in a frame.
(e.g. in the messages window,
time = 2.74 Performance =0.379839 Constraint violation = 2.15358e-012
time = 2.75 Performance =0.370833 Constraint violation = 4.20757e-012
time = 2.76 Performance =0.0380169 Constraint violation = 1.#QNAN
time = 2.77 Performance =0.373046 Constraint violation = 1.0988e-012
time = 2.78 Performance =0.389789 Constraint violation = 6.96274e-012)
What is the meaning of 1.#QNAN at time = 2.76?
And is it OK if I fix this frame by averaging the result of time = 2.75 and 2.77?
(It seems that results of all other frames are OK)
Thanks,
Lee, Sang Jun
"1.#QNAN" in static optimization
- Ayman Habib
- Posts: 2248
- Joined: Fri Apr 01, 2005 12:24 pm
Re: "1.#QNAN" in static optimization
Hi,
StaticOptimization works internally by solving the InverseDynamics problem, then trying to solve the redundancy problem for actuators/muscles using the accelerations from the InverseDynamics solution as a constraint (these are the constraint violations reported). The NAN you see is a sign that the optimizer couldn't solve for muscle forces while enforcing the InverseDynamics solution. This likely happens when there's noise in the data or if there's sudden jump in accelerations in one frame. I'd look into the data further, solve InverseDynamics and see if there's something completely off for the problematic frame, then probably fix/interpolate the data if something looks wrong with it.
Since StaticOptimization is done on a frame by frame basis, there is no assumption about continuity of the solution.
Hope this helps,
-Ayman
StaticOptimization works internally by solving the InverseDynamics problem, then trying to solve the redundancy problem for actuators/muscles using the accelerations from the InverseDynamics solution as a constraint (these are the constraint violations reported). The NAN you see is a sign that the optimizer couldn't solve for muscle forces while enforcing the InverseDynamics solution. This likely happens when there's noise in the data or if there's sudden jump in accelerations in one frame. I'd look into the data further, solve InverseDynamics and see if there's something completely off for the problematic frame, then probably fix/interpolate the data if something looks wrong with it.
Since StaticOptimization is done on a frame by frame basis, there is no assumption about continuity of the solution.
Hope this helps,
-Ayman