yade-users team mailing list archive
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.
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.
Haha! Why would neverErase be better than allowDelete or eraseSometimes?
English grammar matters? ;)
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
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)?
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
Ah, yes, dispatchers might be confused. Sequential inheritance would be
saffer, for the same result.
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.
No, not typical for now. And I'm happy with sequential "action()" from
different engines currently.
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.
Maître de Conférences
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