yade-dev team mailing list archive

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

> >  	Real maxFsSq=phys->normalForce.squaredNorm()*pow(phys->tangensOfFrictionAngle,2);
> >  	Vector3r trialFs=phys->ks*geom->displacementT();
> > -	if(trialFs.squaredNorm()>maxFsSq){ geom->slipToDisplacementTMax(sqrt(maxFsSq)/phys->ks); trialFs*=sqrt(maxFsSq/(trialFs.squaredNorm()));}
> > +	Real multiplier=maxFsSq/trialFs.squaredNorm();
> > +// 	if(trialFs.squaredNorm()>maxFsSq){
> > +// 		geom->slipToDisplacementTMax(sqrt(maxFsSq)/phys->ks); trialFs*=sqrt(maxFsSq/(trialFs.squaredNorm()));}
> > +	if(multiplier<1){
> > +		multiplier = sqrt(multiplier);
> > +		geom->scaleToDisplacementTMax(multiplier); trialFs*=multiplier;}
> 
> Are you nuts??? What if trialFs.squaredNorm()==0 ?

Sorry for inappropriate brevity. Intel CPUs (including the newest i7)
treat NaN's (and I think also inf's, but I have no evidence for that)
specially: rather than performing the computation in the
arithmetic-logical unit (ALU), operations with NaN's are emulated on the
CPU; that makes such computations by orders of magnitude slower (like
100x): it happenned to me once when particles were getting NaN positions
(by an error of mine) and the computation slowed down about 100x at the
moment. (AMD CPUs handle inf and nan in the ALU and don't have this
slowdown)

Besides that

	geom->scaleToDisplacementTMax(multiplier);

is manifestly incorrect, as multiplier is a dimensionless force ratio,
whereas displacementT is, well, displacement, a length.

V.