GOM

Dear AnyBody,

I have been modelling some data sets taken from a couple of quite
short individuals. Prior to running GOM I have set the scaling and
marker positions to fit those of the person I am modelling. I am
getting a problem when I run GOM, it seems to be reporting high
AbsSumKinerror and taken many iterations to run. When the GOM is
complete the model has been scaled disproportionately and the marker
positions seem to be worse than those set prior to the GOM. I have
uploaded a static model (c01static) as an example.

your thoughts would be greatly appreciated as always

best wishes

Peter

Hey Peter,

Without having looked at your model, it sounds like you are trying to optimize
the subject as well as the markers using a static trial. With the marker
optimization settings I gave you before, this is impossible. The SCALE solver in
GaitApplication2 is designed to optimize the length of segments as well as
marker positions over a dynamic trial, where the motion around the joint dofs
determines the placements of the markers and length of segments.

However, there are two ways out of this.

  1. Exclude the optimization of markers that can be used to determine the length
    of limbs from the optimization problem. This can be done in the
    DataForConfigFile.any by specifying optimization options “off off off” for those
    markers. In this case, it is very important that you place all markers correctly
    on the skeleton. This will then lead to the skeleton being scaled such that
    floating markers match the markers on the model as well as possible. Since the
    marker positions are rigidly attached to the skeleton, this will also give you
    the segment lengths. In your case, excluding both the knee and ankle markers
    from the problem in all three directions show do the trick (besides the ones
    that were already locked).

  2. Exclude the optimization of segment lengths from the problem. This you can
    also do in the DataForConfigFile.any by changing the SCALEMAN options to “off”.
    In this case, you will have to give the correct segment lengths and the markers
    will then be optimized to match those lengths as well as possible. If you choose
    this option, then there is a few markers that you can optimize that were
    switched off before.

If it still gives you the wrong solution, then you are in the unlucky situation
that GaitApplication2 decides to pick one of the saddle point solutions that do
exist. This will show up as one or more of the segments being as far away from
the markers as possible. The solution here is to move the man closer to the
markers using the Mannequin.any file until it gives you the solution you want.

I hope this answers your question.

Best regards
Michael Skipper Andersen The AnyBody Research Project

To: anyscript@yahoogroups.comFrom: peter.worsley@yahoo.co.ukDate: Thu, 9 Oct
2008 10:12:40 +0000Subject: [AnyScript] GOM

Dear AnyBody, I have been modelling some data sets taken from a couple of
quiteshort individuals. Prior to running GOM I have set the scaling andmarker
positions to fit those of the person I am modelling. I amgetting a problem when
I run GOM, it seems to be reporting highAbsSumKinerror and taken many iterations
to run. When the GOM iscomplete the model has been scaled disproportionately and
the markerpositions seem to be worse than those set prior to the GOM. I
haveuploaded a static model (c01static) as an example. your thoughts would be
greatly appreciated as alwaysbest wishesPeter


Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE

[Non-text portions of this message have been removed]

Hi Michael,

sorry I didn’t explain myself very clearly. I was using the static trial to find
initial seg lengths and marker positions for my dynamic trials I have collected.
It was not my intention to run GOM on the static trial.

The GOM appears to be scaling the dynamic trials indifferently. I’ll put an
example up (gait1) in the file section. The error seems to start with increased
anterior rotation at the pelvis and continue down to the thigh and shank
scaling.

many thanks

Peter

— On Thu, 9/10/08, Michael Skipper Andersen <msandersen60@hotmail.com> wrote:
From: Michael Skipper Andersen <msandersen60@hotmail.com>
Subject: RE: [AnyScript] GOM
To: anyscript@yahoogroups.com
Date: Thursday, 9 October, 2008, 6:36 PM

Hey Peter,

Without having looked at your model, it sounds like you are trying to optimize
the subject as well as the markers using a static trial. With the marker
optimization settings I gave you before, this is impossible. The SCALE solver in
GaitApplication2 is designed to optimize the length of segments as well as
marker positions over a dynamic trial, where the motion around the joint dofs
determines the placements of the markers and length of segments.

