← Back to team overview

dolfin team mailing list archive

Re: Parameter system

 



Johan Hake wrote:
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.

Agree.

Garth

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
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev




References