yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>]

> Hi, it is probably question directed at me. Torsion, bending, but also
> shear code is implemented as incremental computation from angular
> velocities etc.
Only shear motion is defined in an incremental form. Torsion/bending is 
relative to the initial positions.

>  I don't use torsion and bending, but for the shear part,
> I never got the incremental algo to match with what small-strain FEM
> code computes for strains (production code, therefore assumed to be
> correct).
>   
It is not the first time I read this but I must admit I never understodd 
what it means. What did you compare exactly?

> Besides that, implementing geometry algorithms inside constitutive laws
> is conceptually flawed, for 2 reasons.
>
> 1. Constitutive law should operate just on interaction geometry and
> interaction physics. If it accesses rootBody->bodies, it is a design
> problem.
>   
Agreed : we have a design problem. But I see no obvious solution for now 
(see below).

> 2. Strains are the same accross multiple constituive laws, since it
> really is a geometrical property. It makes no sense to cut&paste code
> all the time; the code for shear strain is repeated at least 5x
> throughout different classes, even with the same comments, and maybe
> same bugs. (Otherwise if I needed torsion in different constitutive law,
> I would have to copy&paste code from CohesiveFrictionalContactLaw??)
>
>   
Well... my main point was to save your brain-time providing 
Janek-brained equations.
On the c++ part, one solution would be to inherit from 
CohesiveFrictionalContactLaw in some way, or develop the law itself to 
make it do what you need. This law is the most general in Yade 
currently, you can go from the simplest normal-elastic interaction to a 
complex force-moment creep law by playing with the parameters. I'm sure 
it is no big deal to add you own constitutive behaviour in this class. 
Of course, it would be no big deal probably to do the opposite : move 
the CohesiveFrictional stuff to your framework...

> (well, let me add 3. Constitutive law should just map strains to
> stresses. It is not constitutive law's business to compute strains. You
> can have a look at ef2_Spheres_NormalShear_ElasticFrictionalLaw, this is
> what I think constitutive law should look like: get strains, compute
> stresses, apply forces. Finito.)
>   
It makes sense, but it means each constitutive law will need its own 
specific geometry engine+dataClass class to compute/store the relevant 
"strain", doesn't it?
Janek, needs an initial relative orientation, Wenji needed maxUn, JF 
needs the volume of the cell from triangulation (stored at bodies level) 
before he can even define the stiffness, the first Yade developers 
thought everybody would need a contact point defined while most of us 
never used it, etc. And I'm sure the next person developping a 
constitutive law will need another geometrical information that nobody 
is expecting for now. Is it compatible with the design you plan?

Also, when you say "constitutive law should look like: get strains, 
compute stresses, apply forces"(*), I'd say it is perhaps a bit more 
complex.
Take this equation : Fn = Kn (Un-Un_plastic), obviously an 
elasto-plastic framework.
What is Un_plastic? Is it an internal parameter of the law or an 
external geometrical information? It is in fact something in between, 
since (1) it  is obviously a kinematic-like variable, but (2) at the 
same time it can't be defined from the current geometry. Un_plastic 
describes an history of the motion _with respect to_ one constitutive 
law. Even with the full record of all previous movements, you can't 
define Un_plastic if you don't know the constitutive law itself.
Should Un_plastic be in contactPhysics or contactGeometry?
Do we really need a rule?

An exemple of this : in creep equations (creep, like plasticity, is 
changing the "neutral" position when it occures), the initial 
orientations (from wich total bending/twisting are defined) are updated 
to reflect creep. The way it is updated is valid only for the specific 
creep law considered here, another constitutive law would update the 
initial configuration differently.

The conclusion is you can't avoid the manipulation/storage of 
geometrical data in some constitutive laws/physicalParameters.

(*) Quick note : I feel strange each time you speak about strain and 
stress in constitutive law, since the specificity of DEM is to consider 
disp./forces instead of strain/stress, usually...

> What makes you think that contact of 2 spheres is describable just by
> penetrationDepth and radii?
Answer 1 : Cundall (1988) ;-)
Answer 2 : because I need nothing else.
>  That would be _normal_ contact. For shear,
> bending and torsion, it gets more complicated, and that's what all the
> cp1rel, cp2rel (and unrollSpherePtToPlane, for that matter, which
> computes the shear from the data) are for.
>   
The incremental definition of the shear force allows to skip the 
definition and storage of cp1rel/cp2rel/unroll. It works very well and 
it has been used by hundreds of researchers since 1988 (so again, I'd 
like to know how you compared with E.F.).

> The "abusive storage" members were not added by me, except
> facetContactFace (abusive, because only used for sphere-facet contact).
> What I agree with is that hasNormalViscosity, NormalViscosity and
> NormalRelativeViscosity are clearly physical quantitites that should be
> in interaction physics.
>
>   
So will you move them away at one point?
> About my future plans: define abstract classes Dem3DofContactGeometry
> (better name?; for classes normal and shear) and Dem6DofContactGeometry
> (for classes with normal, shear, bending and torsion strains)
So, first of all, I would define "DemXDofContactGeometry" with normal, 
Un, and incremental dUt (this code duplicated in different constitutive 
laws), nothing more. This is "normal" DEM, no reason to overload with 
more parameters.
That is what I am a bit annoyed with the ammount of extra stuff that is 
in SpheresContactGeometry right now.
>  with
> virtual methods to get e.g. epsN(), epsT(), regardless of whether it is
> Sphere-Facet of Sphere-Sphere contact. Mapping sphere-facet to
> SpheresContactGeometry has not much physical meaning and will not work
> for more complex things like transferring plastic strain when going over
> facet boundary to its neighbor.
>   
I think I get the idea. I admit I have no clear vision on all this for 
now, I'm just raising a few points.

The possible problem is that people could need to modify the abstract 
classes all the time because they need a geometrical information you 
disregarded
One simple exemple comes to mind : center of mass of bodies. For spheres 
and simple elastic-frictional contacts, you can compute the moment 
generated by fs as M += radius.n x fs, but for non-sperical bodies 
(snow) you cannot do this. You need to compute M+=(ContPoint - 
CenterMass) x fs.
In that case, with your approach, IntGeom would need to store not only 
rad1,rad2 but also the centers of mass of both particles.

So, fundamentally, with you first statement in mind : "Constitutive law 
should operate just on interaction geometry and interaction physics. If 
it accesses rootBody->bodies, it is a design problem", all information 
from bodies must be duplicated in interactionGeometry, which is a 
serious design problem too...

> Then SpheresContactGeometry inherits from Dem3DofContactGeometry, I will
> create (maybe) also SphereFacetContactGeometry etc, but the constitutive
> law will operate on Dem3DofContactGeometry and will not care, whether
> the underlying contact is sphere-sphere, sphere-facet (or sphere-box,
> whatever).
>
>   
Agreed. The fact that SpheresContactGeometry can be used for others 
(body1,body2) is just a temporary trick.

Bruno

--

_______________
Chareyre Bruno
Maitre de conference

Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : 33 4 56 52 86 21
Fax : 33 4 76 82 70 43
________________