dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #13367
Re: Parameter system
On Thursday 07 May 2009 23:16:54 Anders Logg wrote:
> On Thu, May 07, 2009 at 11:05:49PM +0200, 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.
>
> How would that work? Inheritance now provides get/set functions for
> subclasses making it possible to do
>
> solver.set("tolerance", 0.1);
Not sure what you ask for here. I know of Parametrized and I agree that the
above syntax is nice. But I prefer to keep the parameters in its own object
and just operate on that. These can then be collected into one "dict/map" and
then form the parameters of an application. This is also easier to wrap to
python.
The shared_ptr argument might not be so relevant as the potential parametrized
classes may not be declared as shared_ptr classes in the swig interface
anyway. However if that will be the case we must declare Parametrized as a
shared_ptr class in swig and then we must declare all Parametrized sub
classes as shared_ptr...
> > 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;
>
> It would need to be
>
> ParameterDict& p = solver.default_params();
Sure :P
> and I'd suggest naming it Parameters:
>
> Parameters& p = solver.parameters();
Fine.
> > 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.
>
> I think we can also solve this without excessive templating... ;-)
Good!
> > 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++.
>
> What exactly is needed from the Python side? I think I can make a
> fairly simple implementation of this in C++ using a minimal amount of
> templates with simple syntax.
Using operator[] to get and set parameters can straightforwardly be mapped to
python, and we can then also implement the map/dict protocol on top of that.
Other get and set methods can also be used, however set is a built in type in
Python and not a good alternative.
> Is the main difference that instead of inheriting Parametrized, a
> subclass needs to implement a method named parameters() which returns
> the parameter "dictionary"?
Yes.
Johan
Follow ups
References