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
________________
_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
