Johan Hake wrote:
> On Friday 08 May 2009 08:49:59 Garth N. Wells wrote:
>> 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.
>
> You mean one parameter dictionary per class or one per instance?
Per instance.
Garth
I have the
> same distinction in a Python application. Some places I need one per instance
> and other places it is more convinient to have one per class.
>
> In python I have a way to controll this dynamically. Not sure how this could
> be done in c++.
>
> Johan
>
>> 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
>
>
_______________________________________________
DOLFIN-dev mailing list
[email protected]
http://www.fenics.org/mailman/listinfo/dolfin-dev
