Body::isDynamic semantics is not clearly defined

[Václav Šmilauer]

Does isDynamic means that Newton's laws skip the body? Or that forces don't contribute to its velocity? Various Translation/RotationEngines rely by convention on that Newton's laws skip the body completely.

There was a discussion on that topic http://thread.gmane.org/gmane.science.physics.yade.devel/1059 and we should draw conclusions now.

[Bruno Chareyre (bruno-chareyre)]

For me, isDynamic==false clearly means that the time integration is not done on this body, and Newton's law skip it. It will be moved by other engines, or not moved at all.
BUT it means nothing more. For instance, we still need the force on this body (e.g. TriaxialEngines need the force to move the boxes consistently).
I agree it could also mean : "Newton's law will move it with constant velocity", but no, it doesn't, it would add complexity.

[Bruno Chareyre (bruno-chareyre)]

Velocity needs to be defined for non-dynamic bodies too, to compute interractions correctly.
I realise it is not what I was suggesting in gmane archive... but I feel like changing the logic of translation/rotation/triaxial engines would be painfull.

[Václav Šmilauer (eudoxos)]

If the only thing is painfulness, I am willing to undergo it. There is not so many engines and it is easy to check them.

The reason I would like to have it handle like you proposed originally (at gmane) is twofold:

1. In the translation engine, you have to set _both_ velocity and displacement; if you forget velocities (which some of the engines don't do currently IIRC), you will get bad interactions. In the case Newton uses the velocity information, like for all other bodies (except that it doesn't have acceleration), you get the second part for free, using the code that is already there.

2. NewtonsDampedLaw now computes a few characterstics, like maximum speed, of bodies. This concerns non-dynamic bodies, too. To avoid code duplication and conditionals, it would be nice to have these two united.

What do you think?

[Bruno Chareyre (bruno-chareyre)]

It makes sense, but I don't have the full picture in mind.

For instance : TriaxialEngine is controlling the position (and perhaps
not defining vel, so tangential disp is wrong, I don't care because
I never use wall friction...). So, what will happen in Newtons damped
law?
Does it mean, we have to switch in this engine from pos+=disp to
vel=disp/dt (with !isDynamic)?

If you want to make this change, it is ok with me.

===================================================================
EASY and FREE access to your email anywhere: http://Mailreader.com/
===================================================================

[Václav Šmilauer (eudoxos)]

What I meant:

If you don't set velocity (TriaxialEngine), Newton will still integrate the zero velocity to position change, but it will be zero; nothing will change with respect to the current behavior. (Note, however, that with new collision optimizations, this could make contacts being missed as the wall can get out of its bbox without anyone else knowing!).

The difference isDynamic/!isDynamic would be that dynamic bodies have _additionally_ accelerations computed from forces and torques and this accelerations will influence velocities; both of them will have velocities integrated and positions updated.

[Václav Šmilauer (eudoxos)]

