yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>]

> Collider::handleExistingInteraction will be (not yet used) reponsible 
> for changing isReal, isNew flags and signalling that the interaction 
> should be deleted (if it returns false). I would like someone (Bruno?) 
> to review to code whether it is OK.
A quick review found nothing wrong. I was just a little surprised by the 
fact interactions are erased in  2 different places (in the core of 
"action()" and in "updateOverlapingBBset"). I don't think this is a 
recent change though.

> Another change I have in mind is removing haveDistantTransient; 
> marking real contacts to be deleted by the constitutive law incurs no 
> penalty, except for a very specific case where AABBs stop overlapping 
> at the same iteration (not later) that spheres geometrically stop 
> touching;
It can be removed IF all contact laws are setting isReal.
This is not the case currently, e.g. _the basic ElasticContactLaw does 
not set isReal_ (and will be break by this change currently).
Removing this flag makes sense, but it is like setting it true by 
default (it is currently false), so it could modify the behaviour of a 
few existing classes besides ElasticContactLaw. Big "warnings" would 
have to be sent to users.
> this happens only if spheres would be aligned along an axis. In that 
> case, the "penalty" would be that the interaction would be marked 
> !isReal by InteractionGeometryMetaEngine and deleted at next iteration 
> by the collider, instead of being deleted by the collider right away.
A small mistake here (perhaps just a typo?).
InteractionGeometryMetaEngine can in fact only set isReal=true (in case 
of geometrical "interaction", i.e. overlap), it cannot revert to 
isReal=false. So, the interaction will be marked !isReal by the contact 
law only, not the IGME. The IGME code is :

/if (penetrationDepthSq>0 || c->isReal){
               if (isNew) {
                   create and initialise the interaction geometry;
                  isNew = false;
       }
       return true;
   }
   else return false;
/
(and then the returned value is used by the dispatcher to set isReal for 
this interaction.)

> Second potential problem with haveDistantTransient is that you can 
> have multiple constitutive laws, of which one will want to keep 
> distant interaction and the other would not (there are no 
> transient/persistent interactions anymore).
I don't really see the relation between this problem and the 
haveDistantTransient flag.
The correct behaviour would be that a contact is "Real" IF there is a 
geometrical overlap OR at least one physical interaction exists.
This is not implemented that way currently, since an interaction law can 
set !isReal even if another type of interaction exists at the same time.
If the interaction of type1 persists while the interaction of type 2 
disapears, and if law2 is after law1 in metabody->engines, then the 
second law2 will make the interaction deletable even if it should not.
Perhaps it needs an additional flag "isPhysical", which would be false 
at the beggining of each timestep, and set equal to (isPhysical || 
hasTypeX) in InteractionLawX.
The collider would set isReal = isPhysical at the very begining of each 
step.
There is perhaps a smarter way to do this, since isPhysical would play 
almost the same role as isReal (the only difference is isReal must not 
be reset at each step).

> Therefore it seems appropriate to require that constitutive laws 
> delete interactions.
Yes, with the condition above.

> Last thing: there are colliders I suspect are not used (and 
> maintained): PersistentTriangulationCollider, SAPCollider, 
> DistantPersistentSAPCollider. Couldn't we remove those from the tree?
- PersistentTriangulationCollider : experimental stuff, it is slower 
than the default collider but it works, and since some simulations are 
(or will be) maintaining a triangulation (e.g. JF Jerier for the volumic 
contact law or Emanuele Catalano in the near future), it is interesting 
to use it for contact detection at the same time.

- SAPCollider : I don't know this. A very old collider from early ages 
of Yade IIRC. Can be removed safely.

- DistantPersistentSAPCollider : the specific features of this one are 
now included in PersistentSAPcollider (the "if (haveDistantTransient) 
{...}" code that you want by default now). It can be safely removed, 
except that it is still used in CohesiveFrictionalTriaxialTest. 
Switching to the "normal" collider in this demo will be a good way to 
check that everything works fine.

Bruno


--

_______________
Chareyre Bruno
Maitre de conference

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
________________