It will certainly not hurt you, but it will hurt the code as whole. We
will end up having everybody his/her own classes, each with their
peculiarities, and no real cooperation.
Ah... come on...
You said it would be a mess if everybody was doing the same as me (i.e.
changing constants in existing class). I made a defensive answer : it
was not an existing class. Now you take this as a sign of
non-cooperative attitude...
This kn=E.d law is not a specific arbitrary thing based on my personal
taste. It is a widely used definition of stiffness. Before this class,
there was no choice other than Hentz law with the funky factor. I keep
thinking FP law was a necessary addition not only for me, and I'm glad
that others use it now.
Honestly, when I write "my" class sometimes, it refer to a class I feel
responsible for : if it doesn't work I'm the one to blame, if there are
questions I have to reply and explain (what I'm doing now).
To try and conclude this discussion, I suggest a hierarchy in
sophistication like this :
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.
Level 3 : realistic laws like Hertz-Mindlin.
Based on this hierarchy, you clearly see that there is no reason to see
a multiplication of classes in lvl1 (except if somebody wants a pi or a
sqrt (7) somewhere ;)). The major risk is at lvl2, were there is no
general theory and funky factors appear. At lvl 3, there is no big risk
of seeing a growing population of duplicated class, since Hert-Mindlin
is a widely recognized approach, and it is relatively complex to
implement. Lvl0 could be an interesting addition, it could be optional
in Ip2_FP.
Ok, enough philosophy. 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.
Should I just keep everything as it is now, and face the same
misunderstanding again (as mentionned by Chiara, it is not the first
time those names generate confusion)? Seriously, I'm not sure what is best.
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.
Cheers.
Bruno
_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
