yade-users team mailing list archive
-
yade-users team
-
Mailing list archive
-
Message #02834
Re: TranslationEngine Vs JumpChangeSe3
>
> Yes, I confirm (by myself :-) ) that doing so we account for the
> applied displacement twice. Actually this fact is already documented
> and avoid in JumpChangeSe3 class. Maybe we can add a comment also in
> TranslationEngine so that if one wants to use it on dynamic bodies, it
> knows that in such a way you apply the displacement (giving velocity
> as input) twice.
> Actually I do not see another way to apply TranslationEngine to
> dynamic bodies avoiding this problem. In fact, one could use
> JumpChangeSe3 on dynamic bodies as well, but not using ScGeom since it
> needs velocities.
There is actually https://bugs.launchpad.net/yade/+bug/398089 which is
closely related.
Reading JumpChangeSe3 (wouldn't it be better to call it StepChangeSe3,
or rather StepChange... something else?) code, positions are updated "by
hand"
if(!setVelocities || (setVelocities && !b->isDynamic))
i.e. either (1st case) NewtonIntegrator will not update position because
velocity is zero, or (2nd case) NewtonIntegrator will not update
position because the body is not dynamic.
TranslationEngine doesn't make this distinction, it wasn't really
(probably) conceived for such fine-grained control.
One could add a flag to JumpChangeSe3 so that the delta wouldn't mean
delta in one timestep, but in 1 second; that would make it functionally
superset of TranslationEngine actually.
(I was also planning -- or I've written but never commited --
interpolating engine between start and end position&orientation for a
particle....)
Cheers, v.
Follow ups
References