However, there are two ways out of this.

  1. Exclude the optimization of markers that can be used to determine the length
    of limbs from the optimization problem. This can be done in the
    DataForConfigFile.any by specifying optimization options “off off off”
    for those markers. In this case, it is very important that you place all markers
    correctly on the skeleton. This will then lead to the skeleton being scaled such
    that floating markers match the markers on the model as well as possible. Since
    the marker positions are rigidly attached to the skeleton, this will also give
    you the segment lengths. In your case, excluding both the knee and ankle markers
    from the problem in all three directions show do the trick (besides the ones
    that were already locked).

  2. Exclude the optimization of segment lengths from the problem. This you can
    also do in the DataForConfigFile.any by changing the SCALEMAN options to
    “off”. In this case, you will have to give the correct segment lengths
    and the markers will then be optimized to match those lengths as well as
    possible. If you choose this option, then there is a few markers that you can
    optimize that were switched off before.

If it still gives you the wrong solution, then you are in the unlucky situation
that GaitApplication2 decides to pick one of the saddle point solutions that do
exist. This will show up as one or more of the segments being as far away from
the markers as possible. The solution here is to move the man closer to the
markers using the Mannequin.any file until it gives you the solution you want.

I hope this answers your question.

Best regards
Michael Skipper Andersen The AnyBody Research Project

To: anyscript@yahoogroups.comFrom: peter.worsley@yahoo.co.ukDate: Thu, 9 Oct
2008 10:12:40 +0000Subject: [AnyScript] GOM

Dear AnyBody, I have been modelling some data sets taken from a couple of
quiteshort individuals. Prior to running GOM I have set the scaling andmarker
positions to fit those of the person I am modelling. I amgetting a problem when
I run GOM, it seems to be reporting highAbsSumKinerror and taken many iterations
to run. When the GOM iscomplete the model has been scaled disproportionately and
the markerpositions seem to be worse than those set prior to the GOM. I
haveuploaded a static model (c01static) as an example. your thoughts would be
greatly appreciated as alwaysbest wishesPeter


Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE

[Non-text portions of this message have been removed]


Users of the AnyBody Modeling System help each other create biomechanical
models in the AnyScript language.Yahoo! Groups Links

[Non-text portions of this message have been removed]

Hey Peter,

That makes a lot more sense. Sorry that I did not understand that in the first
place.

I had a look at your model and have uploaded a new version to the file section.
I think I found the problem and corrected it and the model does look pretty nice
kinematically now. I did not check anything else. It is called c0gait1_msa.zip.

Let me first point out a few minor issues that I found first before I was even
able to load the model:

  1. In the model, you had specified LengthMassFat scaling in the AnyBody models
    but not in the input file to GaitApplication2, which was set to use a uniform
    scaling law. Having this mis-match will lead to incorrect results. I changed it
    back to uniform scaling.
  2. I changed the mannequin.any file to remove the extensive lateral bending and
    thorax-pelvis flexion that was specified.

Anyway, you had forgotten to save the StudyGait.txt file so that the analysis
end time was after the marker data ended and GaitApplication2 actually failed
with an error saying this is the case. The StudyGait.txt file can be found in
the model tree right next to where ModelGait.txt is in the model tree in
AnyBody. Due to this error, it never optimized anything and just returned the
motion given the segment lengths and marker positions that you used as the
initial guess. If you just double clicked GaitApplication2.exe, you probably did
not see the error message as window just closes immediately after the problem
stops and you have no chance to read the message. If you run it from a command
prompt, you will get a chance to read this message.

When I fixed that an other issue popped up. The issue was the location of the
ASIS markers on the skeleton. If you look careful at what happens after the
optimization (with the fixed StudyGait.txt file) is that the ASIS markers are
forced to stay where you placed them on the skeleton whereas the PSI markers as
well as the pelvis width is allowed to be optimized and the PSI markers gets
moved far away from the skeleton. By moving the ASIS markers 2 cm forward fixes
this problem.

Actually, now that I did have to bring up this issue, I would very much like to
see if I can spark some discussion about a better, and more importantly,
automated way to deal with the issue of defining the position of the few markers
and segments that cannot be optimized as they are used to define where zero
orientation are for a few of the degrees of freedom in the model is. In the gait
model, these are pelvis tilt, foot plantar flexsion and foot inversion/eversion.
So what we do now is to manually define the ASIS, the toe and heel markers.
Additionally, if there are only toe and heel markers on the feet in a streight
line through the ankle joint, we also fix the ankle markers since otherwise
there are in principle infinitively many solutions to how long the shank can be.
If we decided to also include these markers in the optimization problem, there
would be infinitively many solutions to how to define the position of these
markers. For instance for pelvis tilt, this could be defined arbitrarily by
simply re-defining the local marker coordinates of the markers on pelvis.

