yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxxxxxx>]

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
________________