Anders Logg wrote:
> On Fri, May 08, 2009 at 08:12:35AM +0200, Johan Hake wrote:
>> 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.
>
> ok, I'll try this. I'll add a sketch of a new class using as much of
> po as seems reasonable and then you could have a look before I proceed.
>
Will there be just one parameter dictionary, or will objects have their
own? I'm thinking of cases like when a program uses two Krylov solvers
but may use different tolerances for each one.
Garth
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
