yade-dev team mailing list archive

[luc scholtes <lscholtes63@xxxxxxxxx>]

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
).

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>

> 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
>> 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
> Unsubscribe : https://launchpad.net/~yade-dev<https://launchpad.net/%7Eyade-dev>
> More help   : https://help.launchpad.net/ListHelp
>