Re: [Libmesh-devel] Tolerance Defaults

[Roy S. <roy...@ic...>]

On Wed, 17 Sep 2008, Derek Gaston wrote:

> It looks like for the linear solver tolerances there are defaults
> specified in equation_systems.C.  Similarly I have defined defaults
> for all the non-linear tolerances.  The trouble is that TOLERANCE *
> TOLERANCE for "linear solve tolerance" is quite a bit more strict than
> the default Petsc SNES linear solve tolerance (although I can't find
> what the default is... it appears to be around 1e-5 or so).

TOLERANCE * TOLERANCE is a good default for a nonlinear solve
tolerance; definitely not a good default for the linear tolerance in a
first inexact Newton step.

> This causes some trouble during non-linear solves as you end up
> _way_ over solving the initial non-linear steps

Exactly.

> (which in our case actually leads to non-convergence in some cases).

Really?  Then they're doing it wrong.

> But, it could be said that that's not really a problem... people
> should just always define their own tolerances... but it would be
> nice to have sane defaults.  What do you guys propose we do here?

Are we reusing the same parameter name for the total tolerance on a
linear problem and for the initial linear tolerance on a nonlinear
problem?  That's what's wrong; sorry I didn't catch it when you listed
things out before.  We need two separate names for these; if anything,
the linear residual reduction tolerances on a linear problem should
correspond to the nonlinear residual reduction tolerances on a
nonlinear problem.

I'm not sure how to rename things to reflect that in a non-confusing
way, though.

> One option is to set all the default values to something negative...
> and then in the solvers themselves (like PetscNonlinearSolver) detect
> that no tolerance has been specified and use PETSC_DEFAULT... but
> that's kinda ugly.

Where by "kinda" you mean "very".  ;-)

> Another problem is with setting command-line options... I'm calling
> KSPSetTolerances and SNESSetTolerances now... using the values
> specified in the equation systems parameters.  It appears that those
> values override any command-line options (such as -ksp_rtol or -
> snes_atol, etc.).  In and of itself this isn't really a problem...
> it's always been something of a hack that we allow you to pass Petsc
> command-line options to control Petsc.  The trouble is, I have a
> feeling that quite a few people are depending upon this working.  The
> moment I commit this code, anyone using PetscNonlineSolver and setting
> convergence criteria via the command-line (which is _everyone_ using
> PetscNonlinearSolver since before now there hasn't been any other way
> to set these options beyond making Petsc calls yourself) is going to
> be impacted.  I hope that that set of people is pretty low... and
> hopefully they are subscribed to libmesh-users ;-)

Can't we test the command line ourselves for the existance of PETSc
options and then choose not to override them if they've been specified
there?  I do think that the command line options are a hack, but
they're a very convenient and justifiably popular hack, and if they
are used they should definitely override anything that's hardcoded in
the library.
---
Roy