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: [email protected] [mailto:[email protected]] 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 : [email protected] Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~yade-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp _______________________________________________ yade-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/yade-dev
