yade-dev team mailing list archive

["Kien Dang, Mr" <kien.dang@xxxxxxxxxxxxxx>]

Hi,
According to my understanding,  the shrink factor in the paper is used to avoid the sphere interact with more than one facet, it is; however, not effective and it may cause unstability if shrink factor is too large and determine shrink factor suitable for each simulation is somehow unrealistic. In my opinion, we can remember the number of coincided contact points (in IF2IS4SC) for each sphere, we can check the conincidence by some criterion (contactpoint-contactpoint).Length() smaller than some value (can be tol*sphere radius) and then in the constitutive law the force at the contact will be divided by that number. By that way we can avoid complicated algorithms. 

Regards,

Kien Dang

-----Original Message-----
From: yade-dev-bounces+kien.dang=mail.mcgill.ca@xxxxxxxxxxxxxxxxxxx [mailto:yade-dev-bounces+kien.dang=mail.mcgill.ca@xxxxxxxxxxxxxxxxxxx] On Behalf Of Václav Šmilauer
Sent: Thursday, March 19, 2009 4:15 AM
To: Yade Development Group
Subject: [Yade-dev] facets

Sega (and others),

I commited Dem3DofGeom_FacetSphere class recently, along with a test 
script in scripts/test/Dem3DofGeom.py.

1. I copied your algorithm from 
InteractingFacet2InteractingSphere4SpheresContactGeometry without 
understanding some parts of that. Could you please review the code 
briefly that it does what it should? In the test script, for example, 
when the sphere passes over the boundary of the facet, it seems that the 
contact exists longer than it visually should (but I didn't compare that 
with IF2IS4SCG; it's either bug in my re-"implementation" or in the 
original algo; I didn't want to write from scratch, sicne your approach 
seems to nicely avoid computing distances and uses only vector products, 
which should be much faster; or, if you have some description of the 
algo, can you pass me a reference?).

2. The shrinkFactor, if I understand, is there to make the surface 
smoother. We still may have two interactions at the edge at the same 
time, which means that the surface rigidity doubles at those points. I 
propose to add the following topology information to InteractingFacet:

  bool edgeActive[3];
  bool vertexActive[3];
  body_id_t edgeNeighbours[3];
  // maybe also vector<body_id_t> vertexNeighbours[3]

(the names would be different to match spartan naming onf the other data 
members). Then I would make some initializer called, for example, 
FacetTopologyAnalyzer, that would fill those information. Common 
edges/vertices would be active only on one the adjacent facets and the 
inactive ones wouldn't interact at all (in the sense of 
InteractionGeometry).

For the neighbour topology, the point would be to preserve interaction 
data (such as plastic strain, initial contact point etc) accross facet 
boundaries, but I am not yet sure how to handle that correctly (not in 
collider, not in the InteractingGeometryMetaEngine either?, ...).

In the future, it would also be possible to exploit this information 
(and by adding relative angle of the 2 facets that meet at the edge) to 
smooth the transition for neighbours (think b-spline/cylinder 
interpolation, whatever). But let's start with smaller things first.

Any comments on that?

Vaclav


_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp