(Not) Defining velocities in UniaxialStrainer ?

[Jérôme Duriez]

Hi,

I have the feeling that there is something "wrong" with UniaxialStrainer where the velocities of the "posIds" and "negIds" bodies are not defined, and I illustrate it with following examples (attached)

It deals with 2 contacting spheres, with an oblic contact. One sphere is moved towards the 2d sphere, and here both normal and tangential relative displacements occur.
- In testUS.py the moving sphere is moved through UniaxialStrainer
- Whereas in testUSb.py the movement comes from an initial value of velocity (and NewtonIntegrator)

And, obviously, the two simulations are different (see e.g. the plot of fZ sustained by moving sphere). While I would tend to consider these two simulations as identical.

What do you think ?

[Jérôme Duriez (jduriez)]

The 2d attachment

[Bruno Chareyre (bruno-chareyre)]

I don't know UniaxialStrainer, but I don't think the two scripts should give identical results anyway.
A "strainer" should never make bodies cross each other, this is against continuum mechanics (make a compression between two plates, should the top plate cross the bottom plate? If it occures where is the material??).

The real problem I see is that UniaxialStrainer is modifying positions. It should be stricly forbiden in Yade: contact laws are based on velocities, thus playing with positions without a relevant velocity is a way to break most algorithms.
It seems UniaxialStrainer should be simply removed (or someone will fix?).

[Jérôme Duriez (jduriez)]

> The real problem I see is that UniaxialStrainer is modifying positions.
So, we agree on most important part.

> It seems UniaxialStrainer should be simply removed (or someone will fix?).
I do not have precise ideas on what should be a "strainer" and, if it
can be used in discrete mechanics, but maybe other people have, and
anyway I have the feeling that this engine is used (at least by 2
people). So, after other points of view, I could fix it, even if I will
maybe not use it.

It is probably only a matter of setting the velocity corresponding to
the change in position.

--
Jérôme Duriez
Post-Doctorant UJF
Laboratoire 3SR
Bureau E139 - 04.56.52.86.30

[Bruno Chareyre (bruno-chareyre)]

>I could fix it
This engine has been introduced before effective integration of python.
Is it doing something that can't be done with python?

Your case with this bug was typical. You could:
1/ type a few python lines to do exactly what you want, or
2/ learn how to use an engine, try it, realize that it is not doing what you think it would do, find a bug, report, get feedback, start fixing
Coming soon: commit, push, get feedback again, etc.

If this engine is removed you will:
1/ type a few python lines to do exactly what you want
Less compilation time for us all, less maintainance, less noise on the mailing list.

[Jan Stránský (honzik)]

Hi Bruno,

> This engine has been introduced before effective integration of python.
> Is it doing something that can't be done with python?
>

despite this fact, you can just use one line in your python script in
O.engines instead of defining your own function and call it in PyRuuner..
It is true that (according to this thread), it is not maintained for some
time (e.g. directly prescribing displacements), but the functionality is in
general useful..

>
> Your case with this bug was typical. You could:
> 1/ type a few python lines to do exactly what you want, or
> 2/ learn how to use an engine, try it, realize that it is not doing what
> you think it would do, find a bug, report, get feedback, start fixing
> Coming soon: commit, push, get feedback again, etc.
>
> If this engine is removed you will:
> 1/ type a few python lines to do exactly what you want
> Less compilation time for us all, less maintainance, less noise on the
> mailing list.
>

correct, but as more than one person may use it (me for example :-), it
does not matter if it is written in c++ or rewritten to python (somebody
would maintain it, test it, ask questions on mailing lists...)

cheers
Jan

[Jérôme Duriez (jduriez)]

Hi,

I committed finally some change [1], that I began before your assignment, Jan. For the examples script above, the results seem indeed now identical (provided that NewtonIntegrator is put after UniaxialStrainer in the list of engines of testUS.py).

Feel free to test/change it more, Jan. (for me I guess I will not use much more this engine)

Jérôme

[1] : https://github.com/yade/trunk/commit/50727a206bda1ff0129b391ef16daa5cc659ef3c