yade-dev team mailing list archive
-
yade-dev team
-
Mailing list archive
-
Message #05359
Dem3DOFGeom : ScGeom
Hi Vaclav,
After some thinking, I tried what you'll find in r2365. What do you think?
It makes Dem3Dof inherit from ScGeom. Some of the reasons for doing it
that way are (correct me if I'm wrong) :
- GenericSphereContact has been created for the purposes of using
GlobalStiffnessTimeStepper (ScGeom based) with Dem3Dof, a typical
situation where inheritance could have been used.
- Dem3DofGeom need specialized classes derived for each new type of body
pair (Dem3DofGeom_SphereSphere, Dem3DofGeom_WallSphere,... those classes
contains mostly duplicated code btw), while ScGeom apply for any body
type as long as the interaction as a normal and contact point (thanks to
the rad1/rad2 values inside the Ig, so that we don't even need to have
radii in bodies). We could in fact rename "ScGeom" ->
"GenericContactGeom"...
- There is more data in Dem3Dof than in ScGeom. I found a way to get rid
of previousNormal, so now ScGeom has only rad1,rad2,contactPoint, normal.
- Inheritance is way easier and safer to implement : I don't have to
update the existing Ig2 functors (5), law functors (6), preprocessors
(3), and python scripts (how many would have to be updated? no clue).
Impact on Dem3Dof : private precomputable twist_axis, orthonormal_axis,
and shearInc (Vector3's) are added and perhaps not needed. This drawback
would persist whatever the "merging" method however. No CPU penalty
since precomputation is done only on demand by Ig2 functors.
Thanks for comments.
Bruno
p.s. I'm not asking comments on documentation, variable names, sign
convention or compilation warnings yet. It's clearly not all sorted.
Follow ups