On Wed, Nov 28, 2012 at 2:08 PM, Barry Smith <bsm...@mcs.anl.gov> wrote: > > On Nov 28, 2012, at 3:00 PM, Michael Povolotskyi <mpovo...@purdue.edu> 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 ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
