From: Barry S. <bs...@mc...> - 2012-11-28 21:30:28
|
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. Barry > Michael. > > On 11/28/2012 03:55 PM, Barry Smith wrote: >> On Nov 28, 2012, at 2:51 PM, Michael Povolotskyi <mpo...@pu...> wrote: >> >>> Thank you for the very prompt response, >>> but what is the answer: is it a relative step tolerance or an absolute step tolerance that is set in SNESSetTolerances and checked after each step? >> It is a relative test: snorm < snes->stol*xnorm || step || < stol || x || where x is the current solution >> >> >> Barry >> >>> Michael. >>> >>> On 11/28/2012 03:47 PM, Barry Smith wrote: >>>> From SNESDefaultConverged() >>>> >>>> else if (snorm < snes->stol*xnorm) { >>>> ierr = PetscInfo3(snes,"Converged due to small update length: %14.12e < %14.12e * %14.12e\n",(double)snorm,(double)snes->stol,(double)xnorm);CHKERRQ(ierr); >>>> *reason = SNES_CONVERGED_SNORM_RELATIVE; >>>> } >>>> >>>> I will fix the documentation >>>> >>>> On Nov 28, 2012, at 2:44 PM, Michael Povolotskyi <mpo...@pu...> wrote: >>>> >>>>> Hello Petsc developers, >>>>> I have a question about setting tolerances for SNES solver. I have found >>>>> 3 pieces of information that seem to contradict to each other: >>>>> >>>>> 1) >>>>> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/SNES/SNESSetTolerances.html >>>>> stol - convergence tolerance in terms of the norm of the >>>>> change in the solution between steps >>>>> >>>>> 2) >>>>> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/SNES/SNESConvergedReason.html >>>>> SNES_CONVERGED_SNORM_RELATIVE = 4, /* Newton computed step size >>>>> small; || delta x || < stol */ >>>>> >>>>> 3) http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/SNES/SNESDefaultConverged.html >>>>> <http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/SNES/SNES_CONVERGED_SNORM_RELATIVE.html#SNES_CONVERGED_SNORM_RELATIVE> SNES_CONVERGED_SNORM_RELATIVE - (snorm < stol*xnorm) >>>>> >>>>> My question is: >>>>> which criteria is used SNES solver of LS type: absolute, like in 1) and 2), or relative, like in 3) ? >>>>> Thank you, >>>>> Michael. >>>>> >>>>> >>>>> >>> >>> -- >>> Michael Povolotskyi, PhD >>> Research Assistant Professor >>> Network for Computational Nanotechnology >>> 207 S Martin Jischke Drive >>> Purdue University, DLR, room 441-10 >>> West Lafayette, Indiana 47907 >>> >>> phone: +1-765-494-9396 >>> fax: +1-765-496-6026 >>> > > > -- > Michael Povolotskyi, PhD > Research Assistant Professor > Network for Computational Nanotechnology > 207 S Martin Jischke Drive > Purdue University, DLR, room 441-10 > West Lafayette, Indiana 47907 > > phone: +1-765-494-9396 > fax: +1-765-496-6026 > |
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 |
From: Barry S. <bs...@mc...> - 2012-11-29 22:39:18
|
On Nov 29, 2012, at 3:59 PM, John Peterson <pet...@cf...> wrote: > 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? Yes. > > We could change this, but it might break backwards compatibility: some > users may not currently use relative_step_tolerance at all, etc. This tolerance is really a property of how many digits one has in PetscScalar so no really should really be setting it explicitly except under exceptional circumstances. Barry > > -- > 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 > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |