yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>]

Václav Šmilauer a écrit :
> > for now we have 
> > unexplained results even with the simpler 3DOF.
> >     
> ??
>   
I honestly did my best to get results out of 3DOF framework with the 
contact laws I'm using, but for now it has been a failure. I'm suprised 
you did not realize.

Rapid history :
For rigid boundary conditions, there is the long standing bug 
(https://bugs.launchpad.net/yade/+bug/399963), so that the only 
combination giving results at that point is 
boxes+ScGeom+Law2_ScGeom_SomeScGeomFunctor. We don't really know if it 
is due to facets or Dem3Dof. OTOH, periodic boundary conditions were 
offering a good situation to test Dem3Dof since potential problems could 
not come from facets. I tried that.

First I got to solve the bug 
https://lists.launchpad.net/yade-users/msg02639.html in 
Law2_Dem3DofGeom_FrictPhys_Basic, suggesting that I was the first one to 
test that code.
Then, I got to fix another bad bug in Dem3DofGeom_SphereSphere itself 
(https://lists.launchpad.net/yade-dev/msg04338.html).
Next, I realized that Dem3Dof was computing 4 sqrts and 4 divisions 
where ScGeom needs 1 of each, I commited a fix, but unfortunately it 
broke (or exhibited a problem in?) sphere-facets interactions. I 
reverted the fix and resigned myself to the 4 sqrt, using well designed 
code was at that price.
I was expecting correct results after all that, but then I hit another 
bug (https://bugs.launchpad.net/yade/+bug/585771) which I still can't 
explain.

I finally swithed back to ScGeom, the only option left. After a few 
adjustments in the periodic code (e.g. homotheticResize and relative 
velocity shift in functors, which was needed anyway) it works perfectly. 
Results are stable and match the results obtained with "box" boundaries 
in Yade or PFC. That is why I would focus on 3Dof first if the point is 
to reproduce ScGeom algorithms in DemXDof context.
> > Putting curent code for moment law in the 6DOF framework
> >     
> Dem6Dof is there in the source, but it is broken (badly).
>
>   
Exactly. And even if it was not badly broken, it would inherit the bugs 
from 3DOF (I acknowledge this 6DOF code though, since it gives the main 
structure where moment-law can be (hopefully) imputed one day). OTOH, 
FrictPhys/CohFrictPhys is in the source and is validated.

So, we have in Yade currently a DemXDof framework with shiny design 
which fails for the simplest 40-years old elastic-frictional law (I'm 
not implying anything on other laws I didn't test), and a functional and 
validated ScGeom/Frict/CohFrict implementing the classical DEM 
algorithms for 6DOFs interactions with forces and moments.
Splendor and misery?

Another note : I just realized that I probably failed to reply to some 
questions in the past, concerning the local coordinate system of 
contacts. If a local coordinate system is needed, it is handled 
gracefully in SCGeom, which IS tracking the orientation of the local 
coordinate system, independant of any incremental/total formulation. I 
understood this fact had been overlooked while reading this sentence in 
the doc "A special (mis)feature of DEM is that each contact is oriented 
only by two points, current positions of both particles (\currC_1 and 
\currC_2)". First, it is by no mean a "DEM misfeature" (see PFC3D 
manual), second is not even a Yade misfeature.
I can fix that in the doc (together with the paragraph on 
GlobalStiffnessTimeStepper I already mentioned) if you confirm this part 
of doc is commitable already.

Bruno


--
_______________
Bruno Chareyre
Associate Professor
Grenoble INP
Lab. 3SR
BP 53 - 38041, Grenoble cedex 9 - France
Tél : 33 4 56 52 86 21
Fax : 33 4 76 82 70 43
________________