yade-dev team mailing list archive
-
yade-dev team
-
Mailing list archive
-
Message #06375
Re: twist/bend increment computation
-
To:
yade-dev@xxxxxxxxxxxxxxxxxxx
-
From:
Janek Kozicki <janek_listy@xxxxx>
-
Date:
Wed, 1 Dec 2010 18:44:46 +0100
-
Face:
iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAALVBMVEUBAQEtLS1KSkpRUVFXV1dYWFhjY2Nzc3N3d3eHh4eKioqdnZ24uLjLy8vc3NxVIagyAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH2AIVEzgS1fgQtQAAAjRJREFUOMtt1DFv00AUAOAzFQNbjigSyoQaRaBMhKgLUyKXpVNNeUpk9vyDqFJhQ1kiBuaqAwJCqvPtSLY7RlTn5+5IdnYkkt/AOyfxXVLe5vf53Z1875kd34tOEax8djmj6GyjhB5bxz50GdsVZr9fqRjZwAtKOJw5Wqs2MMZ16ALHsaDncF7xAHix1oEFHAB8f+pRjcO4gfZDykcYzbiucRolOLUJ6kjA0xtVt+A6TySlM0RajIpK6DzwKZ/nOYbF/gclHMo1ZOHYY/+Ha+AWuM+3oMS4eeqYzZ8FiCltgUqI8cd2wwAVpJk+8LWYjBtnJdQpHQqJMd4Oxt4bU9ESiFGc5hkqaH74asAX4iabP5I5gZ+qjgGlJCqZa3h3lxhoeVcSE1qLQC4sqKOK9MGW9E3izFqqHokoztLFEgXg31sbZEKnWi2T74A4NxfVQqlkjKtcAWD+zcArFEES01dR0E/nnV0IgugmDd/2L84sOAouRBBHEc7gtc8teDkRlE0iNQPo2w3Xhh/D4TCIQ4LRLoTvgwjj6RRgavdurxYGMaIuGOyAW/PpNlCcU9/93AHenAWYjPoAwa+G3e3to/MgFNTAEKvKDjzuCzHTnY3qqdXtx24VijzQfZ0yewZ5cwRFQaa+mIYr1uI0I76+3W4xhlvoVRwOA0Fdl64HlJnxP6T8YpX/Lga4Wv4A3ErrU5oTfN7Mu/llXMl8RXEPji/lQkN3H7qXqgC2By47EXeU/7PJ/wPxRKMnuZwIeAAAAABJRU5ErkJggg==
-
In-reply-to:
<4CF680BE.50103@doxos.eu>
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.
The approach with velocities isn't something that I could elaborate
on, sorry - not enough experience with this one.
--
Janek Kozicki http://janek.kozicki.pl/ |
Follow ups
References