yade-dev team mailing list archive

[Václav Šmilauer <eu@xxxxxxxx>]

> free end position in L6GeomInc :
> Vector3(3.3886340639637584,7.8792525473155308,-6.7166071545283756)
> free end position in ScGeom6D :
> Vector3(3.3823175232092986,7.8859989218194588,-6.7148657033006511)
Oh, quite nice agreement :-) I would expect higher discrepancy since 
ScGeom6D gets the angles with more precision.
> Now, more annoying : type this once the beam is stabilized :
> O.bodies[0].state.angVel=Vector3(0,0,0.01)
> In both cases you will see growing errors in the form of a weird deformed shape after
> enough 360° turns (earlier with ScGeom, I confess).
I will check. What constitutive law you used with ScGeom6D, and with 
what parameters? I don't know where a problem could be, perhaps it is 
just that the beam shape is unexpected (but correct) due to extreme 
torque between spheres, together with inertia?
> Not sure if this is due to approximations in shearDisp, rotations, both, or still
> something else. It would be interesting to investigate this, though I doubt it really
> invalidate simulations of dense packings.
It should be reasonably stable even under extreme conditions (not just 
dense packings), that was one of the objectives I had in mind --
> Side questions on this.
> 1. It seems that L3Geom::applyLocalForceTorque will always use radius and normal to define
> x1c. Isn't it therefore restricting to spherical bodies, as in
> Law2_ScGeom_FrictPhys_CundallStrack::sphericalBodies=true? (see
> http://www.mail-archive.com/yade-users@xxxxxxxxxxxxxxxxxxx/msg02715.html)
Yes, I know; I was about to add 2 real branch vectors to L3Geom, but I 
have not done it yet. Currently it makes no difference on dynamics, 
since non-spherical particles are always non-dynamic (wall, perhaps 
facet once that is implemented). Reasonably easy to fix in the future.

> 2. It is not clear for me how local coordinates make things simpler. For linear
> elasticity, it looks exactly the same (3 lines in both cases).
I think it makes difference for vector quantities, e.g. relative 
velocity is (uCurr-uPrev)/dt, one can store plastic deformation (which 
does not have to be rotated at every step), u[0] is always the normal 
deformation component (no need to .dot(normal)) and so on. Maybe it is 
just that I feel more comfortable in the local system; of course one can 
always write the same in global coords, though perhaps with more ops. 
Which is the elastic 3-liner for ScGeom6D (I did not know such code 
existed)?
> 3. I thought that L3/L6 was for research purpose. Don't you think that, if users start
> implementing more complete laws (not just linear elastic) on this basis, it will result in
> duplicating existing code (Ig2_Sphere_Sphere_L3Geom_Inc itself is in a large extent a copy
> of ScGeom code - not saying you pasted, but it is really the same)?
For me, research is to get interesting ideas to work (or find that they 
don't work, and see why not); if they do, why not use them? If people 
(including myself) use L3Geom, I will be pleased, if not, it can be 
deleted again. The code in Ig2_Sphere_Sphere_L3Geom_Inc is perhaps not 
the same as in ScGeom -- some parts are, and I was reading ScGeom code 
before, but I can say with clear conscience that I did not type a single 
equation without full understanding. I don't think new geom class will 
lead to duplication of code in terms of contact laws, besides the very 
basic ones (ElPerfPl for instance).

Cheers, v.