[petsc-dev] SNESConvergedDefault() side effect?

Dmitry Karpeyev karpeev at mcs.anl.gov
Wed Jul 24 13:26:27 CDT 2013


It appears that SNESConvergedDefault() sets snes->ttol here
https://bitbucket.org/petsc/petsc/src/40bc6eb114e6a8e7f27fd216b5c1226efddf337a/src/snes/interface/snesut.c?at=master#cl-462

That should be harmless, albeit unnecessary, since snes->ttol is also set
at the beginning of the solve in SNESSolve_NEWTONLS() (and other
SNESSolve_XXX) right before calling the convergence test:
https://bitbucket.org/petsc/petsc/src/40bc6eb114e6a8e7f27fd216b5c1226efddf337a/src/snes/impls/ls/ls.c?at=master#cl-202


However, this might make for some fragile code and may confuse the user
modeling a custom convergence test on SNESConvergedDefault().  In
particular, a local reading of SNESConvergedDefault() creates the
impression that it is the convergence monitor that is responsible for
setting snes->ttol on the zeroth iteration -- snes->ttol is used outside of
SNES, for example,  in one of the variants of the EW code (maybe only
there).  That would require access to SNES internals by user code.

More generally, should this sort of thing be handled everywhere using
snes->norm_init for consistency and to prevent potential breakage?
At the very least, should snes->ttol = ... be removed from
SNESConvergedDefault()?
Thanks.
Dmitry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130724/cbc919a3/attachment.html>


More information about the petsc-dev mailing list