The traditional way this is handled in motion analysis is that the segment
coordinate systems are defined using the markers which are placed on bony
landmarks. Specifically for pelvis, the pelvis coordinate system is defined from
the four markers and hereafter the hip joint centers are calculated in that
reference frame using e.g. the well-known regression equations or a functional
method. However, at least to me, it seems impossible to take a similar approach
when dealing with a musculoskeletal model like this since all the properties of
the original, unscaled model already has the segment coordinate system defined
and has all muscle attachment points, wrapping surfaces, inertia properties etc.
defined in that reference frame. Even the hip joint centers are defined already.
So all we can really do to this model to change it into a new subject is to
morph it using some sort of scaling law and therefore we are left with the
option to define the positions of these very important markers in an already
existing coordinate system. Doing it manually is both difficult, time-consuming
and prone to introduce errors in the model. I am still blank on an automated
solution to this problem so if anyone has any ideas that will not only work for
normal subjects but also for subjects with pathologies (for instance a
clubfoot), please join in.

A last thing that I would like to clarify is that what GaitApplication2 does
when you use the SCALE solver is not the Global Optimization Method (GOM) by Lu
and O’connor, (1999) as you have seemed to imply in the subject of this message.
A lot more than what they presented in that paper is going on in there. However,
if you use the POSONLY solver, it is essentially the same method as GOM but the
math and the optimization problem is handled in more general way, and in fact in
the core of this particular gait model, the model is not described using
generalized coordinates but actually using a full cartesian formulation with
orientations giving using Euler Parameters and a constrained optimization
problem. I understand why some would think that it is using generalized
coordinates since it producees those coordinates as output, but these are in
fact calculated during post-processing and are not part of the actual
optimization problem solved. Just for the sake of completeness, there is also a
third solver option in GaitApplication2 which is POSVELACC which will actually
do velocity and acceleration analysis as well by solving equations to find these
rather than simple finite differences. We have a paper in press in Computer
methods in Biomechanics and Biomedical Engineering that I hope will be publiced
soon that explains all the details.

For the SCALE solver, I unfortunately do not have a journal paper yet, but I do
have a fairly detailed conference paper about the math that I can send to you if
you are interested in knowing what is actually going on.

Sorry for the long answer but I hope this answered your question.

Best regards
Michael Skipper Andersen
The AnyBody Research Project

To: anyscript@yahoogroups.comFrom: peter.worsley@yahoo.co.ukDate: Fri, 10 Oct
2008 09:55:18 +0000Subject: RE: [AnyScript] GOM

