From: John P. <pet...@cf...> - 2012-11-29 21:59:50
|
On Wed, Nov 28, 2012 at 2:08 PM, Barry Smith <bs...@mc...> wrote: > > On Nov 28, 2012, at 3:00 PM, Michael Povolotskyi <mpo...@pu...> wrote: > >> Thank you. >> Looks like also others treated this parameter erroneously as the absolute tolerance: >> >> For example, the Libmesh library: >> http://libmesh.sourceforge.net/doxygen/classlibMesh_1_1PetscNonlinearSolver.php#a1d5ed777465c1f08785bc321c84c7c71 >> >> 00486 // Set the tolerances for the non-linear solver. >> 00487 ierr = SNESSetTolerances(_snes, this->absolute_residual_tolerance, this->relative_residual_tolerance, >> 00488 this->absolute_step_tolerance, this->max_nonlinear_iterations, this->max_function_evaluations); >> >> Am I right that they have a problem? > > Based on the name of their variable yes it does appear to be wrong. The reason it is a relative tolerance (and not absolute) is that one is computing > > x = delta x + x > > and once delta x is sufficiently smaller than x, delta x + x == x (in floating point) so we don't want to iterate past the point where x is not being changed. So, if I'm interpreting everything correctly, it would be more correct for the third argument to be this->relative_step_tolerance instead of this->absolute_step_tolerance? We could change this, but it might break backwards compatibility: some users may not currently use relative_step_tolerance at all, etc. -- John |