dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Sunday 24 May 2009 21:31:22 Garth N. Wells wrote:
> 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.

Agree.

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

Should these parameters be prefixed dolfin, e.g., --dolfin.la_backend, and 
where should them be parsed? In a dolfin_init() or at the same time as any 
user defined parameters. I vote for the first. 

When we do such a parsing we could also check for any local or system wide 
parameter file.

I also think that we in such a function only should issue errors on parameters 
prefixed with e.g., dolfin, so we do not get a pile of errors for the PETSc 
and other userdefined parameters.

> >> At:
> >>
> >> <http://www.boost.org/doc/libs/1_37_0/doc/html/boost/program_options/bas
> >>ic_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).

Yes but not too many false negative, i.e, see comment above.

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

Ok.

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

Ok, so we then need to add some manual parsing of options that starts with 
petsc, in the initPETSc function?

Johan

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