On Thu, Sep 18, 2008 at 3:25 PM, Roy Stogner <roystgnr@...> wrote:
> Also, and this is a completely irrelevant remark that may lower the IQ
> of anyone who reads it: Doesn't the singular noun with misconjugated
> verb, "LIBMESH_HAVE_", make our config code now sound just a little
> like it was written by cavemen?
LIBMESH_MAKE_FIRE
--
John

On Wed, 17 Sep 2008, Benjamin Kirk wrote:
> I am about to check in a substantial change set that prefixes every variable
> in include/base/libmesh_config.h with LIBMESH_ to avoid conflicts with
> external packages.
I'm copying this to libmesh-users to make sure everyone sees it. As I
just discovered when getting back to some of my old code, this macro
change can be more sneaky than an API renaming at the symbol level: at
least when a symbol name changes, you notice when it doesn't compile,
and you fix it. With these macro name changes, the effect to some of
my code was to silently disable features when the application didn't
think "HAVE_*" was defined.
Also, and this is a completely irrelevant remark that may lower the IQ
of anyone who reads it: Doesn't the singular noun with misconjugated
verb, "LIBMESH_HAVE_", make our config code now sound just a little
like it was written by cavemen?
---
Roy

Jed Brown wrote:
>> On Wed, 17 Sep 2008, Derek Gaston wrote:
>>> 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.).
>
> 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.
This is also how we're doing things in petsc_linear_solver.C, it looks
like; it shouldn't be any harder to do for the nonlinear solvers.
---
Roy

On Thu 2008-09-18 07:57, Derek Gaston wrote:
> 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.
Ah, that makes more sense. I was just worried that the command line
would become crippled for the rest of us.
> 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.
Well, that is actually serial AMG as the local preconditioner inside a
Schwarz domain decomposition preconditioner.
> 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.
Right, why not think about these settings in your input file or GUI as
`defaults' to the backend? That is what setting options before
XXXSetFromOptions() does as far as PETSc is concerned. Then you can
just require a switch to pass command line to PETSc. For instance
mpirun -n 8 app -app_opt_1 -app_opt_2 +PETSc -pc_type hypre ...
would make it quite clear that they are bypassing your front end and
sending certain options to PETSc. The GHC (Haskell) runtime does
something similar:
./myapp -options -managed_by_my_app +RTS -ghc -runtime_options -RTS
-another_app_option
where the options between +RTS and -RTS can be used to manipulate the
garbage collector and other very internal things. All programs compiled
with GHC can be manipulated this way, but it doesn't cause a usability
issue.
Everything which is backend-agnostic would be managed by your
app/libmesh. Also, I assume you are aware of PetscOptionsInsertFile()
(-options_file).
This could all be implemented as a derived class of LibMeshInit.
Jed

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

On Wed 2008-09-17 16:10, Roy Stogner wrote:
>
> On Wed, 17 Sep 2008, Derek Gaston wrote:
>
> > This causes some trouble during non-linear solves as you end up
> > _way_ over solving the initial non-linear steps
>
> Exactly.
Motivation to use Eisenstat-Walker?
> > 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.).
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.
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)
I have not changed the default so it shows the PETSc default relative
tolerance. If my program had changed the value to 1e-03 (using
KSPSetTolerances()) then it would show <1e-03>, but the command line
would still have priority.
> > 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.
My $.02
Jed