yade-dev team mailing list archive

[François <francois.kneib@xxxxxxxxx>]

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.