You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an edge case issue, but I wanted to shed some light on it in case anyone runs into a similar problem. I was writing some scripts to execute the ScaleTool iteratively to make models representing each participant in the data set.
I began with the sample marker set available in the Scale testing application. This file contains a <defaults> section although I cannot definitely determine what it is used for (if it is used at all).
I noticed a very strange error when writing the iterative code that the first iteration runs successfully and then all subsequent iterations fail with the following error:
[error] Property 'min_control' has an invalid value.
(details: Minimum control cannot be less than minimum activation).
In Object 'glut_med1_r' of type Thelen2003Muscle.
Thrown at Thelen2003Muscle.cpp:108 inextendFinalizeFromProperties().
Solution
I found that the short term solution is to completely remove the <defaults> tag and all of its children from the MarkerSet.xml file. This allows the ScaleTool to be executed repetitively without error.
Interestingly, if the "broken" file (with the <defaults> tag) is loaded at all during the programs lifetime, all subsequent calls will fail. Even when the "working" file is loaded later, it isn't enough to fix whatever the "broken" file broke. It seems that there is some kind of caching or memory management that is causing this.
Do you have any ideas on what could be causing this behavior @nickbianco@aymanhab?
I am using the gait2392_thelen2003muscle.osim model and a marker set corresponding to the Kuopio Gait Dataset. The issue may also persist with other models and marker sets but I have not tested that yet.
Code snippet
std::unique_ptr<OpenSim::Model> model;
for (int i = 0; i < iterations; i++) {
try {
// Works fine
std::cout << "\nInitializing Model Regularly!" << std::endl;
std::string modelPath =
SimTK::Pathname::getAbsolutePathnameUsingSpecifiedWorkingDirectory(_pathToSubject, fileNameModel);
model = std::make_unique<OpenSim::Model>(OpenSim::Model(modelPath));
model->initSystem();
std::string markerSetPath =
SimTK::Pathname::getAbsolutePathnameUsingSpecifiedWorkingDirectory(_pathToSubject, fileNameMarkerSetBroken);
std::cout << "Loading marker set from: " << markerSetPath << std::endl;
// This will work the first time around the loop but cause the error on all subsequent iterations
OpenSim::MarkerSet markerSet(markerSetPath);
model->updateMarkerSet(markerSet);
std::cout << "[" << i << "] Iteration Completed!" << std::endl;
}
catch (const OpenSim::Exception& x)
{
std::cerr << x.what() << std::endl;
}
}
The text was updated successfully, but these errors were encountered:
Problem
This is an edge case issue, but I wanted to shed some light on it in case anyone runs into a similar problem. I was writing some scripts to execute the
ScaleTool
iteratively to make models representing each participant in the data set.I began with the sample marker set available in the Scale testing application. This file contains a
<defaults>
section although I cannot definitely determine what it is used for (if it is used at all).I noticed a very strange error when writing the iterative code that the first iteration runs successfully and then all subsequent iterations fail with the following error:
Solution
I found that the short term solution is to completely remove the
<defaults>
tag and all of its children from theMarkerSet.xml
file. This allows theScaleTool
to be executed repetitively without error.Interestingly, if the "broken" file (with the
<defaults>
tag) is loaded at all during the programs lifetime, all subsequent calls will fail. Even when the "working" file is loaded later, it isn't enough to fix whatever the "broken" file broke. It seems that there is some kind of caching or memory management that is causing this.Do you have any ideas on what could be causing this behavior @nickbianco @aymanhab?
Reproduction
The full reproduction code is available here.
I am using the
gait2392_thelen2003muscle.osim
model and a marker set corresponding to the Kuopio Gait Dataset. The issue may also persist with other models and marker sets but I have not tested that yet.Code snippet
The text was updated successfully, but these errors were encountered: