yade-users team mailing list archive

[Václav Šmilauer <eudoxos@xxxxxxxx>]

Probably the cleanest way would be to create your constitutive law,
something like:

/* add neverErase (false by default) to ef2_Spheres_Elastic_ElasticLaw,
    which would skip calling requestErase */

class Law2_Spheres_ElectroElastic: public ef2_Spheres_Elastic_ElasticLaw{
    Law2_Spheres_ElectroElastic(){ /* change in parent class*/
neverErase=true; }

    go(shared_ptr<InteractionGeometry>& ig,
shared_ptr<InteractionPhysics>& ip, Interaction* I, MetaBody* rb)
    {
        ef2_Spheres_Elastic_ElasticLaw::go(ig,ip,I,rb); // call parent's
function
        /* handle the interaction here again;
            you could either call another functor from which you
inherit, or just put regular code here */
    }
};


> The problem is this happens in functors, like
> ef2_Spheres_Elastic_ElasticLaw. So, it is impossible to change this in
> only one place for all.
Why not?
> What I have in mind now is to add a bool to the parameters of functors
> (the one I use), and a flag in ElasticContactLaw that would be passed
> to functors :
>
> - ef2_Spheres_Elastic_ElasticLaw(..., bool allowDelete=true)
Yes, makes sense, I would just call it neverErase
> For a more general solution with N interaction laws (*), we could just
> decide that colliders will erase interractions only if no constitutive
> law need it.
> For this purpose, the function "requestDeletion" could be replaced by
> "requestKeep", and all interactions would be deleted unless *at least
> one* constitutive law decides otherwise. In this case, the
> "allowDelete" flag is not needed any more.
Wouldn't work, since the collider would have to traverse many more
interactions at every step and track which ones were not requestKeep'd
> (*) I recall all laws must use the same unique type of interactions,
> since Yade does not handle multiple interactions between two bodies.
> This is not a big problem with multiple inheritance. If I want
> electric(**), elastic, and capillary interactions between bodies, I
> can simply define a IPhysics class like this :
I would be careful with multiple inheritance. I am not a c++ expert, but
isn't the virtual function call slower with multiple inheritance? Also,
yade's RTTI (REGISTER_CLASS_AND_BASE etc) might choke on that, and the
dispatchers as well; don't know.

> A unique constitutive law inheriting from the "N" individual
> constitutive laws is possible as well (it doesn't solve the initial
> problem, since "requestDeletion" is inside functors).
If you think this would be generally useful, it could be added to
ConstitutiveLaw class itself; that would allow chaining arbitrary
functors as shown above; I doubt it is a typical case, though.

Vaclav