Hi,
based on discussion with Vincent and also (older) proposal of
Janek, and
for other reasons of simplicity, I would like to create new Material
class that would hold material properties of bodies. There would be
only
a few instances of it typically:
MetaBody::vector<Material> (plus some convenience function to get
index
based on name, for convenience in the generators -- like "steel",
"mortar", "stone1" etc.)
int Body::materialId would have the number
Body::physicalParameters would be renamed to Body::state (and
PhysicalParameters to State), holding non-const things, basically only
Se3.
Tentative proposition::
Material (Real density)
+-- ElasticMaterial (Real young, Real poisson)
+-- FrictionalMaterial (Real frictionAngle)
BodyState (same as PhysicalParameters now)
+-- ParticleState (=ParticleParameters)
+-- RigidBodyState (=RigidBodyParameters)
ElasticBodyParameters and BodyMacroParameters add only material
properties to RigidBodyParameters and would have no equivalents in
BodyStates. Other classes deriving from RigidBodyParameters are adding
internal state constants/variables, which is exactly what they should
do. (see
http://beta.arcig.cz/~eudoxos/yade/doxygen/d2/d7b/
classPhysicalParameters.html)
InteractionPhysicsMetaEngine would dispatch based on 2x body-
>state, and
it would be the user's responsibility that the type of body's material
is of the type expected by the functor (it could be checked, since
that
would be used only when the contact is created).
===
Note for Vincent: interactions will still have all their properties
inside them (like stiffness, frictionAngle etc computed from
materials).
There is probably not much to do about it -- except for deriving those
constant parameters that depend only on material beforehand and can be
shared between interactions, for all possible (/requested)
combinations
of materials, perhaps using something like GroupRelationData. In that
case InteractionPhysics (interactionState??) would hold something like
interactionParametersId, with container of a few shared "cross-
section"
characteristics (rigidity, frictionAngle etc).
This way, we would get something similar to typical FEM: material
class
(http://www.oofem.org/resources/doc/oofemlibrefman/
classMaterial.html),
cross-section (i.e. shared interaction properties, for different
combinations of materials perhaps) class
(http://www.oofem.org/resources/doc/oofemlibrefman/
classCrossSection.html). InteractionPhysics would correspond to per-
interaction state (http://www.oofem.org/resources/doc/
oofemlibrefman/classMaterialStatus.html). Addionally, we would have
the BodyState, which is on a body, not on interaction (which
corresponds to a FEM element -- at least for cohesive materials).
(end of note for Vincent. I propose to have shared Material and per-
body
State first, then perhaps extend it to shared interaction data as
well.)
Opinions?
_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
