Janek Kozicki said: (by the date of Wed, 1 Dec 2010 18:44:46 +0100) > Václav Šmilauer said: (by the date of Wed, 01 Dec 2010 18:07:10 +0100) > > > > > > also, I don't know what is the meaning of symbols that you used in > > > formulas above: v₁,ω₁,x₁, etc... > > > > v for velocity, ω for angular velocity, x for position (sorry,I thought > > this was quite a common notation). > > that was my guess, but better be sure than sorry. And what is u₁ and > us? shear displacement? > > > > > The second formula I wrote was not correct, I think it should read (not > > thoroughly checked either) > > > > $$\dot\varphi=2\left[\frac{u_1+u_2}{2}\frac{1}{|x_2-x_1|}\right]-\frac{(x_2-x_1)\times(v_2-v_1)}{|x_2-x_1|^2}$$ > > > > (I discovered https://addons.mozilla.org/it/thunderbird/addon/48583/ , > > nice thing!) > > this formula seems complex, I'm not able in present state to parse it > fully. Would need more dedication. > > > Now, whether to use the (anti)symmetric split vs difference of angular > > velocities... What is the reason to use the second one, as you do in > > ScGeom6D for instance, > > umm, me? I don't remember touching ScGeom6D. > > > is there something physical reasoning behind, or > > is it just an arbitrary choice? How about other DEM codes? > > I was thinking in terms of coordinate systems that rotate relative to > each other. Forget spheres, forget radii. Just axes. Their > orientation are quaternions, and I just calculated their rotational > displacement. > > Aha! I'm getting to understand what you mean, an incremental > approach. Is it doable with quaternions? > > If you store prevOrientation instead of initialOrientation on each > iteration, the calculated delta of rotation will be only for > present iteration. Now if you combine together all those deltas from > start to present iteration (just multiply them in order) you will get > a total rotation and will be able to produce your acting moment. > > How to avoid mistake in case of > 360 deg rotation? (the case which > quaternions do not cover correctly). > > You would need to track the real part of quaternion, that one which is > subject to acos(a) when converting to axisAngle(). If it "jumps" > suddenly from -1 to 1, or opposite, then it's a sign that we've > crossed the 360 boundary and need to add or substract it to the > angle when calculating moment. This seems hackish, I agree. But this > is the way I feel it works.
I just had a thought, that you could: - use prevOrientation instead of initialOrientation - and accumulate moment instead of deltas (as quaternions) by this way you will go around the 360deg problem, because moment will not be accumulated in degrees but in [Nm]. Perhaps this is the way to calculate twisting and bending incrementally. -- Janek Kozicki http://janek.kozicki.pl/ | _______________________________________________ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp