sphere-facet geometries are bugy (ScGeom/Dem3Dof)

[Sergei Dorofeenko]

When I run examples/rotatingCylinder.py with bzr2255 (default profile) I got a crash after several iterations. Seems it related with velocityBins mechanism:

 Yade [1]: INFO yade.VelocityBins /home/sega/work/yade/trunk/pkg/common/DataClass/VelocityBins.cpp:33 setBins: New number of bins: 5
FATAL yade.VelocityBins /home/sega/work/yade/trunk/pkg/common/DataClass/VelocityBins.cpp:77 setBins: Body #4483, velSq=nan not put in any bin!?
Crash!

[Anton Gladky (gladky-anton)]

I confirm that.

[Václav Šmilauer (eudoxos)]

It used to work IIRC; NaN velocity is (usually) only indicative of some other problem: zero mass, problem in the integrator and such.

[Anton Gladky (gladky-anton)]

WM3-compilation has no this problem

[Václav Šmilauer (eudoxos)]

Although I can't check for time reasons now, I strongly suspect this line (pkg/common/Engine/PartialEngine/RotationEngine.cpp:62):

state->vel=state->angVel.cross(l);

As you recall, Eigen doesn't handle cross product with zero vectro specially; if angVel is zero (at the beginning), state->vel will be NaN.

[Anton Gladky (gladky-anton)]

I have just checked. There are now NANs in string 62 before crash.

2010/5/27 Václav Šmilauer <email address hidden>

> Although I can't check for time reasons now, I strongly suspect this
> line (pkg/common/Engine/PartialEngine/RotationEngine.cpp:62):
>
> state->vel=state->angVel.cross(l);
>
> As you recall, Eigen doesn't handle cross product with zero vectro
> specially; if angVel is zero (at the beginning), state->vel will be NaN.
>
> --
> bzr2255 crash on examples/rotatingCylinder.py
> https://bugs.launchpad.net/bugs/585898
> You received this bug notification because you are subscribed to Yade.
>
> Status in Yet Another Dynamic Engine: New
>
> Bug description:
> When I run examples/rotatingCylinder.py with bzr2255 (default profile) I
> got a crash after several iterations. Seems it related with velocityBins
> mechanism:
>
> Yade [1]: INFO yade.VelocityBins
> /home/sega/work/yade/trunk/pkg/common/DataClass/VelocityBins.cpp:33 setBins:
> New number of bins: 5
> FATAL yade.VelocityBins
> /home/sega/work/yade/trunk/pkg/common/DataClass/VelocityBins.cpp:77 setBins:
> Body #4483, velSq=nan not put in any bin!?
> Crash!
>
>
>

[Anton Gladky (gladky-anton)]

Vaclav, how do you usually "catch" the "crash-string"?

I insert std::cout's and see what they output. Maybe there are better way?

Thanks.

[Václav Šmilauer (eudoxos)]

Cout is buffered and might not be flushed when the crash happens. Use cerr, which is not buffered, hence displayed immediately.

[Anton Gladky (gladky-anton)]

Thanks, Vaclav.

I have just defined, that the crash appears on r2237 and later.
http://bazaar.launchpad.net/~yade-dev/yade/trunk/revision/2237

*Bruno*, please, have a look, it is a really serious!
http://bazaar.launchpad.net/~yade-dev/yade/trunk/annotate/head:/pkg/dem/Engine/GlobalEngine/ElasticContactLaw.cpp#L119
I think the problem is somewhere here. For some reasons, the force becomes
Vector3(nan,nan,nan), then acceleration, velocity and.... Kaput.

So, it is not, probably, an Eigen problem.

Vaclav, you are right, we should seriously think about regression tests. It
will prevent a lot of mistakes.

_____________________________

Anton Gladkyy

2010/5/27 Václav Šmilauer <email address hidden>

> Cout is buffered and might not be flushed when the crash happens. Use
> cerr, which is not buffered, hence displayed immediately.
>
> --
> bzr2255 crash on examples/rotatingCylinder.py
> https://bugs.launchpad.net/bugs/585898
> You received this bug notification because you are subscribed to Yade.
>
> Status in Yet Another Dynamic Engine: Confirmed
>
> Bug description:
> When I run examples/rotatingCylinder.py with bzr2255 (default profile) I
> got a crash after several iterations. Seems it related with velocityBins
> mechanism:
>
> Yade [1]: INFO yade.VelocityBins
> /home/sega/work/yade/trunk/pkg/common/DataClass/VelocityBins.cpp:33 setBins:
> New number of bins: 5
> FATAL yade.VelocityBins
> /home/sega/work/yade/trunk/pkg/common/DataClass/VelocityBins.cpp:77 setBins:
> Body #4483, velSq=nan not put in any bin!?
> Crash!
>
>
>

[Anton Gladky (gladky-anton)]

Ok, the problem is here:

http://bazaar.launchpad.net/~yade-dev/yade/trunk/annotate/head:/pkg/dem/Engine/GlobalEngine/ElasticContactLaw.cpp#L130

I have commented the string for the moment to escape a crash.

Bruno, please, check, what is wrong in your code. You understand it better, than me. Thank you.

[Bruno Chareyre (bruno-chareyre)]

It should be workarounded in r2259. Can you confirm?
No time for more investigations now.
I didn't get any problems with this code, even after 200k iterations in
periodic tests, and I can't find a way to run the crashing example, see
below. So, I cannot "see" the bug.

Bruno

1st try :

File "examples/rotatingCylinder.py", line 32
 SyntaxError: Non-ASCII character '\xc2' in file
examples/rotatingCylinder.py on line 32, but no encoding declared; see
http://www.python.org/peps/pep-0263.html for details
(rotatingCylinder.py, line 32)

--> Fixed

2nd try :

SyntaxError: Non-ASCII character '\xe2' in file
examples/rotatingCylinder.py on line 36, but no encoding declared; see
http://www.python.org/peps/pep-0263.html for details
(rotatingCylinder.py, line 36)

--> Fixed

3rd try :

 File "examples/rotatingCylinder.py", line 31, in <module>
    cyl=unitCylinder(); sq=unitSquare(); sq.translate(0,0,-1); cyl.copy(sq)
  File "examples/rotatingCylinder.py", line 28, in unitCylinder
    return pack.sweptPolylines2gtsSurface([ptsBase,ptsTop])
  File "/home/bruno/YADE/lib/yade-true-true/py/yade/pack.py", line 125,
in sweptPolylines2gtsSurface
    vtxs=[[gts.Vertex(x,y,z) for x,y,z in pts1] for pts1 in pts]
NameError: global name 'gts' is not defined

--> Huh?!

[Anton Gladky (gladky-anton)]

Hi, Bruno

1) please, install libgts-dev
2) add 'gts' to features
3) check with r2260

Thanks
______________________________

Anton Gladkyy

2010/5/28 Chareyre <email address hidden>

> It should be workarounded in r2259. Can you confirm?
> No time for more investigations now.
> I didn't get any problems with this code, even after 200k iterations in
> periodic tests, and I can't find a way to run the crashing example, see
> below. So, I cannot "see" the bug.
>
> Bruno
>
> 1st try :
>
> File "examples/rotatingCylinder.py", line 32
> SyntaxError: Non-ASCII character '\xc2' in file
> examples/rotatingCylinder.py on line 32, but no encoding declared; see
> http://www.python.org/peps/pep-0263.html for details
> (rotatingCylinder.py, line 32)
>
> --> Fixed
>
> 2nd try :
>
> SyntaxError: Non-ASCII character '\xe2' in file
> examples/rotatingCylinder.py on line 36, but no encoding declared; see
> http://www.python.org/peps/pep-0263.html for details
> (rotatingCylinder.py, line 36)
>
> --> Fixed
>
> 3rd try :
>
> File "examples/rotatingCylinder.py", line 31, in <module>
> cyl=unitCylinder(); sq=unitSquare(); sq.translate(0,0,-1); cyl.copy(sq)
> File "examples/rotatingCylinder.py", line 28, in unitCylinder
> return pack.sweptPolylines2gtsSurface([ptsBase,ptsTop])
> File "/home/bruno/YADE/lib/yade-true-true/py/yade/pack.py", line 125,
> in sweptPolylines2gtsSurface
> vtxs=[[gts.Vertex(x,y,z) for x,y,z in pts1] for pts1 in pts]
> NameError: global name 'gts' is not defined
>
> --> Huh?!
>
> --
> bzr2255 crash on examples/rotatingCylinder.py
> https://bugs.launchpad.net/bugs/585898
> You received this bug notification because you are subscribed to Yade.
>
> Status in Yet Another Dynamic Engine: Confirmed
>
> Bug description:
> When I run examples/rotatingCylinder.py with bzr2255 (default profile) I
> got a crash after several iterations. Seems it related with velocityBins
> mechanism:
>
> Yade [1]: INFO yade.VelocityBins
> /home/sega/work/yade/trunk/pkg/common/DataClass/VelocityBins.cpp:33 setBins:
> New number of bins: 5
> FATAL yade.VelocityBins
> /home/sega/work/yade/trunk/pkg/common/DataClass/VelocityBins.cpp:77 setBins:
> Body #4483, velSq=nan not put in any bin!?
> Crash!
>
>
>

[Anton Gladky (gladky-anton)]

2010/5/28 Chareyre <email address hidden>

> .....

I didn't get any problems with this code, even after 200k iterations in
> periodic tests.....
>

Maybe, you tested that on quasy-static tasks and did not get a special
condition, when it crashes.
Rotatecylinder is a really dynamic one, that is why it appears.

I think, the problem is somewhere in "division by 0", or cross-product of
null-vector.
Please, have a look at your code.

Thanks

[Bruno Chareyre (bruno-chareyre)]

Can you confirm that last commit fixes the bug? I have really no time to
recompile and check.
There is no cross product in my code, and I see no division by zero,
except if 0>0 or NaN>0. In the second case it would mean NaN is
generated outside the function.

[Anton Gladky (gladky-anton)]

