yade-users team mailing list archive
Mailing list archive
[Fwd: Re: Distant and/or multiple interactions]
(older message forwarded)
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
--- Begin Message ---
> 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.
Yes, unless you put it to ConstitutiveLaw itself, which, as I said, is
perhaps not generally useful. But that change is rather trivial in most
> Haha! Why would neverErase be better than allowDelete or eraseSometimes?
> English grammar matters? ;)
Just for consistency sake; if we call it requestErase, it would be
bizzare to have allowDelete; and the "never" makes it clear when that
will happen. ("sometimes" is long and feels like that arbitrarily
sometimes we erase, sometimes not; and "allow" would suggest that
erasing interaction is something exceptional).
> >> 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
No, it doesn't (neither PersistentSAPCollider did, FYI). It only sees
when there is inversion (i.e. 2 bboxed did not overlap and overlap now
or vice versa, along any axis); that's why we needed requestErase (which
remembers the interaction), instead of just setting some interaction
flag inside the interaction itself.
--- End Message ---