Hi Michael, sorry I didn’t explain myself very clearly. I was using the static
trial to find initial seg lengths and marker positions for my dynamic trials I
have collected. It was not my intention to run GOM on the static trial. The GOM
appears to be scaling the dynamic trials indifferently. I’ll put an example up
(gait1) in the file section. The error seems to start with increased anterior
rotation at the pelvis and continue down to the thigh and shank scaling. many
thanksPeter— On Thu, 9/10/08, Michael Skipper Andersen
<msandersen60@hotmail.com> wrote:From: Michael Skipper Andersen
<msandersen60@hotmail.com>Subject: RE: [AnyScript] GOMTo:
anyscript@yahoogroups.comDate: Thursday, 9 October, 2008, 6:36 PMHey
Peter,Without having looked at your model, it sounds like you are trying to
optimizethe subject as well as the markers using a static trial. With the
markeroptimization settings I gave you before, this is impossible. The SCALE
solver inGaitApplication2 is designed to optimize the length of segments as well
asmarker positions over a dynamic trial, where the motion around the joint
dofsdetermines the placements of the markers and length of segments.However,
there are two ways out of this. 1) Exclude the optimization of markers that can
be used to determine the lengthof limbs from the optimization problem. This can
be done in theDataForConfigFile.any by specifying optimization options “off off
off"for those markers. In this case, it is very important that you place all
markerscorrectly on the skeleton. This will then lead to the skeleton being
scaled suchthat floating markers match the markers on the model as well as
possible. Sincethe marker positions are rigidly attached to the skeleton, this
will also giveyou the segment lengths. In your case, excluding both the knee and
ankle markersfrom the problem in all three directions show do the trick (besides
the onesthat were already locked).2) Exclude the optimization of segment lengths
from the problem. This you canalso do in the DataForConfigFile.any by changing
the SCALEMAN options to"off”. In this case, you will have to give the correct
segment lengthsand the markers will then be optimized to match those lengths as
well aspossible. If you choose this option, then there is a few markers that you
canoptimize that were switched off before. If it still gives you the wrong
solution, then you are in the unlucky situationthat GaitApplication2 decides to
pick one of the saddle point solutions that doexist. This will show up as one or
more of the segments being as far away fromthe markers as possible. The solution
here is to move the man closer to themarkers using the Mannequin.any file until
it gives you the solution you want.I hope this answers your question.Best
regardsMichael Skipper Andersen The AnyBody Research ProjectTo:
anyscript@yahoogroups.comFrom: peter.worsley@yahoo.co.ukDate: Thu, 9 Oct2008
10:12:40 +0000Subject: [AnyScript] GOMDear AnyBody, I have been modelling some
data sets taken from a couple ofquiteshort individuals. Prior to running GOM I
have set the scaling andmarkerpositions to fit those of the person I am
modelling. I amgetting a problem whenI run GOM, it seems to be reporting
highAbsSumKinerror and taken many iterationsto run. When the GOM iscomplete the
model has been scaled disproportionately andthe markerpositions seem to be worse
than those set prior to the GOM. Ihaveuploaded a static model (c01static) as an
example. your thoughts would begreatly appreciated as alwaysbest wishesPeter
__________________________________________________________Explore the seven
wonders of the
worldhttp://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE[No
n-text portions of this message have been
removed]------------------------------------Users of the AnyBody Modeling System
help each other create biomechanicalmodels in the AnyScript language.Yahoo!
Groups Links[Non-text portions of this message have been removed]


Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE

[Non-text portions of this message have been removed]

Hey Michael,

thank you for looking at the model and giving me the recommendations for the
GaitApplication2.

I completely agree that setting the initial pos for the kay anatomical landmarks
is both time consuming and difficult to perfect. During my PhD I will be making
up to 300-500 models of various activities, and having an application to speed
up the initial pos would greatly enhance my time management. I think the problem
would come with finding an application robust enough to be able to handle
varying body types and markers positions placement variability.

I look forward to seeing your papers published,

many thanks once again for all your help

best wishes

Peter

— On Sat, 11/10/08, Michael Skipper Andersen <msandersen60@hotmail.com> wrote:
From: Michael Skipper Andersen <msandersen60@hotmail.com>
Subject: RE: [AnyScript] GOM
To: anyscript@yahoogroups.com
Date: Saturday, 11 October, 2008, 6:20 AM

Hey Peter,

That makes a lot more sense. Sorry that I did not understand that in the first
place.

I had a look at your model and have uploaded a new version to the file section.
I think I found the problem and corrected it and the model does look pretty nice
kinematically now. I did not check anything else. It is called c0gait1_msa.zip.

Let me first point out a few minor issues that I found first before I was even
able to load the model:

  1. In the model, you had specified LengthMassFat scaling in the AnyBody models
    but not in the input file to GaitApplication2, which was set to use a uniform
    scaling law. Having this mis-match will lead to incorrect results. I changed it
    back to uniform scaling.
  2. I changed the mannequin.any file to remove the extensive lateral bending and
    thorax-pelvis flexion that was specified.

Anyway, you had forgotten to save the StudyGait.txt file so that the analysis
end time was after the marker data ended and GaitApplication2 actually failed
with an error saying this is the case. The StudyGait.txt file can be found in
the model tree right next to where ModelGait.txt is in the model tree in
AnyBody. Due to this error, it never optimized anything and just returned the
motion given the segment lengths and marker positions that you used as the
initial guess. If you just double clicked GaitApplication2.exe, you probably did
not see the error message as window just closes immediately after the problem
stops and you have no chance to read the message. If you run it from a command
prompt, you will get a chance to read this message.

When I fixed that an other issue popped up. The issue was the location of the
ASIS markers on the skeleton. If you look careful at what happens after the
optimization (with the fixed StudyGait.txt file) is that the ASIS markers are
forced to stay where you placed them on the skeleton whereas the PSI markers as
well as the pelvis width is allowed to be optimized and the PSI markers gets
moved far away from the skeleton. By moving the ASIS markers 2 cm forward fixes
this problem.

