Hello,
I am working on lumbar spine models, in the AMMR version 1.6.2. I tried to simulate a simple 30 degrees flexion with both the Facet Joint Model and the Spine Fixation using FDK model. In each case I enabled the lumbar ligaments and left the disc rotational stiffness active.
Therefore I thought the only difference was the fact that spine rhythm was active only in the Facet Joint Model (and I understand they differ in how the facet joints are modeled, but that should not have any impact on flexion movements). So I did not expect significant differences between the two models’ results.
But results of the simulations show a big difference in the vertical (y-direction) reaction forces at the lumbar joints. In some joints in the order of 150 N. I am attaching the two graphs corresponding to the two models.
How is that possible? Am I doing something wrong?
Sorry, I forgot to mention that I commented out the line #include “Model/SpineFixation.any” in the Spine Fixation model, so that the fixation device is not enabled.
I had a look at the SpineFixation model and see that slightly different anthropometric measurements are used in this case. This may explain some of the difference.
thank you for your answer. Unfortunately I couldn’t quite understand your suggestion; in both cases I checked the same outputs, that is:
“Main.Study.Output.Model.HumanModel.Trunk.JointsLumbar.<joint_name>.Constraints.Reaction.Fout[1]”
Do you mean those values in the two models are calculated in different ways?
In the SpineFixationWithFDK model you can find the following lines, which you have seen in the tutorials in the anthropometric scaling section - it means the human anthropometric measurements are defined in the AnyManUniform.any:
// Define scaling law as ScalingLengthMassFat and provide anthropometric measurements
#define BM_SCALING CONST_SCALING_LENGTHMASSFAT
#path BM_SCALING_ANTHRO_FILE "Model/AnyManUniform.any"
Whereas FacetJointModel uses our generic human, which does not match the height and weight used in SpineFixation model.
That may explain the problem, but i would make some tests to check that this is the case.
thank you for the suggestion, it seems that scaling was actually the problem.
I am now trying to simulate a flexion of the spine with the Spine Fixation using FDK model. As a modification to base model (which I use without the fixation device), I defined the lumbar joints as 6 degrees of freedom joints, with linear stiffness’s for the translational movements, and made those translational DOF Force Dependent.
My problem is that step zero of the simulation includes the initial “adjustments” of the vertebrae to gravity: they translate and rotate. The rotations are a problem, in particular, because as I understand ligaments are calibrated before those rotations, and therefore at step zero they are not at zero length, but instead they are shorter. Therefore, they do not develop any force until the simulation is at around 60%. I am attaching pictures of lumbar ligaments forces and of joint rotation for L4L5.
This results is much lower forces than in the Facet Joint model, both at step 0 (when I expected them to be pretty similar) and at the end of the flexion movement.
Is there any possible workaround, to make the simulation start in the prescribed modeled positions? Like activating FDK at step 1 instead of 0, maybe?
Calibrate ligaments after the initial “adjustments” would help, too, but the forces at step 0 would still be different than in the Facet Joint model without FDK.
You are asking a difficult question. It is a “chicken and egg” problem - if you re-calibrate the model in a new posture, your FDK solution will quite likely give you a new initial posture.
Ideally you want to select a “true” posture, calibrate ligaments properly, and believe it. If calibration is good - it should ideally give calibration posture. It is probably easier if you have a personalized model with an MRI/CT scan, which you can use to segment your initial/calibration posture out.
The problem might also be that for different ligaments different positions are needed. All together it is up to someone to define the best calibration strategy.
Could i also ask what kind of input data do you have?
If I understand correctly you are saying the ideal solution would be to have a real posture to start with, so that I can calibrate the ligaments, and when I start the inverse dynamics the step 0 of FDK will not modify the initial positions because they were real and therefore no adjustments by FDK would be needed. Is that correct?
In my case I do not have any real geometry or any external input data; I am using the demo models and I drive the motions with built-in drivers, trying to replicate results I found in literature.
Since with this approach I do not get reasonable results, I would have the following questions:
as you say, the FDK gives me a new initial posture, after ligaments have been calibrated, generating zero force in the ligaments for more than half way through the simulation. Is it possible to force the inverse dynamics to accept the prescribed posture, skipping this new initial posture adjustment by FDK?
if not, is it possible to “limit” the FDK capabilities? The FDK initial posture adjustment involves significant rotations, would there be a way to limit the magnitude of the rotations driven by FDK at each step?
in case none of the above is a possible solution, and in your opinion there is no other way, the only option would be to switch off the FDK on rotational DOF and switch the spine rhythm back on, is that correct? If so, would you suggest to modify the SpineFixation model in that sense, or to add the FDK on translational DOF in the Facet Joint model?
not really, FDK solver tries to find a position, where all forces are in equilibrium for the particular time step, the only way to ensure that it takes certain kinematics is to ensure equilibrium at exactly that point (and reasonable initial guess).
you can control amount of rotation by increasing/decreasing stiffness of the elements, which would affect rotation.
Could you briefly describe or show code how you model FDK for the trunk? Is the stiffness behavior linear or nonlinear? I think the problem is that when you switch translational DoF on - the FSU collapses, which leads to the laxity and ligaments and it takes some time before they engage. Could you increase stiffness in the translational DoF? How much does the superior vertebra “sink”?
I can’t really modify the rotational or translational stiffness of the joints, as they are based on experimental studies and I need to use realistic ones.
I defined a linear translational stiffness; after setting the spherical joint constraints as force dependent, I introduced an AnyForce class element, at each joint, based on the linear positions of the joint itself (x, y and z). The force in every direction is the stiffness multiplied by the correspondent linear coordinate (x, y or z). I hope I was clear enough.
It happens, indeed, that when I start the simulation the vertebrae collapse under gravity, and as you say that causes the laxity of ligaments, that don’t develop any force at the beginning. But if I use the spine rhythm, deactivating FDK on rotational DOFs, ligaments are engaged much earlier, and forces are in fact more reasonable. So I guess the rotation of the vertebrae when FDK is active on rotational DOFs (as per default model) makes things worse.
As a reference I am attaching the graphs of ligaments forces when FDK is not active on rotations (and spine rhythm is used), and of the linear translations of one of the joints. Relative translation of the superior vertebra is around 0.22 mm at step 0.
As I said, I cannot change the experimental translational stiffness, that is also the same that was used in another AnyBody study publication in literature.
Would you suggest to move the drivers folder outside of the model folder and then create some calibration drivers that would position the lumbar joints in a different posture (the one output from step 0 of inverse dynamics)?
Or is there any other possible workaround?
The joint nodes for the instantaneous centers/axes of rotation are found in a pre-compressed state (enough compression for them to behave as an ICR), and it is not correct to add a spring as you described for the linear DoF (if i understood it well). Try adding a some sort of offset on these springs? Possibly make a parametric/optimization study that will help find the realistic position.
As you see it comes back to finding a more realistic calibration posture.