dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

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.

> > http://www.boost.org/doc/libs/1_39_0/doc/html/program_options/tutorial.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/variables_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.


Johan