O.forces.addMove does not work

Bug #1400075 reported by Jan Stránský
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Yade
New
Undecided
Unassigned

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

Revision history for this message
Bruno Chareyre (bruno-chareyre) wrote :

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.

Revision history for this message
Václav Šmilauer (eudoxos) wrote :

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?

Revision history for this message
Jan Stránský (honzik) wrote : Re: [Bug 1400075] Re: O.forces.addMove does not work

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
>

Revision history for this message
Bruno Chareyre (bruno-chareyre) wrote :

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

Revision history for this message
Janek Kozicki (cosurgi) wrote : Re: [Yade-dev] [Bug 1400075] Re: O.forces.addMove does not work

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

Revision history for this message
Bruno Chareyre (bruno-chareyre) wrote :

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

Revision history for this message
Václav Šmilauer (eudoxos) wrote :

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

Revision history for this message
Janek Kozicki (cosurgi) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers