dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, May 24, 2009 at 11:03:24PM +0200, Johan Hake wrote:
> 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. 

Good suggestions. Having a "dolfin." prefix makes it clear it's a
global parameter for DOLFIN and the dolfin_init() is already there to
be used.

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

Yes, sounds good.

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

Yes, sounds good.

-- 
Anders


> > >> 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
> 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev

Attachment: signature.asc
Description: Digital signature