dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Friday 08 May 2009 09:03:34 Anders Logg wrote:
> On Fri, May 08, 2009 at 08:42:33AM +0200, Johan Hake wrote:
> > On Thursday 07 May 2009 23:20:20 Anders Logg wrote:
> > > On Thu, May 07, 2009 at 10:14:20PM +0100, Garth N. Wells wrote:
> > > > Johan Hake wrote:
> > > > > On Thursday 07 May 2009 18:54:04 Anders Logg wrote:
> > > > >> I've added some of the requested features to the parameter system,
> > > > >> some pushed and some sitting here in a local repository. But the
> > > > >> current design makes it a pain to add new features. A single
> > > > >> change will make it necessary to add a function in at least 5
> > > > >> different classes.
> > > > >>
> > > > >> So I'm thinking of reimplementing and simplifying the parameter
> > > > >> system. I think I know how to make it simpler.
> > > > >>
> > > > >> But before I do that, does anyone have opinions on the
> > > > >> design/implementation? Is there any third-party library that we
> > > > >> could/should use (maybe something in boost)?
> > > > >
> > > > > It would be nice to have something that easely could be
> > > > > transferable to Python.
> > > > >
> > > > > Having a base class let say Parameterized and then let all inherit
> > > > > this to be able to define parameters will not work well for the
> > > > > shared_ptr interface we have. We have problems with the Variable
> > > > > class, which does not work for the derived shared_ptr classes e.g.
> > > > > Function. I would rather have classes that have a parameter rather
> > > > > than beeing.
> > > > >
> > > > > Also by defining a parameter(list/dict) class which can be accessed
> > > > > as a dict let us make the transition to python smoother.
> > > > >
> > > > >    ParameterDict p = solver.default_params();
> > > > >    p["abs_tol"] = 1e-9;
> > > > >
> > > > > By defining some templated check classes we could controll the
> > > > > assignment. In the Solver:
> > > > >    ...
> > > > >    ParameterDict& default_params(){
> > > > >       if (!_par)
> > > > >       {
> > > > >          _par = new ParameterDict();
> > > > >          _par->add_param("abs_tol",new
> > > > > RangeCheck<double>(1e-15,0,1)); vector<string> * allowed_prec = new
> > > > > Vector<string>(); allowed_prec->push_back("ilu");
> > > > >          allowed_prec->push_back("amg");
> > > > >          allowed_prec->push_back("jacobi");
> > > > >          _par->add_param("prec",new
> > > > > OptionCheck<string>("ilu"),allowed_prec));
> > > > > _par->add_param("nonsense","jada"); // No checks
> > > > >       }
> > > > >    }
> > > > >
> > > > > Well, I admit that the above code is not beautiful, and others can
> > > > > probably make it cleaner and spot errors. The point is that
> > > > > RangeCheck and OptionCheck can be derived from a ParCheck class
> > > > > that overloads the operator=(). This will just call a private set
> > > > > function which is defined in the derived classes, and which do the
> > > > > check.
> > > > >
> > > > > The to and from file can be implemented in the ParameterDict body.
> > > > > The checks do not have to be written or read, as a ParameterDict
> > > > > can only read in allready predefined parameters, and the check will
> > > > > be done when the file is read.
> > > > >
> > > > > The option parser ability can also be implemented in ParameterDict
> > > > > using boost or other libraries, based on the registered parameters.
> > > > >
> > > > > I have implemented something like this in Python, and the above is
> > > > > a try to scetch something similare in c++.
> > > >
> > > > At a glance, the above looks like Boost Pogram_options,
> >
> > Does po support nested options?
> >
> >   ...
> >   Parameters app_params;
> >   app_params.add_param("solver",solver.parameters());
> >   app_params.add_param("geometry",geometry.parameters());
> >   ...
> >   app_params["solver"]["abs_tol"] = 1e-9;
> >
> > (Btw I think this is close to how Trilinos does it. )
> >
> > If po do not support this we need to declare all application parameters
> > at one place and then pass this object around to the different dolfin
> > objects.
>
> I think this will be fairly easy to add in the wrapper code. Doesn't
> look like po supports it. But it does support merging of options from
> different sources.

Ok.

> Should we call the new class Options or Parameters?

Parameters. 

An Option is a Parameter, but a Parameter is not always an Option :)

> > > > http://www.boost.org/doc/libs/1_39_0/doc/html/program_options/tutoria
> > > >l.ht ml
> > > >
> > > > A nice feature of Boost Program_options is that it supports options
> > > > from a file and from the command line.
> > > >
> > > > Garth
> > >
> > > There are several options:
> > >
> > > 1. Using po just for parsing command-line options and perhaps reading
> > > from file (we can already read from XML).
> > >
> > > 2. Using po also for storing the values.
> > >
> > > 3. Not using po at all and store everything in simple std::<map,
> > > value>.
> >
> > I go for 1. However my knowledge of po is limited. I see that boost
> > defines its own map structure:
> >
> > <http://www.boost.org/doc/libs/1_39_0/doc/html/boost/program_options/vari
> >ables_map.html>
> >
> > which might be useful, but I suppose that's just for storing. I am not
> > sure po defines an interface for range and option checking either.
>
> It doesn't look like po sypports range checks. That will make it
> difficult to use po for storage, or rather making it easier to
> implement our own storage scheme since we may then make range checks
> part of the storage.

Sounds reasonable.

Johan