On Wed, 17 Sep 2008, Derek Gaston wrote:
> On Sep 17, 2008, at 3:10 PM, Roy Stogner wrote: >> 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... Yeah, oxymorons don't quite pass my "non-confusing" criterion. ;-) "nonlinear solver initial linear tolerance", "nonlinear solver linear maximum iterations"? Still confusing, and I'm open to better ideas, but at least this way the contradictory adjectives are being applied to *different* nouns. >>> 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. That's fine for PETSc as long as the "something else" is consistent, but I'd like us to be consistent too, and it's too much to hope that Trilinos' default tolerances and PETSc's default tolerances are going to be the same. >> 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? That's actually not a bad argument. And the PETSc nonlinear solver interface is new enough that I wouldn't worry about breaking backwards compatibility with its users. On the other hand, if we want to do things pedantically *right*, you haven't just argued that the PETSc nonlinear solver interface shouldn't be changed to avoid overriding command line arguments, you've argued that the PETSc linear solver interface *should* be changed to avoid that. If you're feeling lazy, though, it's not a big deal. We'll just hope that anyone who's bothered by their command line tolerance options being ignored will be bothered enough to send us a patch. --- 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
