yade-dev team mailing list archive

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

> The problem : people not using ElasticContact law (Tien, JF Jerier, 
> viscous law of Sergei perhaps, etc.) will have to define ks when this 
> parameter perhaps does not exist in their model. This code you 
> copy/pasted is the same in many constitutive laws, but not in _all_ 
> constitutive laws.
>
> Intuition is a matter of how you introduce things. Say, this function 
> rotates the interaction and return the shear displacement, would it 
> make more sense? Rotating the contact force is not really modifying 
> it, is it? ;)
Would be OK to assume that all constitutive laws have some notion on 
shearDisplacement? If so, it is the shearDisplacement that will be 
rotated and updated. But it would assume that NormalShearInteraction (if 
we talk about ElasticContactLaw) stores shearDisplacement, not 
shearForce. I think it would be possible; most models I am aware of take 
strains (displacements, ok) as primary. It will work with plasticity and 
viscosity also.
> Ok, we are facing the conflict between incremental and total 
> formulations again. It needs to think twice to keep both of them 
> possible in simple code.
>
> Incremental approach : the constitutive law needs current (rotated) 
> force AND the increment of shear displacement OR shear velocity. The 
> total displacement is undefined and we don't need it.
As said above, would it be thinkable to have total shear force not 
stored anywhere, just "total" displacement and displacement increments? 
For plasticity, you would have to do something like

 if |Fs|>Fn*tan(phi):
    shearDisplacement*=(Fn*tan(phi))/|Fs|
    Fs=ks*shearDisplacement

instead of the current simple magnitude clip:

 if |Fs|>Fn*tan(phi): Fs*=(Fn*tan(phi))/|Fs|.

In the continuous formulation, shearDisplacement (any abbreviation for 
that? strain is eps(ilon); is d for displacement? displ is like display, 
u,v,w are oriented) would be the elastic part and the plastic part would 
just disappear.
> Total approach : computing the interaction needs initial orientation 
> (stored in the geometry class already, storing the shear displacement 
> would be a bit redundant) and current orientation. Does it need to 
> rotate the force at all? Perhaps this updateShearForce is needed only 
> with the incremental approach after all?
Yes, only for incremental, that's why I thought it whould be inside 
SpheresContactGeometry, since this class is used for the incremental 
approach. For the non-incremental, it will be Dem3Dof_Sphere* (now in 
the  hasShear part of SpheresContactGeometry), which is like half-done.

V.