Hi Jerome,
just a suggestion coming from a discussion with Frederic. Is the
name RockJointLaw really adapted to you code since it is more
concerned with the behaviour of the gouge material that can be
contained inside a rock joint? Indeed, with the title RockJoint,
users could think that the law is able to deal with all the rock
joint properties such as the Joint Roughness Coefficient or the
Joint Compressive Strength such as studied in this article
(http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6V4W-4W91CS7-1&_user=2322062&_coverDate=12%2F31%2F2009&_alid=1194322065&_rdoc=1&_fmt=high&_orig=search&_cdi=5769&_sort=r&_docanchor=&view=c&_ct=196&_acct=C000056895&_version=1&_urlVersion=0&_userid=2322062&md5=0a06d0f68437f9aba75e48db7e55a61c
<http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6V4W-4W91CS7-1&_user=2322062&_coverDate=12%2F31%2F2009&_alid=1194322065&_rdoc=1&_fmt=high&_orig=search&_cdi=5769&_sort=r&_docanchor=&view=c&_ct=196&_acct=C000056895&_version=1&_urlVersion=0&_userid=2322062&md5=0a06d0f68437f9aba75e48db7e55a61c>).
Sorry if I add some confusions to the discussion. As said earlier,
it is just a suggestion coming from my very new and little
experience in rock mechanics...
Regards
Luc
2010/2/4 Jerome Duriez <jerome.duriez@xxxxxxxxxxxxxxx
<mailto:jerome.duriez@xxxxxxxxxxxxxxx>>
I agree to give any name you want if you think it makes more
sense. But for the moment I did not have time to read the link
Vaclav sent me about naming. So I do not have my own opinion.
So, either you can wait until this, either you have to get agree
between you ! For a better description of the law, you can find in
the .hpp of the file :
---- beginning of quoting ----
"\brief Contact law including cohesion, moment transfer and
inelastic compression behaviour
This contact Law is inspired by CohesiveFrictionalContactLaw
(inspired itselve directly from the work of Plassiard & Belheine,
see the corresponding articles in "Annual Report 2006" in
http://geo.hmg.inpg.fr/frederic/Discrete_Element_Group_FVD.html
for example). It allows so to set moments, cohesion, tension limit
and (that's the difference) inelastic unloadings in compression
between bodies.
All that concerned brokenBodies (this flag and the
erosionactivated one) and the useless "iter" has been suppressed.
The Relationsships corresponding are RockJointLawRelationships,
where the rigidities, the friction angles (with their tan()), and
the orientations of the interactions are calculated. No more
cohesion and tension limits are computed for all the interactions
To use it you should also use :
- CohesiveFrictionalMat for the bodies, with "isCohesive" = 1 (A
verifier ce dernier point)
- RockJointLawRelationships (=> which involves interactions of
"RockJointPhys" type)"
--- end of quoting ----
I'm afraid it would be too long for the name, and still no better
short idea...
Jerome
Václav Šmilauer a écrit :
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
_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
<https://launchpad.net/%7Eyade-dev>
Post to : yade-dev@xxxxxxxxxxxxxxxxxxx
<mailto:yade-dev@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~yade-dev
<https://launchpad.net/%7Eyade-dev>
More help : https://help.launchpad.net/ListHelp
-- Jérôme Duriez
ATER Iut 1 Grenoble, département GMP - Laboratoire 3S-R
04.56.52.86.49 (ne pas laisser de messages sur le répondeur)
_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
<https://launchpad.net/%7Eyade-dev>
Post to : yade-dev@xxxxxxxxxxxxxxxxxxx
<mailto:yade-dev@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~yade-dev
<https://launchpad.net/%7Eyade-dev>
More help : https://help.launchpad.net/ListHelp
------------------------------------------------------------------------
_______________________________________________
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
