Sooooo... I've implemented the ability to set all those non-linear solver tolerances... but now I'm left wondering what to do with defaults and command-line options.
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). This causes some trouble during non-linear solves as you end up _way_ over solving the initial non-linear steps (which in our case actually leads to non-convergence in some cases). 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? 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. Any other ideas? 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 ;-) The other issue is that even though the convergence test command-line options aren't going to work any longer... you're still going to have to use some of the other Petsc command-line options (such as - ksp_monitor) as there's no programmatic interface for those (yet?). So this sends a conflicting message... although I suppose it's the same message that we've been sending on the linear solver side for some time now. What do you guys think about all this? Derek ------------------------------------------------------------------------- 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
