yade-dev team mailing list archive

[Václav Šmilauer <eudoxos@xxxxxxxx>]

> Level 0 : interactions are defined via parameters kn/ks directly. This 
> is what people want to do first most of the time. It is also the PFC 
> way. It is not in Yade currently.
> Level 1 : kn/ks are defined indirectly via E*D. Very close to lvl 0, no 
> assumption behind (why it is called "basic"), but adapted to 
> non-dimensional approaches.
> Level 2 : definitions based on micro-macro concepts like yours.

I don't think I fall in this category (Hentz did, obviously). I am level
1, except that were you scale by 1 (an assumption), I scale by π/2
(another assumpion). I never pretended that E==E* and I don't understand
why you keep accusing me of that ;-).

> Ok, enough philosophy.
Don't abuse that word ;-)
> I have a practical problem : what should I do 
> with ElastMat? The members are called Young and Poisson, while FP needs 
> Kn and KsDivKn (I usually put a capital letter to distinguish k=K.D, but 
> it collides with coding conventions here, I might choose something else).
> If I create a new class at the same inheritance level, just differing by 
> members names, would it be useless duplication? Are Young and Poisson 
> really used for what they are in some engines? If not I can just change 
> the names in ElastMat.

My personal opinion (whole paragraph): I don't care for Poisson, never
used it (we can just as well remove it from ElastMat). For young, it has
clear meaning for me: I think of spherical particles as means of contact
detection for dynamic lattice model, where nodes (sphere's centers) are
connected by kind-of beam elements (without torsion and bending). Then
each beam has (1) some geometry: length (centroid distance) and
cross-section, be it πr² (me) or 2r² (you; although you don't call it
length, I know) and (2) some material (with that young's modulus). I can
then run static simulation with FEM code, just by using special beam
elements with that cross-section and material with the same properties.

For me, the word "young" denotes simply elastic modulus, i.e. anything
that has dimension [Pa] and linearly relates strain and stress; nothing
makes me expect E==E*. (Any person who has basic insight in particle
models will know that particle-level E and packing-level E* are not
simply related, as they depend on packing density etc etc. If we just
say in the doc for young that it is not packing's modulus, there should
be no confusion about that).

Chaning attribute name is delicate business, as we have no way to stay
backward-compatible with scripts (like we do when class is renamed, i.e.
issue warning, but continue), so please try to avoid that.

> If I create a new data class, clearly, FrictMat will inherit from this 
> new one, since the owl "Frict" suite is designed based on the lvl1 
> conception of contacts, where friction is really friction at a contact 
> point.

I think other people on the list should comment on this; my background
is different and the safest bet is to take no opinion. For the concrete
model, I have almost everything in CpmMat already, anyways and can make
it inherit from Material directly.

Cheers, v.