yade-users team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>]

>   
> > 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?
>   

For instance, now I have this implemented :

ef2_Spheres_Elastic_ElasticLaw(..., bool allowDelete=true)
{
...
if (allowDelete) requestDelete;

}

It works. But if later I want to switch to Law2_Dem3Dof_Elastic_Elastic, I will have to make the same change in this one again. Functors have to be modified one by one, that is what I meant.



> > 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
>   
Haha! Why would neverErase be better than allowDelete or eraseSometimes? 
English grammar matters? ;)


> > 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
>   
Mmmmh. The collider already traverse all interactions right (not in the 
erase process indeed, but more globally it does)? Why would it make 
"many more" in that case? In the worst case, you cycle over all of them 
and erase the ones not requestKeep'd. Biggest loop, yes, but is there 
another option in the situation where you don't know which law should 
have the last word (capillaryLaw is a simple case because we know 
capillarity must always have the last word vs. elasticity)?

> >     
> 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.
>
>   
Ah, yes, dispatchers might be confused. Sequential inheritance would be 
saffer, for the same result.
> > 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.
>
>   
No, not typical for now. And I'm happy with sequential "action()" from 
different engines currently.

Bruno




--

_______________
Chareyre Bruno
Maître de Conférences

Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : 33 4 56 52 86 21
Fax : 33 4 76 82 70 43
________________