yade-dev team mailing list archive

[Janek Kozicki <janek_listy@xxxxx>]

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/  |