For future reference what engine would have to be changes to use velocity instead of touching position etc:
1. CinemCisEngine (only displaces); (CinemCNCEngine, CinemDNCEngine, CinemCNCEngine seem to both change velocities and update positions; Jerome will have to check his code).
2. DisplacementEngine (sets positions; what is Omega::isoSec?)
3. DisplacementToForceEngine (sets position; what is that thing supposed to do???)
4. InterpolatingSpiralEngine (sets positions, no velocity)
5. RotationEngine (sets only angularVelocity, but displaces by setting position directly, without velocity!)
6. TranslationEngine (sets velocity AND updates positions)
7. FixedOrientationEngine, FixedPositionEngine (set position/orientation directly; should be deleted, as we have blockedDOFs)
8. JumpChangeSe3 (has bool setVelocities; used only for testing)
9. Se3Interpolator
10. StaticAttractionEngine
11. ResetPositionEngine (that is OK, warps particles from time to time to another place)
12. ThreeDTriaxialEngine, TriaxialCompressionEngine (only updates positions)
13. LatticeLaw (that is - I assume - OK, since lattice doesn't use velocities and dynamics)

You see there are some inconsistencies, i.e. we have to go through that code anyway. Can I start with that?

BTW There is so much garbage code in the treee :-(

[Václav Šmilauer (eudoxos)]

A related issue is PhysicalParameters::blockedDOFs. Currently it means that acceleration is not integrated, therefore they keep constant velocity (zero, unless you assign some yourself).

If we change the meaning of isDynamic as I proposed, it would mean that both do the same thing, except the blockedDOFs are more fine-grained.

If we don't, I would still like to make isDynamic less ubiquitous and use it only in very exceptional cases where setting blockedDOFs==DOF_ALL and vel=disp/dt wouldn't be possible.

Still there might be an issue with vel=disp/dt, as dt might change during the timestep. Maybe we should guarantee that dt is constant throughout one iteration -- by assigning only to MetaBody::nextDt, and it would not be until the beginning of the next step that the assignment dt=nextDt would be made.

Yet another thing: isDynamic used to have the function of avoiding interactions of 2 bodies that are not dynamic. That is not true (since as far as I remember), although the inline documentation still says so??

[Václav Šmilauer (eudoxos)]

(no chance to do this for 0.20, deferring to 0.30)

[Jérôme Duriez (jduriez)]

I only (re?)discover this. (summer holliday threads are difficult for me to follow...)

So my point of view is that I would be glad that NewtonsIntegrator takes also care of non dynamic bodies by displacing them according to a velocity coming from somewhere else than forces.

In my present case it would allow me to control easily the movements of non-dynamic bodies in python scripts (for test of constitutive laws for example)

[Bruno Chareyre (bruno-chareyre)]

Still open? I completely agree with you Vaclav. Let blockedDOFs and isDynamic==false be the same thing.
Is it what I said on Gmane? Perhpas I changed my mind twice!

[Václav Šmilauer (eudoxos)]

That needs work on the c++ side (you can change Body::isDynamic to an inline function bool Body::isDynamic{return state->blockDOFs!=State::DOF_ALL; } ), in python it already is a property (which is got/set via a function call), so the conversion will be easy.

[Bruno Chareyre (bruno-chareyre)]

Ok. Looking at the secondary points :

>Still there might be an issue with vel=disp/dt, as dt might change during the timestep.

Good point, I never realized that. Is it still relevant?
Delaying dt has almost the same effect than forcing the time-stepper engine to be in first or last position in the loop, but delaying dt transparently is more user-friendly and foolproof.
However, if this is implemented, there should still be away to force immediate dt change, for those who know what they do. It can be used in more sophisticated integration algorithms, predictor-corrector and alike. If not, we would be a bit hardlocking Yade with 2nd order finite differences.

[Václav Šmilauer (eudoxos)]

the Δt changing during the step can be an issue for a particular ordering of engines (such as TranslationEngine, then time stepper, then integration with different Δt than was for TranslationEngine); for me, it is not important.

[Bruno Chareyre (bruno-chareyre)]

A quick implementation of new isDynamic semantic here : https://lists.launchpad.net/yade-users/msg03220.html
The good point in this exemple is non-dynamic bodies need less operations than dynamic ones (it doesn't integrate acceleration, the opposite of blockedDOFs which change acceleration, then integrate it).

[Václav Šmilauer (eudoxos)]

I think you lost track of current development.

Since about 2 weeks back, Body::isDynamic() is a function; it still accesses Body::dynamic (not to be accessed directly) and at some point, when we check that engines that need it are updated, it will only modify State::blockedDOFs accordingly (DOF_ALL or DOF_NONE); then it will be completely removed perhaps (?)

[Václav Šmilauer (eudoxos)]

(BTW this last development was in reaction to #10).

[Bruno Chareyre (bruno-chareyre)]

Yes, the file sent is using the old isDynamic, I knew it was just a quick hack (to test Chiara's script).
The logic is in line with #10, and the advantage of less operations still holds (same result could be obtained by replacing isDynamic by DOF_ALL in the diff).

[Václav Šmilauer (eudoxos)]

fixed in r2607, where the dynamic flag was removed (superseded by State::blockedDOFs)