yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>]

> What is the reason for merging? I don't see any single benefit in that.
>
>   
Huh!? I really wasted my time then.

> The only would be if you precomputed summary shear displacement rather
> than increment, so that it could be stored from Dem3Dof and ScGeom
> together, but you do not do that.
>   
Precomputing what is needed for Dem3Dof functors and laws is not my job, 
is it? Shear displacement is not needed for most functors we have in 
Yade, and for me it is impossible to define in a general way.

> Do you have a design paper/wiki page etc for ScGeom? I cannot read all
> that code now. To my taste, it is all too hairy to serve as a good
> basis.
>   
Maybe read it before stating how it is... For reference, see PFC manual.
> You put twisting/bending inside ScGeom. That is not economical and just
> adding that to Dem3DofGeom without any value added... why?!
>
>   
There is no twisting and bending in ScGeom itself. Again, ScGeom is 
normal, contact point, r1, r2. Cached values are rotations of the local 
coordinate system and shear increment, not bending and twisting.
> > those classes contains mostly duplicated code btw
> >     
> No more than necessary.
>
>   
With ScGeom, it is not necessary at all.

> The fact of not distinguishing sphere+{sphere,facet,wall} cases makes me
> think it cannot work properly, especially when it comes to plasticity
> and so on.
>   
It can. A contact point is a point. It doesn't care if the bodies behind 
are cubes or spheres.
Could you suggest an exemple of where this does not apply?

> Sorry to be brief. To summarize: I don't understand the reason for that.
>   
So, I revert and resume working with ScGeom as usual? Not really a 
problem. I this case, I hope I'll not hear comments on developments 
being "not-prospective" when energy tracing is implemented or when  6DOF 
code will be moved from Ip to Ig6DOF (it will be in a class inheriting 
from ScGeom obviously).

Bruno