dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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

-- 
Anders

Attachment: signature.asc
Description: Digital signature