On Sep 18, 2008, at 2:33 AM, Jed Brown wrote: >> Exactly. > > Motivation to use Eisenstat-Walker?
Indeed - I used this option yesterday and it worked well for several of our problems. > If you set these *before* you call SNESSetFromOptions() then the > command > line options will be used if they are specified. This is the correct > way to change the defaults without clobbering the command line. Yep - thought about this while I was laying in bed last night... thanks for the confirmation. > By the way, you can see all the application defaults by running with > -help. For instance, this is for the Schur complement solver (in a > preconditioner). > > -schur_ksp_rtol <1e-05>: Relative decrease in residual norm > (KSPSetTolerances) Ah - great! I'll probably make the defaults match Petsc then. >>> 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. > > Really? I think the command line options are perhaps the single > greatest advantage to using PETSc. The functions to set solver > options > are really intended for cases where the application (problem-specific, > usually not discretization-specific) needs to adjust solver parameters > adaptively, for instance in your convergence test. > > It is not possible to provide a libmesh-specific options database that > is as powerful without knowing about every package that PETSc may be > built against. Do you really want libmesh to keep track of this? > > -snes_type tr -snes_tr_delta2 0.8 -snes_lag_preconditioner 3 > -snes_ksp_ew -snes_ksp_ew_threshold 0.15 -ksp_type ibcgs > -pc_type asm -pc_asm_overlap 2 -sub_pc_type hypre > -sub_pc_hypre_boomeramg_interp_type multipass-wts ... > > This is a slightly contrived example, but it should make the point > that > you can't hope to replicate this functionality. Making a common > interface to a few options might be useful, but they should really > only > be defaults and the PETSc command line options should have precedence. From a research perspective you are absolutely right. What you probably aren't considering is that some people (e.g. me) are trying to build commercial / production codes on top of libMesh / PetsC.... and from that standpoint you want to have complete control over the command-line. For instance, if I told any of our users that in order to use mult-grid preconditioning they had to to pass -sub_pc_type hypre on the command-line.... they would freak out. They want to be able to put "preconditioner = multigrid" in the input file and have it work (or even just "solve = true"! _OR_ select "multigrid" from a drop-down box in a GUI). Further, from an app developer standpoint, I don't want my users to be able to override internal capability by passing junk on the command-line... that sounds like a recipe for disaster. Now - how to make "preconditioner = multigrid" work inside of the application is where you get into trouble. We want to support both Trilinos and Petsc with our application... so you can freely switch back and forth between the two solver packages... and maybe even use some Trilinos packages with Petsc linear solvers (such as NOX). I know that at a certain level it doesn't make sense to have libMesh support _everything_ from Petsc and Trilinos with a common interface... so in order to handle some of the more exotic options transparently to our users we're going to have to do some #ifdef type gymnastics. But for things that _are_ really common (these tolerances for instance), I think it makes sense to provide an interface to those in libMesh itself. Anyway - not trying to be argumentative... just trying to give you some perspective about why I'm worrying about this right now. As always... thank you very much for your hints! 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
