I’m actually working with the version 2.0.1 of AnyBody and the repository 6.0.1.
I’m simulating an abduction from 15 to 120 degrees, in the plane of the scapula. To do so, I drive the clavicle, the scapula and the humerus with kinematic values from Ludewig (2009) article (relative angles between ref frames). I noticed that the artificial rake for the deltoid muscle is built in a way that it always keep the same radius. This is not a problem in the early stages of the abduction, but at some point near the end of the motion, the rake seems to be too thigh and the muscle pathway looks like a “V” shape (see the attached file). As a consequence, it affects the recruitment process, the amplitudes of the forces and their orientation as well. From my point of view, this is not a good representation of the real case.
If you think this is a good representation, you’ll have to tell me why.
Otherwise, did you change the algorithm in the latter versions of AnyBody to avoid this ? If not, do you think there would be an easy way to avoid it ?
The artificial rake is probably not perfect and it is right that this V shape of the muscle may be more straight in reality. But i don’t think it will have a so big influence on the results.
Of course the kinamatic of the rake can be modified and you are free to do it if you feel the need. We are not planning to change this kinematic right now but it is good anyway that you point at such things, any suggestions for improvement are always welcome.
I totally understand that you missed my thread. That’s the reason why I decided to write you back.
I agree with you that for the intact shoulder model (i.e. the one with all the muscles in it), the “v” shape doesn’t change the results a lot.
However, my ultimate goal is to simulate a massive rotator cuff tear with a permanent contact between the humeral head and the acromion, as it has been seen clinically. Thus, the only remaining muscle is the deltoid and his job is to raise the arm and hold the permanent contact.
You will understand now that if the deltoid pathway is not simulated with a sufficient precision, it would lead to a false representation of the muscle forces, because, as some divisions of the deltoid (specially the anterior fibers) are falsely pointing upward, the recruitment algorithm doesn’t have the right simulation conditions and doesn’t give the right results.
In other words, if the true pathway would make these divisions to point less upward, I think that the optimization algorithm would give a different pattern of activities or would say that the kinematics conditions cannot be fulfilled at a given time during the simulation (lack of muscles to do the job).
I do have an idea to improve the deltoid pathway behaviour, but I’m not sure how to program it in the software. Your help would be appreciated here. My basic idea would be to add an “IF” condition that switches between an “obstacle pathway” algorithm and a “Direct pathway” between the origin and insertion of the deltoid, when no obstacle are touching the muscle divisions. In my previous works (master degree), I suceeded to do this with a little Matlab program. However, the AnyBody core programmation is a little bit to complicated for me, so if you think that it can be done in AnyBody, I would be very happy.
I hope that you will agree with this possible improvement in the model.
Bonjour!
Here comes a long shot.
Concerning the “switch”, do you know by just looking at kinematics when this will/should happen? If so, an easy solution would be to run 2 (or several) simulations with different defined pathways (viapoints) for the muscle. Like, 0.00-0.31 s with pathway X and then 0.32-1.00 s with pathway Y. As it is static optimization, this would be ok.
btw, can you post a full reference to Ludewig (2009)?
A bientôt!
/jokke
That’s a good point. I’m sure that it’s possible to find a solution by this way, but I’m searching for a solution that will be more flexible, with no need to do the simulation twice.
The fact is that I want to change a lot of parameter, like the origin and the insertion of the deltoid, or the center of rotation of the humeral head. If I have to perform the tests twice at each time, that would be very long. Also, considering a possible improvement to the model, it would be better to find a direct solution.
Here is the Ludewig reference :
[b][i]Motion of the Shoulder Complex During Multiplanar Humeral Elevation
Paula M. Ludewig, Vandana Phadke, Jonathan P. Braman, Daniel R. Hassett, Cort J. Cieminski and Robert F. LaPrade J Bone Joint Surg Am. 2009;91:378-389. doi:10.2106/JBJS.G.01483[/i][/b]
Bonjour!
OK, I get your point.
Thanks for the reference. It might be useful for improving my skiing simulations, as one current limitation is the “stiff” shoulder complex. And most cross-country skiing techniques have a large range of motion of the upper arm, together with rather large movements of the shoulder complex.
/jokke
I can not see any way of letting a muscle change from being an shortestpath muscle to a via point muscle dependent on some kinematic measure, this is what you are looking for right?
You can do swicthes in terms of forces, so you can swicth reactions in and out dependent on kinematics, but the same goes not for kinematics. Kinematics in this case a muscle path can noy be swicth to another type dependent on kinematics, this can only be changed a lot time.
I am not sure i fully understand the difference between the two paths of the deltiod in the two cases, and what goes wrong with the normal obstacle path. I would initially look for ways of improving the current path to be usefull in both situations, but i guess you have tried this.
Anyway if it was possible to switch between the two types this would create jumps in muscle length and velocity this may lead to undesired activations.
If you did a small skecth on the two cases it might help to better understand your model.
Personnally, I judged this “V” shape as annoying, because it doesn’t fit with my logical representation of the right deltoid pathway. Maybe you can give me an explanation of why you think this is a good way to simulate the path.
Anyway, here is my opinion about the existence of an artificial rake and why I guess that it should be improved (please correct me if I’m wrong):
The shortestpath muscle is the best way to simulate the interaction between the muscle and the bone. However, this is not sufficient for the deltoid muscle pathway, as you want each divisions to be properly aligned and you don’t want the muscle to slide freely on the humeral head surface. Thus, you add a series of via-points, which together creates the artificial rake. The motion of the rake is driven in rotation, according to a ratio based on the humeral rotation. However, the rake is not driven in translation, as it’s fixed on the “GH Node” of the scapula.
Now when the humerus is elevated at some degree, let’s say 60 (scapulo-humeral angle), the muscle no longer touches the bone (see the picture “Deltoid_pathway_Dufour (2005).jpg”). From my point of view, the divisions should not pass through the via-points beyond that angle, but should rather goes from the origin to the insertion directly.
In 2D, if the muscle is driven by only the shortestpath algorithm, there is no problem. But this is not the case in 3D, as we need these via-points for the rake.
So, my question is : Is there a possibility to disable these via-points at a certain degree ? If not, is it possible to drive the translational kinematics of these points to avoid the V shape, or at less, to give a more physiological pathway ?
Now i understand the problem better, to be honsest i did not read all the post so i missed the point that it was the rake that is the root of the problem.
There is one solution but it is going to cost some extra calcualtion time:
The solution is to introduce warpping surfaces on the rake, the idea should be to make the rake a real rake where all the teeths of the rake are created as cylinders. So you would neeed to introduce a number of thin cylinders pointing away from the the gh center and then get rid of the viapoints on the rake. Then the cylinders should prevent the sideways sliding and the muscles will be allowed to let go of the surface, when the arm is lifted high.
It is not a perfect solution due to the thin cylinders you will need a high number of points on the muscles to get a good wrapping, this will slow down computations.
It is ofcourse also possible to drive the translations of the rake as you suggest, but this will also have to be done using a linear rhytm like for the rotations so i guess this wil not solve the problem, you can not make this translation conditional.
That’s a good idea. I’ll test it right now. I should also provide you a comparison between the old and the new rake, as it will provide us a proof that it’s effective (or not).
After some tests, I figured that the first solution (cylinders) take too much time to compute and doesn’t represent the distribution of the muscle around the shoulder joint. I tried different way to orientate these cylinders, but no one gave me good results.
Thus, I decided to keep the integrity of the rake, and instead, I drove it in translation. To do so, I released one translational degree of freedom (X axis (Ref 1) of the “Deltoid Muscle Connector” joint) and simply drove its velocity with a kinematic driver (AnyKinEqSimpleDriver). Now, the good point is that the computation time is not increased, but the bad point is that the ‘V’ shape is still present on the anterior part of the muscle (divisions 7 to 12).
Thus, I decided to drive the translation of the anterior part separetely from the rest of the muscle. First, I duplicated the ‘Artificial Rake’ folder, and then, I made one for divisions 1 to 6 and another one for the divisions 7 to 12 (anterior part). By this way, I’m now able to put an higher translation speed for the anterior part, in order to get rid of the “V” shape faster. Finally, I also gave it a little rotationnal speed (Y axis), in order to make it follow a “good looking” pathway.
Note that all these changes are hypothetical, and my goal is to get closer to a more representative behavior of the whole deltoid. Even if it doesn’t change the simulation results when all the muscles are considered, I’m conviced that this will, in turn, make a difference when only the deltoid is present (i.e. massive rotator cuff tear).
I would appreciate your comments on these changes. I would specially like to know what are the consequences and/or the risks associated with them.
Too bad that the wrapping solution did not work successfully, it would have been someway simpler.
Your solution sounds ok i guess, but controlling the translations in a good and generic way must be tricky i guess.
Please be awre of the reactions you are adding to the model in terms of the various drivers for the translations, it is a good questions if these should be On or Off in principle i think they should be Off but i get this model right i do not think this would run.
The wrapping solution was simpler, but took too much time to compute. Also, I get a simulation error very often which forced me to increase the ‘SPLine.StringMesh’ to a value of 70 for some muscles. This was another reason why the simulation was slowed down.
You’re totally right, I don’t know yet how I should control the translation in a generic way. I put the translation because I thought that when the anterior muscle contracts, its envelope, which is seperated from the rest of the deltoid, trends to be more oriented towards the direction of the force, somewhat like an elastic that you would stretch. Thus, I don’t really know how to link the translation to the force applied by the anterior part of the deltoid. Do you think that switching ON or OFF the reaction force of the translation driver would make a difference ?
I am not sure about how much difference the reaction forces will make in this case, but i think you should check the value. Since there is motion and force in this case it will add energy to the mech. system.
It will not be possibe to have the motion dependent on the force unless you run and invese inverse analysis.
I get your point. I’ll check that. My idea to separate the anterior portion of the deltoid was finally wrong. From a physiological point of view, it seems that the 3 portions of the deltoid make a whole. In fact, if you cut the deltoid at its origin and insertion, you should obtain only one muscle, and not 3 distinct parts. That made your artificial rake even more realistic then I though.
I will go back to the last version of the rake with all the via points in the same folder, but I’ll keep the translation driver. I’ll check the reaction force related to it.
I realized that the annoying V-shape was partially related to the fact that the clavicula and the scapula were fixed during the abduction. Now I move the clavicula and indirectly the scapula (via the CA ligament driver) and it’s much more representative.
Finding the velocity of the translation for the artificial rake driver was too uncertain. Thus, I re-tried to apply you idea of cylinders, but this time I succeeded.
After a fine tuning of some parameters (e.g. cylinder radius and positioning as well as muscles SPLine stringMesh and InitialPosVectors), I get a better representation of the deltoid rake for the scapular part. Muscles are still moving on the wrapping surface, but the movements are less important.
I think these movements may not influence the results much, but it is hard to say without having seen it visually. I assume that the motions is sideway translations of the muscle, if so this may not change the moment arm much.
I come back to you about the deltoid artificial rake after a long break of trying to improve it.
Recently, I studied muscular activation estimated by the AnyBody shoulder model during abduction and scapular elevation. I was using the actual artificial rake of the deltoid. I found that the anterior part of the deltoid is not recruited at all (you can test it if you want). However, literature studies seems to say that the anterior part of the deltoid is recruited just like the middle portion (Wickham et al. 2010, Alpert et al. 2000 — see attached pdf).
From my opinion, this poor activation of the anterior deltoid is due to the artificial rake, which creates anterior fibres with unfavorable lines of action. I’m actually trying a new method to simulate the complex geometry of the deltoid. Instead of the artificial rake, I use 2 contact ellipsoids and 3 cylinders optimally positioned on the scapula. The new estimations are more concordant with literature data and not only for the anterior portion of the deltoid.