Question about Recruitment Solvers

I have a question regarding RecruitmentSolvers, specifically the
MinMaxNRSimplex solver (although I’m sure my question applies to the
other Recruitment Solvers as well). I have noticed in the past (and
with the current model that I am working on), that I will occasionally
get the following error when I am adjusting the tEnd and nStep values:

ERROR(OBJ1) : MyStudy’ : Muscle recruitment analysis failed,
simplex solver reports that solution does not satisfy all constraints.

Depending on the tEnd and nStep values I plug in, I can often get the
model to run all the way through. For example, if I have a file that
has a kinematics time frame of 0-58, and a kinetics time frame of
0-116, I have noticed that changing the tEnd and nStep does not always
guarantee that the InverseDynamicsAnalysis will fully run through; I
can have the tEnd be 58/120 (to represent a 120 Hz sampling rate), and
the nStep be 58, and the model will compile and run fine. However, if
the tEnd is (arbitrarily) 30/120, and the nStep is 30, the model will
compile, however it won’t run to completion. And often, the length
that the model will run before failing varies in a non-decipherable
pattern. If my tEnd and nStep is 25, the model may run until 22
before failing – completing nearly the entire analysis. However, if
my tEnd and nStep is 55, the model may run to only 9 before failing –
hardly completing any of the analysis.

I’m sure there is a simple explanation for this which will help in
future analyses and my determination of tEnd and nStep values. Could
you help me out with this? Thank you for your time!

PS – I have uploaded a wheelchair model that I am trying to fully
drive with the addition of trunk movement (right now the trunk is
fixed to the back of the wheelchair – I wrote about two weeks ago with
a question about this model). It currently compiles, but I think
there is a problem with the initial conditions because the left side
of the body does not mimic the right side at load time. It was
working, and I’m not quite sure what I changed, but something seems
amiss…(The file name is SarahArmModel – Muscles_6-11-07).

Hi Sarah

I have uploaded a new version of you application to the file section
of the group it is named “SarahArmModel – Muscles_6-11-07V2” . I
have updated the InitialPosition.any file and made some changes in
the Mannequin.any file so now it loads at a reasonable position and
also run kinematically.

Concerning the MinMaxNRSimplex solver you may experience cases like
you are describing. When the tStart, tEnd or nStep are changed it
means that the analysis will calculate for different time values. If
the model is sensitive this may provoke recruitment problems like
you have experienced. This basically means that a certain or several
dof. in the model are difficult to balance with muscles forces. If
this is the case one solution is to try adding AnyReacForces to the
different dof in the model, if adding a AnyReacForce for a certain
dof in the model makes it stable, it indicates that this dof. is
causing the problem.

The recruitment problem may also occur if there are very strong
muscles present in the problem, this can make the model numerically
difficult to solve. This can be the case if you have strong pushing
muscles for generating support forces to the model, like on a
backrest or similar. So sometimes lowering the strength of these
muscles makes the model more stable.

If you add a small amount of gravity to the directions of the model
having zero gravity, it also often helps making the recruitment more
stable. So something like Gravity = {0.01, -9.81, 0.01}; usually
helps without disturbing the solution of the problem.

The next version of AnyBody will have some additional settings
available in the solver. This can sometimes help solve recruitment
problems if these are caused by numeric problems.

I tried to make your model run inverse analysis, but it seemed that
one timestep was causing problems. The reactions in the GH joint are
created with a number of pushing muscles which ensures that the
reaction force fall with the cavity of scapula. Due to the loading
conditions of this model i tried to change the directional reactions
in the glenohumeral joint back to a classic spherical joint, and it
help solve the problem. To introduce this change to your brep
please do the following changes in Arm3d/jnt.any

1: outcomment the line "#include "“ghreactions.any”
2: change the lines

AnyKinEq GHLinCon = {
AnyKinMeasure &GHLinCon = .GHLin;
Reaction.Type={Off,Off,Off};
};

to

AnyKinEq GHLinCon = {
AnyKinMeasure &GHLinCon = .GHLin;
// Reaction.Type={Off,Off,Off};
};

Best regards
Søren, AnyBody Support