Actually, now that I did have to bring up this issue, I would very much like to
see if I can spark some discussion about a better, and more importantly,
automated way to deal with the issue of defining the position of the few markers
and segments that cannot be optimized as they are used to define where zero
orientation are for a few of the degrees of freedom in the model is. In the gait
model, these are pelvis tilt, foot plantar flexsion and foot inversion/eversion.
So what we do now is to manually define the ASIS, the toe and heel markers.
Additionally, if there are only toe and heel markers on the feet in a streight
line through the ankle joint, we also fix the ankle markers since otherwise
there are in principle infinitively many solutions to how long the shank can be.
If we decided to also include these markers in the optimization problem, there
would be infinitively many solutions to how to define the position of these
markers. For instance for pelvis tilt, this could be defined arbitrarily by
simply re-defining the local marker coordinates of the markers on pelvis.

The traditional way this is handled in motion analysis is that the segment
coordinate systems are defined using the markers which are placed on bony
landmarks. Specifically for pelvis, the pelvis coordinate system is defined from
the four markers and hereafter the hip joint centers are calculated in that
reference frame using e.g. the well-known regression equations or a functional
method. However, at least to me, it seems impossible to take a similar approach
when dealing with a musculoskeletal model like this since all the properties of
the original, unscaled model already has the segment coordinate system defined
and has all muscle attachment points, wrapping surfaces, inertia properties etc.
defined in that reference frame. Even the hip joint centers are defined already.
So all we can really do to this model to change it into a new subject is to
morph it using some sort of scaling law and therefore we are left with the
option to define the positions of these very important markers in an already
existing coordinate system. Doing it manually is both difficult, time-consuming
and prone to introduce errors in the model. I am still blank on an automated
solution to this problem so if anyone has any ideas that will not only work for
normal subjects but also for subjects with pathologies (for instance a
clubfoot), please join in.

A last thing that I would like to clarify is that what GaitApplication2 does
when you use the SCALE solver is not the Global Optimization Method (GOM) by Lu
and O’connor, (1999) as you have seemed to imply in the subject of this
message. A lot more than what they presented in that paper is going on in there.
However, if you use the POSONLY solver, it is essentially the same method as GOM
but the math and the optimization problem is handled in more general way, and in
fact in the core of this particular gait model, the model is not described using
generalized coordinates but actually using a full cartesian formulation with
orientations giving using Euler Parameters and a constrained optimization
problem. I understand why some would think that it is using generalized
coordinates since it producees those coordinates as output, but these are in
fact calculated during post-processing and are not part of the actual
optimization problem solved. Just for the sake of completeness, there is also a
third solver option in GaitApplication2 which is POSVELACC which will actually
do velocity and acceleration analysis as well by solving equations to find these
rather than simple finite differences. We have a paper in press in Computer
methods in Biomechanics and Biomedical Engineering that I hope will be publiced
soon that explains all the details.

For the SCALE solver, I unfortunately do not have a journal paper yet, but I do
have a fairly detailed conference paper about the math that I can send to you if
you are interested in knowing what is actually going on.

Sorry for the long answer but I hope this answered your question.

Best regards
Michael Skipper Andersen
The AnyBody Research Project

To: anyscript@yahoogroups.comFrom: peter.worsley@yahoo.co.ukDate: Fri, 10 Oct
2008 09:55:18 +0000Subject: RE: [AnyScript] GOM

