yade-dev team mailing list archive
-
yade-dev team
-
Mailing list archive
-
Message #03280
Re: RockJointLawRelationships
> > I suggest to rename CohesiveFricitonalMat to CohFrictMat, in any case.
> Btw, I suggested to name contact parameters FrictCont or FrictInt some
> time ago, but there were no reactions.
I didn't spot that. It might be a problem that Int and Cont (interaction
and contact) are already used in the DEM domain*. In yade the whole
interaction is interaction (which comprises phys & geom). But I am open
to this, "Phys" is no better, for sure.
*) some people make (meaningful) terminological distiction of 2 kinds of
interactions, which can be either "contact" (non-cohesive, generated by
motion) or "link" (pre-established and cohesive).
> I think "Frict" (or something else ofc) is the physics, so frictPhys is
> redundant and makes no clear difference between bodies physics and
> interaction physics.
The confusion between bodies and interactions no longer applies, as
bodies have state & material, and interactions have (for lack of better
word) physics... no?
> In the present case, it would give :
>
> Ip2_CohFricMat_CohFricMat_RockJointInt
>
> or just :
>
> Ip2_CohFricMat_CohFricMat_RockJoint (a "joint" is an interaction).
I would like to keep the type suffixes, even if it is clear what they
are. Like all Materials are *Mat, interaction geometries are *Geom,
interaction physics *Phys, states are *State (the exceptions are Shapes,
which are quite few and generally used, and Bound, which we have just
Aabb).
What do you think about Ip2_2xCohFrictMat_RockJointPhys (I mean, about
the "2x")?
BTW the base class is FrictPhys (not FricPhys), so either we go with
CohFrictPhys, or FrictPhys is renamed to FricPhys (I was thinking about
FricPhys before, but I thought it might sound funny for french, so I
chose FrictPhys instead).
> "Rock" is perhaps a bit vague, isn't there a better description of the law?
BTW wasn't Luc working on rock joint planes etc?
v
Follow ups
References