— In anyscript@yahoogroups.com, “Sarah R. Sullivan” <sarsulli@…>
wrote:
>
> I have a question regarding RecruitmentSolvers, specifically the
> MinMaxNRSimplex solver (although I’m sure my question applies to
the
> other Recruitment Solvers as well). I have noticed in the past
(and
> with the current model that I am working on), that I will
occasionally
> get the following error when I am adjusting the tEnd and nStep
values:
>
> ERROR(OBJ1) : MyStudy’ : Muscle recruitment analysis failed,
> simplex solver reports that solution does not satisfy all
constraints.
>
> Depending on the tEnd and nStep values I plug in, I can often get
the
> model to run all the way through. For example, if I have a file
that
> has a kinematics time frame of 0-58, and a kinetics time frame of
> 0-116, I have noticed that changing the tEnd and nStep does not
always
> guarantee that the InverseDynamicsAnalysis will fully run through;
I
> can have the tEnd be 58/120 (to represent a 120 Hz sampling rate),
and
> the nStep be 58, and the model will compile and run fine.
However, if
> the tEnd is (arbitrarily) 30/120, and the nStep is 30, the model
will
> compile, however it won’t run to completion. And often, the length
> that the model will run before failing varies in a non-decipherable
> pattern. If my tEnd and nStep is 25, the model may run until 22
> before failing – completing nearly the entire analysis. However,
if
> my tEnd and nStep is 55, the model may run to only 9 before
failing –
> hardly completing any of the analysis.
>
> I’m sure there is a simple explanation for this which will help in
> future analyses and my determination of tEnd and nStep values.
Could
> you help me out with this? Thank you for your time!
>
> PS – I have uploaded a wheelchair model that I am trying to fully
> drive with the addition of trunk movement (right now the trunk is
> fixed to the back of the wheelchair – I wrote about two weeks ago
with
> a question about this model). It currently compiles, but I think
> there is a problem with the initial conditions because the left
side
> of the body does not mimic the right side at load time. It was
> working, and I’m not quite sure what I changed, but something seems
> amiss…(The file name is SarahArmModel – Muscles_6-11-07).
>

Just another follow-up question regarding driving a model by mocap data. I have
been looking at the gait webcast from last August, and I am trying to drive the
pelvis in the same way that it is driven in the webcast and I have a question
regarding the statement that RAsisZ + LAsisZ = SacrumZ. Should this be the
average of the two Ases Z-directions? Just adding them together would give a
very tall pelvis, right? Should it be (RAsisZ + LAsisZ)/2 = SacrumZ?

Just trying to figure this out…hope I’m not bothering you!

As always, thanks for your time,
Sarah

-----Original Message-----

