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