dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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.

Should we call the new class Options or Parameters?

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

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.

-- 
Anders

Attachment: signature.asc
Description: Digital signature