| Thread Previous • Date Previous • Date Next • Thread Next |
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
| Thread Previous • Date Previous • Date Next • Thread Next |
