O.forces.addMove does not work

[Jan Stránský]

Hi,

I tried O.forces.addMove to apply displacement to a particle, but the method seems not to work..

b = sphere((0,0,0),1)
O.bodies.append(b)
O.forces.addMove(0,(1,0,0))
print b.state.pos # (0,0,0)
O.step()
print b.state.pos # is (0,0,0) again...

Is this behavior ok, do I do something wrong or is it a bug?

I use Ubuntu 14.04 and yade 2014-11-08.git-d693417

Thanks
Jan

[Bruno Chareyre (bruno-chareyre)]

I stumbled across this addMove a few times when working on the collider and other things but I never understood clearly what it was supposed to do. Not sure it has ever been completely implemented, Vaclav could tell maybe.

I would suggest to remove all of it if it doesn't work. "b.vel=" is good enough to impose a displacement, I don't think we need anything else. It is also a bit strange to impose a displacement through the force container.

[Václav Šmilauer (eudoxos)]

Hi, the code was always working, and still should be, in NewtonIntegrator.pp:208 (and 2 other lines for rotations) I read

   if (scene->forces.getMoveRotUsed()) state->pos+=scene->forces.getMove(id);

It was supposed to impose displacement or rotation change directly, and to do it in a way which is thread-safe; changing b.vel may affect other computations going on in that timestep, plus it usually supposes that dt does not change between steps (not always the case). But I see there is only little use for it, and I would have to remember hard what was the reason to introduce it back then. There must have been one :)

@Jan, do you have NewtonIntegrator in engines?

[Jan Stránský (honzik)]

Hi Vaclav, yes, NewtonIntegrator is in O.engines by default if you do not
change it..
Jan

2014-12-19 16:57 GMT+01:00 Václav Šmilauer <email address hidden>:

> Hi, the code was always working, and still should be, in
> NewtonIntegrator.pp:208 (and 2 other lines for rotations) I read
>
> if (scene->forces.getMoveRotUsed())
> state->pos+=scene->forces.getMove(id);
>
> It was supposed to impose displacement or rotation change directly, and
> to do it in a way which is thread-safe; changing b.vel may affect other
> computations going on in that timestep, plus it usually supposes that dt
> does not change between steps (not always the case). But I see there is
> only little use for it, and I would have to remember hard what was the
> reason to introduce it back then. There must have been one :)
>
> @Jan, do you have NewtonIntegrator in engines?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1400075
>
> Title:
> O.forces.addMove does not work
>
> Status in Yet Another Dynamic Engine:
> New
>
> Bug description:
> Hi,
>
> I tried O.forces.addMove to apply displacement to a particle, but the
> method seems not to work..
>
> b = sphere((0,0,0),1)
> O.bodies.append(b)
> O.forces.addMove(0,(1,0,0))
> print b.state.pos # (0,0,0)
> O.step()
> print b.state.pos # is (0,0,0) again...
>
> Is this behavior ok, do I do something wrong or is it a bug?
>
> I use Ubuntu 14.04 and yade 2014-11-08.git-d693417
>
> Thanks
> Jan
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/yade/+bug/1400075/+subscriptions
>

[Bruno Chareyre (bruno-chareyre)]

I see, thanks. The problem is that many parts of the code assume consistency between displacement and velocity, addMove breaks that.

[Janek Kozicki (cosurgi)]

Bruno Chareyre said: (by the date of Fri, 19 Dec 2014 16:46:02 -0000)

> I see, thanks. The problem is that many parts of the code assume
> consistency between displacement and velocity, addMove breaks that.

If you do:

  grep addMove --exclude="./tags" --exclude="ChangeLog" ./* -R

you will see that addMove() isn't used anywhere except for
the file ./examples/test/force-move.py

--
Janek Kozicki http://janek.kozicki.pl/ |

[Bruno Chareyre (bruno-chareyre)]

It seems to me that:
1/ a robust (velocity-consistent) implementation would need much more than a simple bugfix
2/ assigning velocity is the right way to control motion according to the documentation [1]
Therefore, I would suggest to simply remove addMove from sources.

Do you guys have a realistic example of something that can't be achieved without addMove?
As mentionned in #2, assigning velocity means that the displacement per iteration depends on the timestep but isn't it what we want? I mean, imposing a constant displacement of a body per timestep implies that the velocity of the said body is changing all the time (with a changing dt). A physical quantity depending on a numerical detail is an odd feature.

Further, if someone really wants to addMove() and doesn't care about velocity consictency, it could be simply:
b.state.pos += move #in a pyRunner, typically

[1] https://yade-dem.org/doc/user.html#imposed-velocity

@Janek
>you will see that addMove() isn't used anywhere except for the file ./examples/test/force-move.py

This grep output is typical for such function (supposed to be used through python wrapper mainly), i.e. implementation in the source code + one example script. It doesn't tell really if the function is used or not (by yade users), and if it is used it can still have nasty side effects.

@Vaclav
>I would have to remember hard what was the reason to introduce it

Maybe an intermediate state of the tensile tests, where groups of particles had to be moved as rigid blocks - now done with constant velocity but maybe with constant disp/iter previously?

Bruno

[Václav Šmilauer (eudoxos)]

> Maybe an intermediate state of the tensile tests, where groups of particles had to be moved as rigid blocks - now done with constant velocity but maybe with constant disp/iter previously?

Yes, that must have been it! It was for sure at the time where blocked DOFs would make the particle simply fixed in space, even if it had any velocity.

v.

[Janek Kozicki (cosurgi)]

moved from Jan Stránský on 2014-12-07 to https://gitlab.com/yade-dev/trunk/issues/23