Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix live muscle plotter irreversibly changes to an error message on muscle realization error #939

Open
adamkewley opened this issue Nov 1, 2024 · 1 comment

Comments

@adamkewley
Copy link
Collaborator

adamkewley commented Nov 1, 2024

Reported by Ashleigh W

So, I have a model with muscles. The muscles have paths and wrapping surfaces. The parameters are at the default values (i.e, fiber lengths etc).

I was plotting moment arms against joint coordinates - no motions included. I have three rotations in the hip. When I plotted the moment arm for Muscle A against these three coordinates, there was no problem. Everything worked as expected. However, when I tried to plot Muscle B, it would only plot for two of the coordinates but I received a strange warning message (screenshot attached) when plotting against one of the coordinates, but the warning was related to Muscle A instead.

The error message was confusing because it was (1) about a different muscle rather than the one I was trying to plot and (2) it was mentioning velocity for a muscle that was at the default parameter values. Furthermore, Muscle A plotted without any issues, but it was affecting the plotting of other muscles around certain joint coordinates. If I tried to make any changes, the plot would appear for a split second before the error message appeared instead - eventually this led to opensim creator fully crashing. I eventually deduced that if I remove the wrapping surface for Muscle A, then all problems solve themselves.

thumbnail_osc_error

@adamkewley
Copy link
Collaborator Author

This issue is because of how the muscle live-plotter currently works. It currently:

  • Takes a user-selected coordinate
  • Takes a user-selected output (e.g. muscle moment arm)
  • Sends the coordinate range, output extractor (function), and model to a background (simulator) thread
  • The simulator thread steps through (permutes) the coordinate, re-realizes the entire model, then pumps the resulting model + state through the output extraction function
  • If an error occurs during this process, it's propagated to the UI thread via an exception, which the UI dumps into the panel without crashing/halting the rest of the UI rendering process

The reason AW sees an unexpected message is because the muscle being plotted isn't the muscle that causes the error. From a computational standpoint this maybe makes sense (it's just realizing the whole model, in case there's something else in the model that might affect the output, and it doesn't know enough about the output function to skip steps), but it's confusing for a user.

Further, the user might find it confusing that the plotter crashes, but playing around with the coordinate slider doesn't. The reason for the difference might be that the coordinate slider skips some finalization steps until the user lets go of the mouse (so that dragging the slider along can happen in realtime). The plotter always performs a full model realization etc. at each datapoint. So, to have the same bug as the plotter, the user would have to let go of their mouse when dragging the slider in the Coordinates panel at the exact same positions as the plotter is plotting.

Possible Solutions

  1. Tag the output extraction functions with relevant metadata, so that the simulator thread can perform a bare-minimum amount of work to plot the data. E.g. a moment arm extractor does not require adjusting the model or state.
  2. Use relevant tags/metadata to tell the simulator that the component that's producing the output that are being plotted (e.g. a muscle's force output) is not dependent on other certain other components (e.g. the muscle force is known to be independent of other forces, so it is safe to disable all other forces).
  3. Propagate error messages from the simulator thread through an error message channel that the UI then aggregates into relevant feedback (i.e. a popup, mark parts of the plot where an error was detected, etc.). Do not halt producing other datapoints.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant