I forgot to mention one thing that could be used: inheriting functors instead of duplicating what they do. It needs to convert IP/IG base classes to derived classes in the derived functor, as in [1]. It may be possible to handle this with a set of macro. B
[1] https://github.com/yade/trunk/blob/master/pkg/dem/Ig2_Sphere_Sphere_ScGeom.cpp#L57 On 22/06/15 11:30, Bruno Chareyre wrote: > Hi there, > Since the capillary model of Luc Scholtès, the implementation of > capillary models in Yade has always been using sorts of hacks. > > What capillary models imply is that we can have two simultaneous > interactions between the same two objects: one corresponds to solid > contact force, the other corresponds to pendular bridge forces. The > forces are additive, and both interactions can be computed using the > same IGeom, fortunately. > > For Luc, the problem was (and it still is) that the dispatching will > never pull two types of interactions for two objects (only one Law2 is > called). Hence we cannot have two ordinary interactions acting between > two bodies. > > The hack of Luc (blame me, I think I suggested this): make capillary law > a global engine that uses IGeom data defined in the interaction loop but > which is executed after the interaction loop. It has its own loop on > interactions independently of dispatching. > Problems: > - one more loop > - parallelization has to be reimplemented > - handling capillary data needs to add variables to IPhys and then it > needs a special IP2 functor to generate a special IPhys (FrictPhys -> > CapillaryPhys), a lot of code duplicated just for adding 1 or 2 > variables to a class. > > A more recent strategy (by Anton) is to implement solid contact + > capillary force in a unique Law2. Advantage: no additional loop. > > The worst problem in both cases is: the capillary model is restricted to > a particular contact law, although they are independent physics model. > So, if we want capillary forces combined with e.g. HertzMindlin contacts > we need to 1/ duplicate the full capillary model in the HM context > ("Anton"'s way) or 2/make the capillary model handle two different IPhys > by reimplementing a dispatching mechanism. > > The second option leads to the following in > Law2_ScGeom_CapillaryPhys_Capillarity.cpp: > if (!hertzOn) cundallContactPhysics = > static_cast<CapillaryPhys*>(interaction->phys.get());//use CapillaryPhys > for linear model > else mindlinContactPhysics = > static_cast<MindlinCapillaryPhys*>(interaction->phys.get()); > > A series of awkward "if (!hertzOn)" is seldom found in the rest of the > code to. > Obviously this approach cannot be generalized to more than two different > IPhys, the code would be a big mess. > > What we want: > A- having N possible contact laws, and M possible capillary models... > and why not L remote electrostatic attraction models (for instance), > B- being able to combine all them in simulations with no additional > implementation, i.e. only N+M+L implementations in total > > What we have, be it with Luc's way or Anton's way: > A framework in which handling all possible combinations needs N*M*L > implementations... > > Can we do something about it? Any idea? > > Bruno > > > -- _______________ 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
