Mismatching Array Dimensions during Muscle Tendon Length Initialization and Optimization

[Maximillian Diaz]

We are currently looking to run muscle-tendon length initialization and personalization on some muscles that cross 10 joints within the wrist, thumb, and index finger of the Mobl-Arms models. To get the pipeline running we are using three passive movement tasks and two active hand tasks (one trial each to start). It seems we are running into issues were the data being pulled/calculated during the pipelines are resulting in mismatching array dimensions.

This first case is when we flag the muscle-tendon length initialization are true within the MTP settings file. Our inverse dynamics, inverse kinematics, and muscle analysis files have the corresponding columns (or files for muscle analysis) for all 48 joint coordinates found in the combined upper limb Mobl-Arms and Mobl-Arms hand and wrist models. The current MatLab error is a result of modeledValues.passiveModelMoments being a 3x41x101 double and columnsWithAllZeros being a 3x48 logical.
Currently wondering if this is a coding fix, remove excess joints from input files, or model issue. Error and experimentalData variable and modelValues variables below.

MTPLengthError.png (32.37 KiB) Viewed 1206 times

MTPLengthErrorExperimetnal.png (51.05 KiB) Viewed 1206 times

MTPLengthErrormodelvalues.png (10 KiB) Viewed 1206 times

The second case is similar case in that if we skip the length initialization (flag false in settings file) and just run the MTP pipeline we run into a mismatched array dimension. In this case it seems to be that the experimentalData.inverseDynamicsMomements are a 2x8x101 and the modelValues.muscleJointMoments are 2x10x101. The number 8 stands out here since that is the number of EMG channels we are collecting during the two tasks, which relates to an emgDataExpanded of 17 muscles, but all 10 joints are crossed by at least one muscle (either an intrinsic or extrinsic hand muscle). Error and experimentalData variable and modelValues variables below.

MTPError.png (44.05 KiB) Viewed 1206 times

MTPErrorExperimetnal.png (591.99 KiB) Viewed 1206 times

[Spencer Williams]

Hi, I noticed that your 'momentArmsCoordinateNames' is 1x46, but it should be 1x48 like the coordinate names. I think there could be a parsing issue here.

Could you reply with:

• Your workspace saved into a .mat file at the time of each error

• The column names from a passive and an active inverse dynamics file given as inputs

The fact that both issues involve an incorrect number of coordinates included in moment data makes it seem like there is an issue with parsing moment arm data.

Also, have you used our preprocessing script to format your files? Your EMG data have 101 time points and numPaddingFrames is 0, which will cause issues when MTP tries to optimize the electromechanical time delay. You'll want to make sure the EMG data files have extra frames on each side so we can adjust the delay. In the last part of preprocessing, this means that your trial start and end times should not match the start and end of an input EMG file.

Thanks!

[Maximillian Diaz]

Hi Spencer,

A parsing error would make sense (I ran into a few when first trying to let the pipeline auto determine trial prefixes). I've attached zip files that have the workspaces associated with each function that go with the error messages that I get when placing a breakpoint at the failing lines for NMSM v1.1 (along with the screen shot of the error message). Sorry that its so many zips (and replies), I ran into file size issues, the forum not accepting plain .mat files, and the 5 attachments limit.

As for the EMG data, we are not using the preprocessing script for our file formatting. We have muscle specific MVCs to perform EMG normalization of fine wire EMG, so that part of the script wasn't going to be usable for our case. We also already had python scripts for task cropping, time normalization, and time syncing for other analysis tied to the data, so we are trying to stay consistent with our methods. I honestly must have missed that the example EMG files had more than 101 time points (I figured everything was 101 based on the getting started page). Any recommendations on the number of extra frames to add on each side, or is there a minimum number?

[Maximillian Diaz]

Delay post of second set of files due to forum limiting posting time

[Maximillian Diaz]

Delayed post of last set of files

[Spencer Williams]

Thanks for the sending the data! Most of the problems are with how we parse inputs for MTP, and we'll work on patching those. For now, I have a couple of workarounds that should let you run MTP on the current verion.

For the Length Initialization error, there are seven coordinates missing from the moment arms. Five of your passive coordinates have "_force" in their load name (deviation_force, flexion_force, t_x_force, t_y_force, t_z_force). If you replace the "_force" in these column labels with "_moment", that should fix five of the missing moment arm coordinates.

The two remaining coordinates are "wrist_hand_r1" and "wrist_hand_r3". These are not included in your moment arms coordinate names list, which has 46 elements instead of the 48 in your ID column list. Could you make sure there are moment arm files for those coordinates? If you don't find any issues with your input files, could you place a breakpoint on line 64 of parseMuscleTendonPersonalizationSettingsTree.m (the line calls reorderPreprocessedDataByMuscleNames) and send me a .mat file of your workspace at that point?

The issue you saw with MTP after skipping Length Initialization should also be fixed if you change the "_force" suffixes to "_moment". Two of your 10 MTP coordinates are "deviation" and "flexion", so I think the "_force" suffix was the problem here too.

With padding frames, we normally add enough frames to EMG data to cover at least 200 ms before the start and after the end of the trial, adding the same number of padding frames to all included trials. I would add 5 frames to each side of your EMG data.

I also noticed that your groupedMaxNormalizedFiberLength is longer than expected (38) when it should match the number of muscles included (17). It looks like this happened because during parsing we assumed that included muscles would be listed together in the .osim model file. Your first and last muscles included in normalized fiber length groups span 38 muscle indices in the model. For now, I think you can get around this issue by rearranging the muscles inside the .osim model file so that the 17 muscles you are using with MTP don't have any other muscles between them.

Thanks for helping us find these issues! Let me know if you have any other problems running MTP.

[Maximillian Diaz]

Hey Spencer,

This was a huge help. Changing the '_force' roots to '_moment' worked for running MTP with and without Length Initialization. The wrist_hand_r1 coordinates was an error with our preprocessing code and how it was parsing and reconstructing names, so the file existed but with the wrong name.

After fixing the missing moment arm for the seven coordinates the groupedMaxNormalizedFiberLength variable size was an issue. To fix it I did what you suggested and listed the muscles contained in the number of muscles included (17) (got them via the muscleTendonColumnNames variable) in order within the osim file. However, I also had to add all the muscles contained within a NormalizedFiberLengthGroup after the 17 muscles. I placed them at the end of the list of model muscles, so no clue if placing the list at the top, middle, or bottom of the model muscles matters.
We have successfully gotten the Length Initialization and MTP to run and have the constraints satisfied during optimization. Now it just seems to be issues associated with saveMuscleTendonPersonalizationResults. I may have a solution to one of the errors that I'm gonna explore, but will post another topic about the issue/bug once I've done some initial exploration. Thanks again for all your help.