> Date: Thu Jun 14 07:56:16 EDT 2007
> From: “AnyBody Support” <support@anybodytech.com>
> Subject: [anyscript] Re: Question about Recruitment Solvers
> To: anyscript@yahoogroups.com
>
> Hi Sarah
>
> I have uploaded a new version of you application to the file section
> of the group it is named “SarahArmModel ? Muscles_6-11-07V2” . I
> have updated the InitialPosition.any file and made some changes in
> the Mannequin.any file so now it loads at a reasonable position and
> also run kinematically.
>
> Concerning the MinMaxNRSimplex solver you may experience cases like
> you are describing. When the tStart, tEnd or nStep are changed it
> means that the analysis will calculate for different time values. If
> the model is sensitive this may provoke recruitment problems like
> you have experienced. This basically means that a certain or several
> dof. in the model are difficult to balance with muscles forces. If
> this is the case one solution is to try adding AnyReacForces to the
> different dof in the model, if adding a AnyReacForce for a certain
> dof in the model makes it stable, it indicates that this dof. is
> causing the problem.
>
> The recruitment problem may also occur if there are very strong
> muscles present in the problem, this can make the model numerically
> difficult to solve. This can be the case if you have strong pushing
> muscles for generating support forces to the model, like on a
> backrest or similar. So sometimes lowering the strength of these
> muscles makes the model more stable.
>
> If you add a small amount of gravity to the directions of the model
> having zero gravity, it also often helps making the recruitment more
> stable. So something like Gravity = {0.01, -9.81, 0.01}; usually
> helps without disturbing the solution of the problem.
>
> The next version of AnyBody will have some additional settings
> available in the solver. This can sometimes help solve recruitment
> problems if these are caused by numeric problems.
>
> I tried to make your model run inverse analysis, but it seemed that
> one timestep was causing problems. The reactions in the GH joint are
> created with a number of pushing muscles which ensures that the
> reaction force fall with the cavity of scapula. Due to the loading
> conditions of this model i tried to change the directional reactions
> in the glenohumeral joint back to a classic spherical joint, and it
> help solve the problem. To introduce this change to your brep
> please do the following changes in Arm3d/jnt.any
>
> 1: outcomment the line "#include "“ghreactions.any”
> 2: change the lines
>
> AnyKinEq GHLinCon = {
> AnyKinMeasure &GHLinCon = .GHLin;
> Reaction.Type={Off,Off,Off};
> };
>
> to
>
> AnyKinEq GHLinCon = {
> AnyKinMeasure &GHLinCon = .GHLin;
> // Reaction.Type={Off,Off,Off};
> };
>
>
>
> Best regards
> S?ren, AnyBody Support
>
>
> — In anyscript@yahoogroups.com, “Sarah R. Sullivan” <sarsulli@…>
> wrote:
> >
> > I have a question regarding RecruitmentSolvers, specifically the
> > MinMaxNRSimplex solver (although I’m sure my question applies to
> the
> > other Recruitment Solvers as well). I have noticed in the past
> (and
> > with the current model that I am working on), that I will
> occasionally
> > get the following error when I am adjusting the tEnd and nStep
> values:
> >
> > ERROR(OBJ1) : MyStudy’ : Muscle recruitment analysis failed,
> > simplex solver reports that solution does not satisfy all
> constraints.
> >
> > Depending on the tEnd and nStep values I plug in, I can often get
> the
> > model to run all the way through. For example, if I have a file
> that
> > has a kinematics time frame of 0-58, and a kinetics time frame of
> > 0-116, I have noticed that changing the tEnd and nStep does not
> always
> > guarantee that the InverseDynamicsAnalysis will fully run through;
> I
> > can have the tEnd be 58/120 (to represent a 120 Hz sampling rate),
> and
> > the nStep be 58, and the model will compile and run fine.
> However, if
> > the tEnd is (arbitrarily) 30/120, and the nStep is 30, the model
> will
> > compile, however it won’t run to completion. And often, the length
> > that the model will run before failing varies in a non-decipherable
> > pattern. If my tEnd and nStep is 25, the model may run until 22
> > before failing ? completing nearly the entire analysis. However,
> if
> > my tEnd and nStep is 55, the model may run to only 9 before
> failing ?
> > hardly completing any of the analysis.
> >
> > I’m sure there is a simple explanation for this which will help in
> > future analyses and my determination of tEnd and nStep values.
> Could
> > you help me out with this? Thank you for your time!
> >
> > PS ? I have uploaded a wheelchair model that I am trying to fully
> > drive with the addition of trunk movement (right now the trunk is
> > fixed to the back of the wheelchair ? I wrote about two weeks ago
> with
> > a question about this model). It currently compiles, but I think
> > there is a problem with the initial conditions because the left
> side
> > of the body does not mimic the right side at load time. It was
> > working, and I’m not quite sure what I changed, but something seems
> > amiss?(The file name is SarahArmModel ? Muscles_6-11-07).
> >
>
>

Hi Sarah

No problem I will try to explain.

This driver was created because we found that driving for example
the pelvis directly in the z direction was not a good idea, because
and error on leg length joit kinematics would the result in unwanted
rotaions of the pelvis. Therefore we introduced this driver that
makes sure that the pelvis can have variations in height. The driver
says that the height difference between the sacrum marker on the
pelvis and the free floating sacrum marker should be equal the sum
of the the heigth difference between the asis markers.

It is correct that in the Gait3D model the equation

RAsisZ + LAsisZ = SacrumZ is being used

it migth be that

(RAsisZ + LAsisZ)/2 = SacrumZ

would be better that is correct, this can be tested by chaning the
coefficients. Changing these coefficients will not change the
model dramatically i think, but it is easy to try out.

Best regards
Søren, AnyBody Support

