← Back to team overview

yade-users team mailing list archive

Re: About the moment calculation in cohesion-friction model


Actually just today we were discussing there the equilibrium distance
concept. My conclusion is that it should be added to ScGeom so that it
works for those "continuum-like" materials.
Better derive a class for continuum like materials (see below). It is not very good to add more data when most code will not use it.

  In fact, it was the biggest
obstacle when I tried (never finished) to adapt the Cpm model to ScGeom.
The option was to store the initial distance in CpmPhys (which is
actually, looking at your code, what you do actually with
CFpmPhys::initD), but I did not go along that path as it would be only a
Is it really a hack? Equilibrium distance can be seen as a physical variable of the contact. It can change to reflect damage, etc. This is perhaps the best option : no added data in ScGeom, no new Ig class.
What about the other 2 laws? Chia Weng's law is cohesionless and follows
faithfully Jean-Patrick's paper, that is what I gathered. Janek's law
(Law2_ScGeom_CohFrictPhys_ElasticPlastic) differs in that is has
additionally twist and tension? Is there a paper that describes it?

This is how I see things : usually, when people say "it follows Plassiard", they mean variables have the same names and all assumptions and conventions in parameter definitions, micro-macro passage, and such are the same. It is not really the good question for sorting contact laws. Defining kn=E.D (for instance) is just a question of modelling, not computing, and as such, it is out of the scope of law functors. Different users will always do that differently, and it should be handled in Ip functors. OTOH, computing relative torsion/bending between two bodies will always be done with the same algorithm. Same for returning moment=k*rotation, regardless how k is defined. So, most of diffs between the 3 law functors could/should actually be confiined to Ip data and functors.

[The best would be to provide a few functions (to ScGeom or some more
complex class) that would handle bending and twisting, similarly to how
ScGeom::rotate() handles shear displacement. Then respective models
would make use of them to get their work done in a few lines.]

Not in ScGeom : relative rotation needs initial orientations of each bodies stored in the interaction -> we want no more data in ScGeom. The plan is to add data in the future 6DofScGeom and move the moment code in there. Currently, this data is in interaction physics.

About documentation, don't be too pessimistic. The algorithm for rotations is easy to understand (provided you exclude all aspects regarding Poisson, Young, and other modelling tricks, as suggested above).