Hi Michael, sorry I didn’t explain myself very clearly. I was using the
static trial to find initial seg lengths and marker positions for my dynamic
trials I have collected. It was not my intention to run GOM on the static trial.
The GOM appears to be scaling the dynamic trials indifferently. I’ll put an
example up (gait1) in the file section. The error seems to start with increased
anterior rotation at the pelvis and continue down to the thigh and shank
scaling. many thanksPeter— On Thu, 9/10/08, Michael Skipper Andersen
<msandersen60@hotmail.com> wrote:From: Michael Skipper Andersen
<msandersen60@hotmail.com>Subject: RE: [AnyScript] GOMTo:
anyscript@yahoogroups.comDate: Thursday, 9 October, 2008, 6:36 PMHey
Peter,Without having looked at your model, it sounds like you are trying to
optimizethe subject as well as the markers using a static trial. With the
markeroptimization settings I gave you before, this is impossible. The SCALE
solver inGaitApplication2 is designed to optimize the length of segments as well
asmarker positions over a dynamic trial, where the motion around the joint
dofsdetermines the placements of the markers and length of segments.However,
there are two ways out of this. 1) Exclude the optimization of markers that can
be used to determine the lengthof limbs from the optimization problem. This can
be done in theDataForConfigFile.any by specifying optimization options “off
off off"for those markers. In this case, it is very important that you
place all markerscorrectly on the skeleton. This will then lead to the skeleton
being scaled suchthat floating markers match the markers on the model as well as
possible. Sincethe marker positions are rigidly attached to the skeleton, this
will also giveyou the segment lengths. In your case, excluding both the knee and
ankle markersfrom the problem in all three directions show do the trick (besides
the onesthat were already locked).2) Exclude the optimization of segment lengths
from the problem. This you canalso do in the DataForConfigFile.any by changing
the SCALEMAN options to"off”. In this case, you will have to give the
correct segment lengthsand the markers will then be optimized to match those
lengths as well aspossible. If you choose this option, then there is a few
markers that you canoptimize that were switched off before. If it still gives
you the wrong solution, then you are in the unlucky situationthat
GaitApplication2 decides to pick one of the saddle point solutions that doexist.
This will show up as one or more of the segments being as far away fromthe
markers as possible. The solution here is to move the man closer to themarkers
using the Mannequin.any file until it gives you the solution you want.I hope
this answers your question.Best regardsMichael Skipper Andersen The AnyBody
Research ProjectTo: anyscript@yahoogroups.comFrom:
peter.worsley@yahoo.co.ukDate: Thu, 9 Oct2008 10:12:40 +0000Subject: [AnyScript]
GOMDear AnyBody, I have been modelling some data sets taken from a couple
ofquiteshort individuals. Prior to running GOM I have set the scaling
andmarkerpositions to fit those of the person I am modelling. I amgetting a
problem whenI run GOM, it seems to be reporting highAbsSumKinerror and taken
many iterationsto run. When the GOM iscomplete the model has been scaled
disproportionately andthe markerpositions seem to be worse than those set prior
to the GOM. Ihaveuploaded a static model (c01static) as an example. your
thoughts would begreatly appreciated as alwaysbest wishesPeter
__________________________________________________________Explore the seven
wonders of the
worldhttp://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE[No
n-text
portions of this message have been
removed]------------------------------------Users of the AnyBody Modeling System
help each other create biomechanicalmodels in the AnyScript language.Yahoo!
Groups Links[Non-text portions of this message have been removed]


Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE

[Non-text portions of this message have been removed]


Users of the AnyBody Modeling System help each other create biomechanical
models in the AnyScript language.Yahoo! Groups Links

[Non-text portions of this message have been removed]

Hej,

The paper which Michael is writing about is still in press, but is now
available online though the following link:

http://dx.doi.org/10.1080/10255840802459412

M. S. Andersen; M. Damsgaard; J. Rasmussen. Kinematic analysis of
over-determinate biomechanical systems. Computer Methods in Biomechanics
and Biomedical Engineering. (in press) DOI: 10.1080/10255840802459412.

Regards, Mark

