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 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
