yade-dev team mailing list archive

[Vaclav Smilauer <eudoxos@xxxxxxxx>]

Bruno Chareyre napsal(a):
> Václav Šmilauer a écrit :
> > Bruno,
> >
> > I compared today results of old brefcom that used incremental
> > computation of epsN (roughly the same as in ElasticContactLaw)
> I guess you meant epsS? Because in ElasticContactLaw, Un is not computed 
> incrementally, only Us is.
> >  with new
> > version that does that based on original contact point position (see in
> > SpheresContactGeometry docs). Before, I was using timestep
> > .2*PWaveTimeStep, now I got to 1*PWaveTimeStep with only small change in
> > the strain-stress diagram (the simulation didn't explode). Time per
> > iteration is a bit larger (by about 5-10%) due to more complicated
> > calculations involved. Let me know if you would like to try, adapting
> > ElasticContactLaw would be quite easy.
> >
> >   
> Unfortunately, it is completely impossible to do that in 
> ElasticContactLaw without changing fundamentaly the physics behind.
>
> Simple example in 1D :
> 1st scenario : relative displacement us : resultant force fs = 
> -fn*tan(phi) (provided the friction threshold was reached)
> 2nd scenario : relative displacement 2*us, then another displacement -us 
> : resultant force fs = fn*tan(phi) (sign changed)
>
> You have the same start/end points in both cases but the forces are of 
> opposite sign, because the force depends on the history of the motion. 
> You will loose history if you don't use an incremental form.
> What you suggest is possible only in a purely elastic problem.

My algorithm tracks the original contact point, but it will be displaced 
if there is plastic slip (Coulomb friction); therefore it ends up with 
the same result as you suggested, provided that the -1*us displacement 
leads to slipping. (I use something similar in brefcom as well; and it 
works)

> Another thing is i'm a bit surprised you could change the timestep while 
> keeping the same stress-strain graph, since this graph is defining - 
> alone - the critical timestep in your problem. Eigenfrequencies are 
> physical quantities that don't depend on the implementation details, 
> just stiffness and mass.

With incremental code, there are 2 factors worsening the accuracy: (1) 
the algorithm itself is approximate, (2) errors accumulate. In the 
non-incremental code, the algorithm is geometrically exact and errors 
don't accumulate.

Therefore I think it is possible that the simulation is more stable with 
the new code.

Vaclav