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
> [email protected]
> http://www.fenics.org/mailman/listinfo/dolfin-dev
_______________________________________________
DOLFIN-dev mailing list
[email protected]
http://www.fenics.org/mailman/listinfo/dolfin-dev
