On 26/06/15 10:04, Anton Gladky wrote: > Hi all, > > my 2Cts. I think we should avoid an additional loop in any case. > It will hurt the calculation speed drastically. > > Most of capillary laws implemented by me are more-less "independent" [1] > and can theoretically be used as external static functions, which are > calculating just an additional adhesive force. The problem is if someone want to use those adhesive forces combined with Hertz contacts, he can't. It would need to implement a new law functor.
> I think first of all we should finish migration into Python3 and Qt5, because > it can happen, that Yade will not be able to be compiled on new > systems soon. Of course, but I feel useless here. :) Bruno > [1] > https://github.com/yade/trunk/blob/master/pkg/dem/ViscoelasticCapillarPM.cpp#L219 > > Best regards > > Anton > > > 2015-06-24 10:18 GMT+02:00 François <[email protected]>: >> Hi all, >> >> I totally agree with you, this kind of flexibility would be very helpful. >> In the same fashion (but independently of this issue), if you want a contact >> between a Sphere and a GridConnection, the force on the GridConnection have >> to be dispatched on the two GridNodes in the contact law. It means that also >> you want a simple elasto-frictional law you currently have to copy the >> existing law (designed for two-bodies-contact) into a new one that just >> apply the force differently (on three bodies). >> >>> I am thinking that maybe allowing dispatcher to call not just the >>> first one class that matches, but all of them (that were setup >>> beforehand inside O.engines InteractionLoop), could solve the problem? >>> >>> You are absolutely right. >>> In this case it still needs to workout a model for data classes. >>> Multiple inheritance maybe? But it may generate ambiguities: >>> >>> class ViscElCapPhys : public ViscElPhys, public CapPhys { >>> ... >>> REGISTER_CLASS_INDEX(ViscElCapPhys, ??????) >>> }; >> >> The idea is good, do you agree that this "multiple dispatcher calls" design >> should only occur on this particular capillary physics ? Otherwise I'm >> afraid that this could be a nightmare for simulations with different >> materials, one inheriting from the other. I have the feeling that a more >> generic and configurable way exists, allowing the user to define which are >> the multiple contact physics and law he wants. For example (but maybe weird >> and painful to develop), multiple materials per body, allowing multiple >> interactions ? (a classical elasto-frictional one and a capillary one for >> example) >> For both solutions, it looks like we have to consider either multiple >> interactions between two objects, or multiple physics per interaction. >> >> François. >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~yade-dev >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~yade-dev >> More help : https://help.launchpad.net/ListHelp >> > _______________________________________________ > Mailing list: https://launchpad.net/~yade-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~yade-dev > More help : https://help.launchpad.net/ListHelp -- _______________ Bruno Chareyre Associate Professor ENSE³ - Grenoble INP Lab. 3SR BP 53 38041 Grenoble cedex 9 Tél : +33 4 56 52 86 21 Fax : +33 4 76 82 70 43 ________________ _______________________________________________ Mailing list: https://launchpad.net/~yade-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
