> > 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.
_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