— In anyscript@yahoogroups.com, “Sarah R. Sullivan” <sarsulli@…>
wrote:
>
> Just another follow-up question regarding driving a model by mocap
data. I have been looking at the gait webcast from last August, and
I am trying to drive the pelvis in the same way that it is driven in
the webcast and I have a question regarding the statement that
RAsisZ + LAsisZ = SacrumZ. Should this be the average of the two
Ases Z-directions? Just adding them together would give a very tall
pelvis, right? Should it be (RAsisZ + LAsisZ)/2 = SacrumZ?
>
> Just trying to figure this out…hope I’m not bothering you!
>
> As always, thanks for your time,
> Sarah
>
>
>
>
>
> -----Original Message-----
>
> > Date: Thu Jun 14 07:56:16 EDT 2007
> > From: “AnyBody Support” <support@…>
> > Subject: [anyscript] Re: Question about Recruitment Solvers
> > To: anyscript@yahoogroups.com
> >
> > Hi Sarah
> >
> > I have uploaded a new version of you application to the file
section
> > of the group it is named “SarahArmModel ? Muscles_6-11-07V2” . I
> > have updated the InitialPosition.any file and made some changes
in
> > the Mannequin.any file so now it loads at a reasonable position
and
> > also run kinematically.
> >
> > Concerning the MinMaxNRSimplex solver you may experience cases
like
> > you are describing. When the tStart, tEnd or nStep are changed
it
> > means that the analysis will calculate for different time
values. If
> > the model is sensitive this may provoke recruitment problems
like
> > you have experienced. This basically means that a certain or
several
> > dof. in the model are difficult to balance with muscles forces.
If
> > this is the case one solution is to try adding AnyReacForces to
the
> > different dof in the model, if adding a AnyReacForce for a
certain
> > dof in the model makes it stable, it indicates that this dof. is
> > causing the problem.
> >
> > The recruitment problem may also occur if there are very strong
> > muscles present in the problem, this can make the model
numerically
> > difficult to solve. This can be the case if you have strong
pushing
> > muscles for generating support forces to the model, like on a
> > backrest or similar. So sometimes lowering the strength of these
> > muscles makes the model more stable.
> >
> > If you add a small amount of gravity to the directions of the
model
> > having zero gravity, it also often helps making the recruitment
more
> > stable. So something like Gravity = {0.01, -9.81, 0.01}; usually
> > helps without disturbing the solution of the problem.
> >
> > The next version of AnyBody will have some additional settings
> > available in the solver. This can sometimes help solve
recruitment
> > problems if these are caused by numeric problems.
> >
> > I tried to make your model run inverse analysis, but it seemed
that
> > one timestep was causing problems. The reactions in the GH joint
are
> > created with a number of pushing muscles which ensures that the
> > reaction force fall with the cavity of scapula. Due to the
loading
> > conditions of this model i tried to change the directional
reactions
> > in the glenohumeral joint back to a classic spherical joint, and
it
> > help solve the problem. To introduce this change to your brep
> > please do the following changes in Arm3d/jnt.any
> >
> > 1: outcomment the line "#include "“ghreactions.any”
> > 2: change the lines
> >
> > AnyKinEq GHLinCon = {
> > AnyKinMeasure &GHLinCon = .GHLin;
> > Reaction.Type={Off,Off,Off};
> > };
> >
> > to
> >
> > AnyKinEq GHLinCon = {
> > AnyKinMeasure &GHLinCon = .GHLin;
> > // Reaction.Type={Off,Off,Off};
> > };
> >
> >
> >
> > Best regards
> > S?ren, AnyBody Support
> >
> >
> > — In anyscript@yahoogroups.com, “Sarah R. Sullivan”
<sarsulli@>
> > wrote:
> > >
> > > I have a question regarding RecruitmentSolvers, specifically
the
> > > MinMaxNRSimplex solver (although I’m sure my question applies
to
> > the
> > > other Recruitment Solvers as well). I have noticed in the
past
> > (and
> > > with the current model that I am working on), that I will
> > occasionally
> > > get the following error when I am adjusting the tEnd and nStep
> > values:
> > >
> > > ERROR(OBJ1) : MyStudy’ : Muscle recruitment analysis failed,
> > > simplex solver reports that solution does not satisfy all
> > constraints.
> > >
> > > Depending on the tEnd and nStep values I plug in, I can often
get
> > the
> > > model to run all the way through. For example, if I have a
file
> > that
> > > has a kinematics time frame of 0-58, and a kinetics time frame
of
> > > 0-116, I have noticed that changing the tEnd and nStep does
not
> > always
> > > guarantee that the InverseDynamicsAnalysis will fully run
through;
> > I
> > > can have the tEnd be 58/120 (to represent a 120 Hz sampling
rate),
> > and
> > > the nStep be 58, and the model will compile and run fine.
> > However, if
> > > the tEnd is (arbitrarily) 30/120, and the nStep is 30, the
model
> > will
> > > compile, however it won’t run to completion. And often, the
length
> > > that the model will run before failing varies in a non-
decipherable
> > > pattern. If my tEnd and nStep is 25, the model may run until
22
> > > before failing ? completing nearly the entire analysis.
However,
> > if
> > > my tEnd and nStep is 55, the model may run to only 9 before
> > failing ?
> > > hardly completing any of the analysis.
> > >
> > > I’m sure there is a simple explanation for this which will
help in
> > > future analyses and my determination of tEnd and nStep
values.
> > Could
> > > you help me out with this? Thank you for your time!
> > >
> > > PS ? I have uploaded a wheelchair model that I am trying to
fully
> > > drive with the addition of trunk movement (right now the trunk
is
> > > fixed to the back of the wheelchair ? I wrote about two weeks
ago
> > with
> > > a question about this model). It currently compiles, but I
think
> > > there is a problem with the initial conditions because the
left
> > side
> > > of the body does not mimic the right side at load time. It was
> > > working, and I’m not quite sure what I changed, but something
seems
> > > amiss?(The file name is SarahArmModel ? Muscles_6-11-07).
> > >
> >
> >
>

