dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

Anders Logg wrote:
> On Sun, May 24, 2009 at 09:08:24PM +0200, Johan Hake wrote:
> > On Sunday 24 May 2009 17:08:59 Anders Logg wrote:
> > > On Sun, May 24, 2009 at 03:42:21PM +0100, Garth N. Wells wrote:
> > > > Will it still be possible to use PETSc command-line options?
> > > >
> > > > Garth
> > > No, an error is given for any parameter that is not in the parameter
> > > database.
> > >
> > > I suggest we prefix PETSc options with "petsc." and make a special
> > > treatment of those: not checking that the options are valid and
> > > stripping them of the "petsc." prefix before sending them to PETSc.
> > Not sure this will work, as we need to parse the PETSc options before we know 
> > anything about any Parameters, right? 
>
> This touches on something we really haven't decided. Should we have a
> mechanism for global parameters? 

Yes.

The old parameter system allowed
> global parameters, but the new parameter system does not. It would be
> fairly easy to add (a singleton NewParameters object).
>
> An important example of a global parameter would be "linear algebra
> backend".
>
> If we allow global parameters, we need to provide a function that
> parses argc, argv and reads global DOLFIN parameters as well as
> passing all petsc.foo parameters to PETSc.
>
> > At:
> >   
> > <http://www.boost.org/doc/libs/1_37_0/doc/html/boost/program_options/basic_command_line_parser.html>
> >
> > I see that we can create a basic_command_line_parser, which we can specify to 
> >
> >    allow_unregistered()
> >
> > This is pretty self explainatory, however we are also allowed to check which 
> > unregistered options that were passed. 
>
> How about checking for unregistered options and report those (printing
> a summary of which options were not recognized by DOLFIN).
>
> > In an IFDEF HAS_PETSc we can add all possible options in PETSc (and SLEPc) and 
> > check if the unregistered options are one of these, if not we can throw an 
> > error. Should we keep a global such list so other component can add such 
> > parameters?

PETSc has tons of options, so this isn't feasible.

> We could, but it sounds difficult to get a complete list of PETSc
> options and keeping it updated (if it's not very static which I don't
> really know). I suggest just sending anything prefixed with "petsc."
> to PETSc and then let PETSc worry about the options.

That should be ok. PETSc prints messages on unknown and unused parameters.

Garth


> ------------------------------------------------------------------------
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev