← Back to team overview

yade-users team mailing list archive

Re: Distant and/or multiple interactions


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.



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