Hi,

What I understand is that the systems is applying:

u1 + u2 + u3 =0

where u1, u2, and u3 are the differenence between the motion-markers
and body-markers (in y-direction) at RAsisZ, LAsisZ, and SacrumZ,
respectively. There was a small mistake in “JointAndDirvers.any”: they
should be labelled as “RAsisY, LAsisY, and SacrumY”.

I may be wrong.

John

— In anyscript@yahoogroups.com, “AnyBody Support” <support@…> wrote:
>
> Hi Sarah
>
> No problem I will try to explain.
>
> This driver was created because we found that driving for example
> the pelvis directly in the z direction was not a good idea, because
> and error on leg length joit kinematics would the result in unwanted
> rotaions of the pelvis. Therefore we introduced this driver that
> makes sure that the pelvis can have variations in height. The driver
> says that the height difference between the sacrum marker on the
> pelvis and the free floating sacrum marker should be equal the sum
> of the the heigth difference between the asis markers.
>
> It is correct that in the Gait3D model the equation
>
> RAsisZ + LAsisZ = SacrumZ is being used
>
> it migth be that
>
> (RAsisZ + LAsisZ)/2 = SacrumZ
>
> would be better that is correct, this can be tested by chaning the
> coefficients. Changing these coefficients will not change the
> model dramatically i think, but it is easy to try out.
>
>
> Best regards
> Søren, AnyBody Support
>
>
>
> — In anyscript@yahoogroups.com, “Sarah R. Sullivan” <sarsulli@>
> wrote:
> >
> > Just another follow-up question regarding driving a model by mocap
> data. I have been looking at the gait webcast from last August, and
> I am trying to drive the pelvis in the same way that it is driven in
> the webcast and I have a question regarding the statement that
> RAsisZ + LAsisZ = SacrumZ. Should this be the average of the two
> Ases Z-directions? Just adding them together would give a very tall
> pelvis, right? Should it be (RAsisZ + LAsisZ)/2 = SacrumZ?
> >
> > Just trying to figure this out…hope I’m not bothering you!
> >
> > As always, thanks for your time,
> > Sarah
> >
> >
> >
> >
> >
> > -----Original Message-----
> >
> > > Date: Thu Jun 14 07:56:16 EDT 2007
> > > From: “AnyBody Support” <support@>
> > > Subject: [anyscript] Re: Question about Recruitment Solvers
> > > To: anyscript@yahoogroups.com
> > >
> > > Hi Sarah
> > >
> > > I have uploaded a new version of you application to the file
> section
> > > of the group it is named “SarahArmModel ? Muscles_6-11-07V2” . I
> > > have updated the InitialPosition.any file and made some changes
> in
> > > the Mannequin.any file so now it loads at a reasonable position
> and
> > > also run kinematically.
> > >
> > > Concerning the MinMaxNRSimplex solver you may experience cases
> like
> > > you are describing. When the tStart, tEnd or nStep are changed
> it
> > > means that the analysis will calculate for different time
> values. If
> > > the model is sensitive this may provoke recruitment problems
> like
> > > you have experienced. This basically means that a certain or
> several
> > > dof. in the model are difficult to balance with muscles forces.
> If
> > > this is the case one solution is to try adding AnyReacForces to
> the
> > > different dof in the model, if adding a AnyReacForce for a
> certain
> > > dof in the model makes it stable, it indicates that this dof. is
> > > causing the problem.
> > >
> > > The recruitment problem may also occur if there are very strong
> > > muscles present in the problem, this can make the model
> numerically
> > > difficult to solve. This can be the case if you have strong
> pushing
> > > muscles for generating support forces to the model, like on a
> > > backrest or similar. So sometimes lowering the strength of these
> > > muscles makes the model more stable.
> > >
> > > If you add a small amount of gravity to the directions of the
> model
> > > having zero gravity, it also often helps making the recruitment
> more
> > > stable. So something like Gravity = {0.01, -9.81, 0.01}; usually
> > > helps without disturbing the solution of the problem.
> > >
> > > The next version of AnyBody will have some additional settings
> > > available in the solver. This can sometimes help solve
> recruitment
> > > problems if these are caused by numeric problems.
> > >
> > > I tried to make your model run inverse analysis, but it seemed
> that
> > > one timestep was causing problems. The reactions in the GH joint
> are
> > > created with a number of pushing muscles which ensures that the
> > > reaction force fall with the cavity of scapula. Due to the
> loading
> > > conditions of this model i tried to change the directional
> reactions
> > > in the glenohumeral joint back to a classic spherical joint, and
> it
> > > help solve the problem. To introduce this change to your brep
> > > please do the following changes in Arm3d/jnt.any
> > >
> > > 1: outcomment the line "#include "“ghreactions.any”
> > > 2: change the lines
> > >
> > > AnyKinEq GHLinCon = {
> > > AnyKinMeasure &GHLinCon = .GHLin;
> > > Reaction.Type={Off,Off,Off};
> > > };
> > >
> > > to
> > >
> > > AnyKinEq GHLinCon = {
> > > AnyKinMeasure &GHLinCon = .GHLin;
> > > // Reaction.Type={Off,Off,Off};
> > > };
> > >
> > >
> > >
> > > Best regards
> > > S?ren, AnyBody Support
> > >
> > >
> > > — In anyscript@yahoogroups.com, “Sarah R. Sullivan”
> <sarsulli@>
> > > wrote:
> > > >
> > > > I have a question regarding RecruitmentSolvers, specifically
> the
> > > > MinMaxNRSimplex solver (although I’m sure my question applies
> to
> > > the
> > > > other Recruitment Solvers as well). I have noticed in the
> past
> > > (and
> > > > with the current model that I am working on), that I will
> > > occasionally
> > > > get the following error when I am adjusting the tEnd and nStep
> > > values:
> > > >
> > > > ERROR(OBJ1) : MyStudy’ : Muscle recruitment analysis failed,
> > > > simplex solver reports that solution does not satisfy all
> > > constraints.
> > > >
> > > > Depending on the tEnd and nStep values I plug in, I can often
> get
> > > the
> > > > model to run all the way through. For example, if I have a
> file
> > > that
> > > > has a kinematics time frame of 0-58, and a kinetics time frame
> of
> > > > 0-116, I have noticed that changing the tEnd and nStep does
> not
> > > always
> > > > guarantee that the InverseDynamicsAnalysis will fully run
> through;
> > > I
> > > > can have the tEnd be 58/120 (to represent a 120 Hz sampling
> rate),
> > > and
> > > > the nStep be 58, and the model will compile and run fine.
> > > However, if
> > > > the tEnd is (arbitrarily) 30/120, and the nStep is 30, the
> model
> > > will
> > > > compile, however it won’t run to completion. And often, the
> length
> > > > that the model will run before failing varies in a non-
> decipherable
> > > > pattern. If my tEnd and nStep is 25, the model may run until
> 22
> > > > before failing ? completing nearly the entire analysis.
> However,
> > > if
> > > > my tEnd and nStep is 55, the model may run to only 9 before
> > > failing ?
> > > > hardly completing any of the analysis.
> > > >
> > > > I’m sure there is a simple explanation for this which will
> help in
> > > > future analyses and my determination of tEnd and nStep
> values.
> > > Could
> > > > you help me out with this? Thank you for your time!
> > > >
> > > > PS ? I have uploaded a wheelchair model that I am trying to
> fully
> > > > drive with the addition of trunk movement (right now the trunk
> is
> > > > fixed to the back of the wheelchair ? I wrote about two weeks
> ago
> > > with
> > > > a question about this model). It currently compiles, but I
> think
> > > > there is a problem with the initial conditions because the
> left
> > > side
> > > > of the body does not mimic the right side at load time. It was
> > > > working, and I’m not quite sure what I changed, but something
> seems
> > > > amiss?(The file name is SarahArmModel ? Muscles_6-11-07).
> > > >
> > >
> > >
> >
>

