On Sep 17, 2008, at 3:10 PM, Roy Stogner wrote: >> (which in our case actually leads to non-convergence in some cases). > > Really? Then they're doing it wrong.
Well... it doesn't lead to divergence... it's just that we have some highly non-linear problems that if you oversolve the first couple of non-linear steps it then takes forever to converge. Don't really know how else to explain it. It could have something to do with lack of back-tracking in Petsc SNES (as far as I know). >> 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. "nonlinear linear solver tolerance" "nonlinear linear solver maximum iterations" etc... ???? >> 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". ;-) It should be noted that this is essentially what Petsc does itself. PETSC_DEFAULT is #defined to be -2... and if you pass that into any of the tolerance functions then it does something else. > 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. Sigh. I was hoping you weren't going to say that. That's not going to be much fun at all, but I can't really find an argument against doing it. Like I mentioned earlier though... we don't allow setting KSP tolerances for pure linear solves on the command-line right now... so why should we allow setting SNES tolerances? 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
