yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>]

Hi Janek,

Let's try and make something clean this time. ;-)
> I need to add two parameters:
>
> - Rolling stiffness coefficient β
> - Moment limit coefficient η
>
>
> Currently β has a fixed value of 2.0 in Ip2_2xCohFrictMat_CohFrictPhys.cpp line 52
>
>   
Make sure what you want is not already implemented. In that case I think 
it is, Luc mentionned CFPM, I know Boon also implemented it in 
CohesionlessMomentRotation (CMR, the Plassiard law). Basically, it is 
more a question of cleaning/merging.
In order to be general, CohFrict would need to integrate rotational 
friction like in CMR but also offer the possibility of rotational 
cohesion (currently infinite as you said, let it be anything, even 0 to 
reproduce CMR).
> Where to add it? Should I add it to CohFrictMat.hpp or should I
> derive from this class and name it CohFricRollMat ?
>   
I think the best is to add everything in CohFrictMat, including normal 
and shearCohesion which are currently in the Ip2 functor.
We can latter derive a "creep" material adding creep parameters to 
CohFrictMat.

> How to name it? rollingStiffnessCoefficient comes to mind. But could
> be also a rollingCoefficient, bendingCoefficient and so on.
>   
"Coefficient" is vague. I'd prefer 
rolling/twisting+Stiffness/Friction/Cohesion.
So that, for instance :
trialTwist = twistAngle*twistStiffness //elastic behaviour
maxTwist = twistFriction*fn+twistCohesion //elastic limit
if (abs(trialTwist)>maxTwist) {do something, taking into account the 
"fragile" flag}
...

> I remember you discussing that CohesiveFrictionalContactLaw should be
> dissected somehow, into a 2-argument functor, or something else. What
> was that?
>
>   
The different angles and axis of relative rotation could be precomputed 
so that the constitutive law would only use the values that it currently 
computes in e.g. Law2_ScGeom_CohFrictPhys_ElasticPlastic::go(). All this 
should be in an Ig class inheriting from ScGeom and adding the 
additional DOF's needed by CF law and duplicates. In the end, large 
blocks of duplicated code can be replaced by just one line accessing the 
Ig data from inside the contact law.

> Last question, why the name Ip2_2xCohFrictMat_CohFrictPhys instead of
> Ip2_CohFrictMat_CohFrictMat_CohFrictPhys. Of course the latter is
> longer. But is there a fixed convention about that? For instance the
> file Ip2_FrictMat_FrictMat_FrictPhys.hpp  definitely breaks this convention.
>
>   
I have no opinion.

Cheers.

Bruno