yade-dev team mailing list archive

[Václav S(milauer <eudoxos@xxxxxxxx>]

> * TODO: add torsion code, that will (if a flag is on) compute torsion
> angle on the contact axis.
> *
> * TODO: add bending code, that will compute bending angle of the
> contact axis
>
> The code for this is in CohesiveFrictionalContactLaw already, its been
> developped by Cosurgi.
Hi, it is probably question directed at me. Torsion, bending, but also
shear code is implemented as incremental computation from angular
velocities etc. 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).

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.

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, 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.)

What makes you think that contact of 2 spheres is describable just by
penetrationDepth and radii? 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 "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.

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) 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.

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).

Hope that I was clear and that there will be some discussion about this.

Vaclav