Michael Skipper Andersen wrote:
>
>
> Hey Peter,
>
> That makes a lot more sense. Sorry that I did not understand that in
> the first place.
>
> I had a look at your model and have uploaded a new version to the file
> section. I think I found the problem and corrected it and the model
> does look pretty nice kinematically now. I did not check anything
> else. It is called c0gait1_msa.zip.
>
> Let me first point out a few minor issues that I found first before I
> was even able to load the model:
> 1. In the model, you had specified LengthMassFat scaling in the
> AnyBody models but not in the input file to GaitApplication2, which
> was set to use a uniform scaling law. Having this mis-match will lead
> to incorrect results. I changed it back to uniform scaling.
> 2. I changed the mannequin.any file to remove the extensive lateral
> bending and thorax-pelvis flexion that was specified.
>
> Anyway, you had forgotten to save the StudyGait.txt file so that the
> analysis end time was after the marker data ended and GaitApplication2
> actually failed with an error saying this is the case. The
> StudyGait.txt file can be found in the model tree right next to where
> ModelGait.txt is in the model tree in AnyBody. Due to this error, it
> never optimized anything and just returned the motion given the
> segment lengths and marker positions that you used as the initial
> guess. If you just double clicked GaitApplication2.exe, you probably
> did not see the error message as window just closes immediately after
> the problem stops and you have no chance to read the message. If you
> run it from a command prompt, you will get a chance to read this message.
>
> When I fixed that an other issue popped up. The issue was the location
> of the ASIS markers on the skeleton. If you look careful at what
> happens after the optimization (with the fixed StudyGait.txt file) is
> that the ASIS markers are forced to stay where you placed them on the
> skeleton whereas the PSI markers as well as the pelvis width is
> allowed to be optimized and the PSI markers gets moved far away from
> the skeleton. By moving the ASIS markers 2 cm forward fixes this problem.
>
> Actually, now that I did have to bring up this issue, I would very
> much like to see if I can spark some discussion about a better, and
> more importantly, automated way to deal with the issue of defining the
> position of the few markers and segments that cannot be optimized as
> they are used to define where zero orientation are for a few of the
> degrees of freedom in the model is. In the gait model, these are
> pelvis tilt, foot plantar flexsion and foot inversion/eversion. So
> what we do now is to manually define the ASIS, the toe and heel
> markers. Additionally, if there are only toe and heel markers on the
> feet in a streight line through the ankle joint, we also fix the ankle
> markers since otherwise there are in principle infinitively many
> solutions to how long the shank can be. If we decided to also include
> these markers in the optimization problem, there would be infinitively
> many solutions to how to define the position of these markers. For
> instance for pelvis tilt, this could ! be defined arbitrarily by
> simply re-defining the local marker coordinates of the markers on pelvis.
>
> The traditional way this is handled in motion analysis is that the
> segment coordinate systems are defined using the markers which are
> placed on bony landmarks. Specifically for pelvis, the pelvis
> coordinate system is defined from the four markers and hereafter the
> hip joint centers are calculated in that reference frame using e.g.
> the well-known regression equations or a functional method. However,
> at least to me, it seems impossible to take a similar approach when
> dealing with a musculoskeletal model like this since all the
> properties of the original, unscaled model already has the segment
> coordinate system defined and has all muscle attachment points,
> wrapping surfaces, inertia properties etc. defined in that reference
> frame. Even the hip joint centers are defined already. So all we can
> really do to this model to change it into a new subject is to morph it
> using some sort of scaling law and therefore we are left with the
> option to define the positions of these very importa! nt markers in an
> already existing coordinate system. Doing it manually is both
> difficult, time-consuming and prone to introduce errors in the model.
> I am still blank on an automated solution to this problem so if anyone
> has any ideas that will not only work for normal subjects but also for
> subjects with pathologies (for instance a clubfoot), please join in.
>
> A last thing that I would like to clarify is that what
> GaitApplication2 does when you use the SCALE solver is not the Global
> Optimization Method (GOM) by Lu and O’connor, (1999) as you have
> seemed to imply in the subject of this message. A lot more than what
> they presented in that paper is going on in there. However, if you use
> the POSONLY solver, it is essentially the same method as GOM but the
> math and the optimization problem is handled in more general way, and
> in fact in the core of this particular gait model, the model is not
> described using generalized coordinates but actually using a full
> cartesian formulation with orientations giving using Euler Parameters
> and a constrained optimization problem. I understand why some would
> think that it is using generalized coordinates since it producees
> those coordinates as output, but these are in fact calculated during
> post-processing and are not part of the actual optimization problem
> solved. Just for the sake of completeness, th! ere is also a third
> solver option in GaitApplication2 which is POSVELACC which will
> actually do velocity and acceleration analysis as well by solving
> equations to find these rather than simple finite differences. We have
> a paper in press in Computer methods in Biomechanics and Biomedical
> Engineering that I hope will be publiced soon that explains all the
> details.
>
> For the SCALE solver, I unfortunately do not have a journal paper yet,
> but I do have a fairly detailed conference paper about the math that I
> can send to you if you are interested in knowing what is actually
> going on.
>
> Sorry for the long answer but I hope this answered your question.
>
> Best regards
> Michael Skipper Andersen
> The AnyBody Research Project
>
> To: anyscript@yahoogroups.comFrom
> <mailto:anyscript%40yahoogroups.comFrom>:
> peter.worsley@yahoo.co.ukDate
> <mailto:peter.worsley%40yahoo.co.ukDate>: Fri, 10 Oct 2008 09:55:18
> +0000Subject: RE: [AnyScript] GOM
>
> Hi Michael, sorry I didn’t explain myself very clearly. I was using
> the static trial to find initial seg lengths and marker positions for
> my dynamic trials I have collected. It was not my intention to run GOM
> on the static trial. The GOM appears to be scaling the dynamic trials
> indifferently. I’ll put an example up (gait1) in the file section. The
> error seems to start with increased anterior rotation at the pelvis
> and continue down to the thigh and shank scaling. many thanksPeter—
> On Thu, 9/10/08, Michael Skipper Andersen <msandersen60@hotmail.com
> <mailto:msandersen60%40hotmail.com>> wrote:From: Michael Skipper
> Andersen <msandersen60@hotmail.com
> <mailto:msandersen60%40hotmail.com>>Subject: RE: [AnyScript] GOMTo:
> anyscript@yahoogroups.comDate
> <mailto:anyscript%40yahoogroups.comDate>: Thursday, 9 October, 2008,
> 6:36 PMHey Peter,Without having looked at your model, it sounds like
> you are trying to optimizethe! subject as well as the markers using a
> static trial. With the markeroptimization settings I gave you before,
> this is impossible. The SCALE solver inGaitApplication2 is designed to
> optimize the length of segments as well asmarker positions over a
> dynamic trial, where the motion around the joint dofsdetermines the
> placements of the markers and length of segments.However, there are
> two ways out of this. 1) Exclude the optimization of markers that can
> be used to determine the lengthof limbs from the optimization problem.
> This can be done in theDataForConfigFile.any by specifying
> optimization options “off off off"for those markers. In this case, it
> is very important that you place all markerscorrectly on the skeleton.
> This will then lead to the skeleton being scaled suchthat floating
> markers match the markers on the model as well as possible. Sincethe
> marker positions are rigidly attached to the skeleton, this will also
> giveyou the segment lengths. In your case, ! excluding both the knee
> and ankle markersfrom the problem in all three directions show do the
> trick (besides the onesthat were already locked).2) Exclude the
> optimization of segment lengths from the problem. This you canalso do
> in the DataForConfigFile.any by changing the SCALEMAN options to"off”.
> In this case, you will have to give the correct segment lengthsand the
> markers will then be optimized to match those lengths as well
> aspossible. If you choose this option, then there is a few markers
> that you canoptimize that were switched off before. If it still gives
> you the wrong solution, then you are in the unlucky situationthat
> GaitApplication2 decides to pick one of the saddle point solutions
> that doexist. This will show up as one or more of the segments being
> as far away fromthe markers as possible. The solution here is to move
> the man closer to themarkers using the Mannequin.any file until it
> gives you the solution you want.I hope this answers your question.
> Best regardsMichael Skipper Andersen The AnyBody Research ProjectTo:
> anyscript@yahoogroups.comFrom: peter.worsley@yahoo.co.ukDate
> <mailto:peter.worsley%40yahoo.co.ukDate>: Thu, 9 Oct2008 10:12:40
> +0000Subject: [AnyScript] GOMDear AnyBody, I have been modelling some
> data sets taken from a couple ofquiteshort individuals. Prior to
> running GOM I have set the scaling andmarkerpositions to fit those of
> the person I am modelling. I amgetting a problem whenI run GOM, it
> seems to be reporting highAbsSumKinerror and taken many iterationsto
> run. When the GOM iscomplete the model has been scaled
> disproportionately andthe markerpositions seem to be worse than those
> set prior to the GOM. Ihaveuploaded a static model (c01static) as an
> example. your thoughts would begreatly appreciated as alwaysbest
> wishesPeter
> __________________________________________________________Explore the
> seven wonders of the
> worldhttp://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE
>
<<a href=“worldhttp://search.msn.com/results.a%21%0A%20spx?q=7+wonders+world&mkt=en-US&form=QBRE”>worldhttp://search.msn.com/results.a%21%0A%20spx?q=7+wonders+world&mkt=en-US&fo
rm=QBRE</a>>[Non-text
> portions of this message have been
> removed]------------------------------------Users of the AnyBody
> Modeling System help each other create biomechanicalmodels in the
> AnyScript language.Yahoo! Groups Links[Non-text portions of this
> message have been removed]
>
> __________________________________________________________
> Explore the seven wonders of the world
> http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE
> <http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE>
>
> [Non-text portions of this message have been removed]
>
>