Yes, it seems, it is working without crashes now.
Will test later again.

Thank you.
______________________________

Anton Gladkyy

2010/5/28 Chareyre <email address hidden>

> Can you confirm that last commit fixes the bug? I have really no time to
> recompile and check.
> There is no cross product in my code, and I see no division by zero,
> except if 0>0 or NaN>0. In the second case it would mean NaN is
> generated outside the function.
>
> --
> bzr2255 crash on examples/rotatingCylinder.py
> https://bugs.launchpad.net/bugs/585898
> You received this bug notification because you are subscribed to Yade.
>
> Status in Yet Another Dynamic Engine: Confirmed
>
> Bug description:
> When I run examples/rotatingCylinder.py with bzr2255 (default profile) I
> got a crash after several iterations. Seems it related with velocityBins
> mechanism:
>
> Yade [1]: INFO yade.VelocityBins
> /home/sega/work/yade/trunk/pkg/common/DataClass/VelocityBins.cpp:33 setBins:
> New number of bins: 5
> FATAL yade.VelocityBins
> /home/sega/work/yade/trunk/pkg/common/DataClass/VelocityBins.cpp:77 setBins:
> Body #4483, velSq=nan not put in any bin!?
> Crash!
>
>
>

[Václav Šmilauer (eudoxos)]

Worked around by not using scaleDisplacementT as suggested by Anton.

[Anton Gladky (gladky-anton)]

I wanted to stay the bug opened, while scaleDisplacementT function is not
fixed.

If not, the function should be commented or even .... deleted.
Sorry, but it is hardly reproducible bug, and nobody knows who and when will
meet this problem.
If we simply close the bug, we will forget about that.

Anton.

2010/6/2 Václav Šmilauer <email address hidden>

> Worked around by not using scaleDisplacementT as suggested by Anton.
>
> ** Changed in: yade
> Status: Confirmed => Fix Released
>
> --
> bzr2255 crash on examples/rotatingCylinder.py
> https://bugs.launchpad.net/bugs/585898
> You received this bug notification because you are subscribed to Yade.
>
> Status in Yet Another Dynamic Engine: Fix Released
>
> Bug description:
> When I run examples/rotatingCylinder.py with bzr2255 (default profile) I
> got a crash after several iterations. Seems it related with velocityBins
> mechanism:
>
> Yade [1]: INFO yade.VelocityBins
> /home/sega/work/yade/trunk/pkg/common/DataClass/VelocityBins.cpp:33 setBins:
> New number of bins: 5
> FATAL yade.VelocityBins
> /home/sega/work/yade/trunk/pkg/common/DataClass/VelocityBins.cpp:77 setBins:
> Body #4483, velSq=nan not put in any bin!?
> Crash!
>
>
>

[Václav Šmilauer (eudoxos)]

You're right, Anton, but it should not be a blocker for 0.5.

[Bruno Chareyre (bruno-chareyre)]

I'd be interested to know what values were passed to scaleDisplacementT before the crash (in case you still have cerr's everywhere).
Ok to keep the bug open. I'm using scaleDisp without problems here, and I'll have to find out how it crashes in cylinder test.
It is not used in trunk starting from r2259, so it is currently harmless.

[Anton Gladky (gladky-anton)]

2010/6/2 Chareyre <email address hidden>

> I'd be interested to know what values were passed to scaleDisplacementT
> before the crash (in case you still have cerr's everywhere).
>

Not an easy to say now. Needs to be checked.
I guess, it is something about tangential motion with almost 0 normal one.

[Václav Šmilauer (eudoxos)]

@Bruno: It can be specific to Facet-Sphere contact, therefore you have no issue.

[Bruno Chareyre (bruno-chareyre)]

@Vaclav: Yes, this is probably where I'll look first.

[Václav Šmilauer (eudoxos)]

Removing scaleDisplacementT as it is not being used anywhere.

[Bruno Chareyre (bruno-chareyre)]

I renamed the bug.
Closing is dangerous because scaleDisp only revealed an existing problem somewhere (it is similar to crashing for NaN vels in Newton when there is a problem in constitutive law).
I propose to keep it open as long as we can't make sphere-facet interactions work properly.

[Václav Šmilauer (eudoxos)]

I closed the bug before I commited the respective code (which I did now). I don't see a point to keep it open (the code was not used anyways), unless you want to maintain Dem3DofGeom &co (for me, it is phased out by L3Geom).

[Bruno Chareyre (bruno-chareyre)]

Ok. Does it means we stop reporting Dem3Dof bugs because it will not be maintained at all (I won't)?
Note : the function is used, virtualy, but the code using it has been commented out to workaround this bug (in ElasticContactLaw.cpp).

[Václav Šmilauer (eudoxos)]

The function in Law2_Dem3DofGeom_FrictPhys_CundallStrack (or what is it called) was commented out because of this bug, and I think it is not clear if it was a problem in that function or elsewhere in Dem3DofGeom.

I agree that there is no reason to report bugs agains Dem3DofGeom anymore, as there would be no-one to fix them.