Actually just today we were discussing there the equilibrium distance
concept. My conclusion is that it should be added to ScGeom so that it
works for those "continuum-like" materials.
Better derive a class for continuum like materials (see below). It is
not very good to add more data when most code will not use it.
In fact, it was the biggest
obstacle when I tried (never finished) to adapt the Cpm model to ScGeom.
The option was to store the initial distance in CpmPhys (which is
actually, looking at your code, what you do actually with
CFpmPhys::initD), but I did not go along that path as it would be only a
hack.
Is it really a hack? Equilibrium distance can be seen as a physical
variable of the contact. It can change to reflect damage, etc. This is
perhaps the best option : no added data in ScGeom, no new Ig class.
What about the other 2 laws? Chia Weng's law is cohesionless and follows
faithfully Jean-Patrick's paper, that is what I gathered. Janek's law
(Law2_ScGeom_CohFrictPhys_ElasticPlastic) differs in that is has
additionally twist and tension? Is there a paper that describes it?
This is how I see things : usually, when people say "it follows
Plassiard", they mean variables have the same names and all assumptions
and conventions in parameter definitions, micro-macro passage, and such
are the same. It is not really the good question for sorting contact
laws. Defining kn=E.D (for instance) is just a question of modelling,
not computing, and as such, it is out of the scope of law functors.
Different users will always do that differently, and it should be
handled in Ip functors. OTOH, computing relative torsion/bending between
two bodies will always be done with the same algorithm. Same for
returning moment=k*rotation, regardless how k is defined.
So, most of diffs between the 3 law functors could/should actually be
confiined to Ip data and functors.
[The best would be to provide a few functions (to ScGeom or some more
complex class) that would handle bending and twisting, similarly to how
ScGeom::rotate() handles shear displacement. Then respective models
would make use of them to get their work done in a few lines.]
Not in ScGeom : relative rotation needs initial orientations of each
bodies stored in the interaction -> we want no more data in ScGeom.
The plan is to add data in the future 6DofScGeom and move the moment
code in there. Currently, this data is in interaction physics.
About documentation, don't be too pessimistic. The algorithm for
rotations is easy to understand (provided you exclude all aspects
regarding Poisson, Young, and other modelling tricks, as suggested above).
Bruno
_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp
