dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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? 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?

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.

-- 
Anders

Attachment: signature.asc
Description: Digital signature