yade-dev team mailing list archive

[Jerome Duriez <Jerome.Duriez@xxxxxxxxxxx>]

Hi,

Some personnal thoughts, (I guess my coding skills won't allow me to find the solution)

- I completely agree with the two first mentionned problems: the new loop, with parallelization issues

- as for the 3rd problem, I see clearly the incoveniency to redefine e.g. both MindlinCapillaryPhys and CapillaryPhys or associated Ip2 functors. Could this functor inheritance you mentionned help here ?

However, for me, it is just fine than CapillaryPhys (or MindlinCapillaryPhys) is distinct from FrictPhys (or MindlinPhys). Personnaly, I do not really like huge classes (being IPhys, or Law2Functors) that can handle a lot of different things. Because, in the end with such classes, you have to scroll all the attributes to understand the default behavior and be sure what you're doing.
Are such huge classes an objective you have in mind ? (I'm not sure I got all your points)

________________________________________
From: Yade-dev [yade-dev-bounces+jerome.duriez=ucalgary.ca@xxxxxxxxxxxxxxxxxxx] on behalf of Bruno Chareyre [bruno.chareyre@xxxxxxxxxxxxxxx]
Sent: June 22, 2015 4:06 AM
To: yade-dev@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Yade-dev] Call for brainstorming and re-design / capillary models issue

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     : yade-dev@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp