yade-users team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>]

>> Also, note that in some cases (in mine in fact :)), 
>> InteractingSphere2InteractingSphere4SpheresContactGeometry::interactionDetectionFactor 
>> will be more than one while Body2AABB::interactionDetectionFactor will 
>> be 1. The typical situation for that is a cohesive contact, which will 
>> break in tension in a "distant" situation, but will be created ONLY IF 
>> there is a real (not-distant) contact at the beggining.
>>   
>>     
>
> If I get it right, setting >1 for *2*4*Geometry and having regular AABBs
> will make the behaviour non-isotropic, since in diagonal directions
> spheres will be collided earlier (as soon as dist<(sqrt(2)*(r1+r2))),
> while in the axial directions, that will happen at dist<(r1+r2). Unless
> you handle that specially in *2*4*Geometry, you will have more diagonal
> contacts being created and they will be distant.
>   
Ah, you are right. I told you something wrong. With cohesive contacts, I 
use InteractionFactor=1 in both engines in fact, but I still need the 
"distant" variant of *2*4Geometry because only this one will update the 
geometry and keep isReal=true for distant configurations.
To make it clear : I never create distant interactions, but I can delete 
distant interactions; in that case I use "distant"  engines with 
radiusFactor=1. And it should be isotropic...

> In my case, I will set those sphere factors to >1 for first few
> iterations, so that cohesive contacts are create between particles that
> are initially close together (i.e. that are "structural", not just
> coming together during simulation) and then, I reset those to 1 and
> create non-cohesive contacts.
>
>   
Ok. It makes sense in concrete (I guess you will define an equilibrium 
position with interpenetration!=0 then?), but - generally speaking, it 
is not necessary to create cohesion between distant bodies in order to 
simulate a cohesive material, cohesion at contacts is sufficient.

> The interaction of engines is getting complicated, I will (perhaps) try
> to document that. We should say for good who is responsible for deleting
> contacts (I think constitutive law, not the collider)
Yes, constitutive law should do that.

>  and rename the
> isReal flag to seomthing more meaningful (like isPenetrating)
"isPenetrating"?!! The actual meaning is more "isInteracting" : it can 
be true in distant configurations as long as a cohesive interaction 
persists.
Because of those lines in Interacting2Interacting4DistantGeometry :

if (penetrationDepth>0 || c->isReal)
    {
        ....
   
        return true;
 }

(Remember that this return value is used to define isReal...)


>   Would
> you agree with that? (Luckily, persistentInteractions will die soon.)
>
> Janek, is there a guarantee that I can do
>
>  for(InteractionContainer I=ic->begin(); I!=ic->end(); ++I){
>     /*...*/
>     ic->erase((*I)->getId1(),(*I)->getId2())
>  }
>
> without invalidating the iterator I (and crashing or whatever)?
> (Currently I push interactions to be deleted into a
> std::list<pair<bodyId_t,bodyId_t>> and then iterate over that, once the
> loop over interactions is finished.)
>
>   
Why do you need to delete them? I though the collider would do that as 
soon as the constutive law set isReal=false.
Line 201 in DistantSAP :

if (overlap && !found)
        transientInteractions->insert(body_id_t(id1),body_id_t(id2));
        else if (!overlap && found && !interaction->isReal)
        transientInteractions->erase(body_id_t(id1),body_id_t(id2));
 
Did I miss something?


Bruno

 
_______________
Chareyre Bruno
Maitre de conference

Institut National Polytechnique de Grenoble
Laboratoire 3S (Soils Solids Structures) - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : 33 4 56 52 86 21
Fax : 33 4 76 82 70 43
________________

_______________________________________________
Yade-users mailing list
Yade-users@xxxxxxxxxxxxxxxx
https://lists.berlios.de/mailman/listinfo/yade-users