Hi John

You are right about this equation and also about the labels, at some
point it was the z direction which was driven, but then this was
changed without changing the labels.

Best regards
Søren, AnyBody Support

— In anyscript@yahoogroups.com, “johnzengwu” <jwu@…> wrote:
>
> Hi,
>
> What I understand is that the systems is applying:
>
> u1 + u2 + u3 =0
>
> where u1, u2, and u3 are the differenence between the motion-
markers
> and body-markers (in y-direction) at RAsisZ, LAsisZ, and SacrumZ,
> respectively. There was a small mistake in “JointAndDirvers.any”:
they
> should be labelled as “RAsisY, LAsisY, and SacrumY”.
>
> I may be wrong.
>
> John
>
> — In anyscript@yahoogroups.com, “AnyBody Support” <support@>
wrote:
> >
> > Hi Sarah
> >
> > No problem I will try to explain.
> >
> > This driver was created because we found that driving for
example
> > the pelvis directly in the z direction was not a good idea,
because
> > and error on leg length joit kinematics would the result in
unwanted
> > rotaions of the pelvis. Therefore we introduced this driver that
> > makes sure that the pelvis can have variations in height. The
driver
> > says that the height difference between the sacrum marker on the
> > pelvis and the free floating sacrum marker should be equal the
sum
> > of the the heigth difference between the asis markers.
> >
> > It is correct that in the Gait3D model the equation
> >
> > RAsisZ + LAsisZ = SacrumZ is being used
> >
> > it migth be that
> >
> > (RAsisZ + LAsisZ)/2 = SacrumZ
> >
> > would be better that is correct, this can be tested by chaning
the
> > coefficients. Changing these coefficients will not change the
> > model dramatically i think, but it is easy to try out.
> >
> >
> > Best regards
> > Søren, AnyBody Support
> >
> >
> >
> > — In anyscript@yahoogroups.com, “Sarah R. Sullivan”
<sarsulli@>
> > wrote:
> > >
> > > Just another follow-up question regarding driving a model by
mocap
> > data. I have been looking at the gait webcast from last August,
and
> > I am trying to drive the pelvis in the same way that it is
driven in
> > the webcast and I have a question regarding the statement that
> > RAsisZ + LAsisZ = SacrumZ. Should this be the average of the
two
> > Ases Z-directions? Just adding them together would give a very
tall
> > pelvis, right? Should it be (RAsisZ + LAsisZ)/2 = SacrumZ?
> > >
> > > Just trying to figure this out…hope I’m not bothering you!
> > >
> > > As always, thanks for your time,
> > > Sarah
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > >
> > > > Date: Thu Jun 14 07:56:16 EDT 2007
> > > > From: “AnyBody Support” <support@>
> > > > Subject: [anyscript] Re: Question about Recruitment Solvers
> > > > To: anyscript@yahoogroups.com
> > > >
> > > > Hi Sarah
> > > >
> > > > I have uploaded a new version of you application to the file
> > section
> > > > of the group it is named “SarahArmModel ? Muscles_6-11-
07V2” . I
> > > > have updated the InitialPosition.any file and made some
changes
> > in
> > > > the Mannequin.any file so now it loads at a reasonable
position
> > and
> > > > also run kinematically.
> > > >
> > > > Concerning the MinMaxNRSimplex solver you may experience
cases
> > like
> > > > you are describing. When the tStart, tEnd or nStep are
changed
> > it
> > > > means that the analysis will calculate for different time
> > values. If
> > > > the model is sensitive this may provoke recruitment problems
> > like
> > > > you have experienced. This basically means that a certain or
> > several
> > > > dof. in the model are difficult to balance with muscles
forces.
> > If
> > > > this is the case one solution is to try adding AnyReacForces
to
> > the
> > > > different dof in the model, if adding a AnyReacForce for a
> > certain
> > > > dof in the model makes it stable, it indicates that this
dof. is
> > > > causing the problem.
> > > >
> > > > The recruitment problem may also occur if there are very
strong
> > > > muscles present in the problem, this can make the model
> > numerically
> > > > difficult to solve. This can be the case if you have strong
> > pushing
> > > > muscles for generating support forces to the model, like on
a
> > > > backrest or similar. So sometimes lowering the strength of
these
> > > > muscles makes the model more stable.
> > > >
> > > > If you add a small amount of gravity to the directions of
the
> > model
> > > > having zero gravity, it also often helps making the
recruitment
> > more
> > > > stable. So something like Gravity = {0.01, -9.81, 0.01};
usually
> > > > helps without disturbing the solution of the problem.
> > > >
> > > > The next version of AnyBody will have some additional
settings
> > > > available in the solver. This can sometimes help solve
> > recruitment
> > > > problems if these are caused by numeric problems.
> > > >
> > > > I tried to make your model run inverse analysis, but it
seemed
> > that
> > > > one timestep was causing problems. The reactions in the GH
joint
> > are
> > > > created with a number of pushing muscles which ensures that
the
> > > > reaction force fall with the cavity of scapula. Due to the
> > loading
> > > > conditions of this model i tried to change the directional
> > reactions
> > > > in the glenohumeral joint back to a classic spherical joint,
and
> > it
> > > > help solve the problem. To introduce this change to your
brep
> > > > please do the following changes in Arm3d/jnt.any
> > > >
> > > > 1: outcomment the line "#include "“ghreactions.any”
> > > > 2: change the lines
> > > >
> > > > AnyKinEq GHLinCon = {
> > > > AnyKinMeasure &GHLinCon = .GHLin;
> > > > Reaction.Type={Off,Off,Off};
> > > > };
> > > >
> > > > to
> > > >
> > > > AnyKinEq GHLinCon = {
> > > > AnyKinMeasure &GHLinCon = .GHLin;
> > > > // Reaction.Type={Off,Off,Off};
> > > > };
> > > >
> > > >
> > > >
> > > > Best regards
> > > > S?ren, AnyBody Support
> > > >
> > > >
> > > > — In anyscript@yahoogroups.com, “Sarah R. Sullivan”
> > <sarsulli@>
> > > > wrote:
> > > > >
> > > > > I have a question regarding RecruitmentSolvers,
specifically
> > the
> > > > > MinMaxNRSimplex solver (although I’m sure my question
applies
> > to
> > > > the
> > > > > other Recruitment Solvers as well). I have noticed in the
> > past
> > > > (and
> > > > > with the current model that I am working on), that I will
> > > > occasionally
> > > > > get the following error when I am adjusting the tEnd and
nStep
> > > > values:
> > > > >
> > > > > ERROR(OBJ1) : MyStudy’ : Muscle recruitment analysis
failed,
> > > > > simplex solver reports that solution does not satisfy all
> > > > constraints.
> > > > >
> > > > > Depending on the tEnd and nStep values I plug in, I can
often
> > get
> > > > the
> > > > > model to run all the way through. For example, if I have
a
> > file
> > > > that
> > > > > has a kinematics time frame of 0-58, and a kinetics time
frame
> > of
> > > > > 0-116, I have noticed that changing the tEnd and nStep
does
> > not
> > > > always
> > > > > guarantee that the InverseDynamicsAnalysis will fully run
> > through;
> > > > I
> > > > > can have the tEnd be 58/120 (to represent a 120 Hz
sampling
> > rate),
> > > > and
> > > > > the nStep be 58, and the model will compile and run fine.
> > > > However, if
> > > > > the tEnd is (arbitrarily) 30/120, and the nStep is 30, the
> > model
> > > > will
> > > > > compile, however it won’t run to completion. And often,
the
> > length
> > > > > that the model will run before failing varies in a non-
> > decipherable
> > > > > pattern. If my tEnd and nStep is 25, the model may run
until
> > 22
> > > > > before failing ? completing nearly the entire analysis.
> > However,
> > > > if
> > > > > my tEnd and nStep is 55, the model may run to only 9
before
> > > > failing ?
> > > > > hardly completing any of the analysis.
> > > > >
> > > > > I’m sure there is a simple explanation for this which will
> > help in
> > > > > future analyses and my determination of tEnd and nStep
> > values.
> > > > Could
> > > > > you help me out with this? Thank you for your time!
> > > > >
> > > > > PS ? I have uploaded a wheelchair model that I am trying
to
> > fully
> > > > > drive with the addition of trunk movement (right now the
trunk
> > is
> > > > > fixed to the back of the wheelchair ? I wrote about two
weeks
> > ago
> > > > with
> > > > > a question about this model). It currently compiles, but
I
> > think
> > > > > there is a problem with the initial conditions because the
> > left
> > > > side
> > > > > of the body does not mimic the right side at load time.
It was
> > > > > working, and I’m not quite sure what I changed, but
something
> > seems
> > > > > amiss?(The file name is SarahArmModel ? Muscles_6-11-07).
> > > > >
> > > >
> > > >
> > >
> >
>