dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

Johan Hake wrote:
> On Monday 30 November 2009 17:22:19 Garth N. Wells wrote:
>> Anders Logg wrote:
>>> On Mon, Nov 30, 2009 at 10:57:17PM +0000, Garth N. Wells wrote:
>>>> Johan Hake wrote:
>>>>> On Monday 30 November 2009 12:11:34 Anders Logg wrote:
>>>>>> On Sun, Nov 29, 2009 at 09:51:25PM +0000, Garth N. Wells wrote:
>>>>>>> Anders Logg wrote:
>>>>>>>> On Sat, Nov 28, 2009 at 11:26:07PM +0100, Anders Logg wrote:
>>>>>>>>> On Sat, Nov 28, 2009 at 11:23:58PM +0100, Anders Logg wrote:
>>>>>>>>>> On Sat, Nov 28, 2009 at 10:21:18PM +0000, Garth N. Wells wrote:
>>>>>>>>>>> Anders Logg wrote:
>>>>>>>>>>>> On Sat, Nov 28, 2009 at 09:32:03PM +0000, Garth N. Wells wrote:
>>>>>>>>>>>>> It would be good to make a release of DOLFIN/FFL/UFL next week
>>>>>>>>>>>>> with the new syntax for Constants and Expressions. Are there
>>>>>>>>>>>>> any pressing issues which need to be addressed before making a
>>>>>>>>>>>>> new release?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Garth
>>>>>>>>>>>> I agree. Let's make a release as soon as possible.
>>>>>>>>>>>>
>>>>>>>>>>>> The only things I see missing are
>>>>>>>>>>>>
>>>>>>>>>>>> 1. std::vector argument in eval. I see you've started on this.
>>>>>>>>>>>>
>>>>>>>>>>>> 2. Getting the buildbot running in on form or another.
>>>>>>>>>>> If we don't get this running in time, I'm happy if we run the
>>>>>>>>>>> tests by hand on a few OSes.
>>>>>>>>>> Me too.
>>>>>>>>>>
>>>>>>>>>>>> Andre Massing has prepared a major bundle on the CGAL stuff but
>>>>>>>>>>>> that can wait until after 0.9.5, but it would be good to do it
>>>>>>>>>>>> immediately after so we get that done.
>>>>>>>>>>> Perhaps he could publish it first as a personal branch on
>>>>>>>>>>> Launchpad?
>>>>>>>>>> Yes, it would be a good opportunity to test that feature.
>>>>>>>>>>
>>>>>>>>>> What do you think Andre? Could you give it a try?
>>>>>>>>> Another thing to figure out is the logic/algorithm for selecting
>>>>>>>>> coefficient element degrees.
>>>>>>>>>
>>>>>>>>> We have another thread going on this.
>>>>>>>> Another thing that we might want to fix in the new release is the
>>>>>>>> ability to do
>>>>>>>>
>>>>>>>>   return (foo, bar)
>>>>>>>>
>>>>>>>> instead of
>>>>>>>>
>>>>>>>>   values[0] = foo
>>>>>>>>   values[1] = bar
>>>>>>>>
>>>>>>>> in the Expression class in Python.
>>>>>>>>
>>>>>>>> Johan hinted that it would be possible to implement this.
>>>>>>>>
>>>>>>>> On the other hand, one can argue that the simplified Expression
>>>>>>>> interface (using C++ string expressions) is already simple enough
>>>>>>>> for simple cases and that one should need to assign to values when
>>>>>>>> subclassing Expression to make it consistent with the C++ interface.
>>>>>>>>
>>>>>>>> Opinions?
>>>>>>> I like to keep the consistency with C++, plus Expressions which
>>>>>>> demand a subclass in place of JIT are usually reasonably complicated,
>>>>>>> so it may in practice be more like
>>>>>>>
>>>>>>>   return (............................................,
>>>>>>> ......................................)
>>>>>> Agreed. Let's keep the eval interface as is.
>>>>>>
>>>>>> What remains before a release? I can see these two:
>>>>>>
>>>>>> 1. Getting the la unit tests (get_row) working. Are you working on
>>>>>> this Johan?
>>>>> Yes.
>>>>>
>>>>> At least the amount of time I feel correct using on it. It is a bit
>>>>> more nasty than I first anticipated. But I have good hope!
>>>> Would these difficulties be resolved if we use the native SWIG wrappers
>>>> for std::vector instead of homemade versions case-by-case? I know that
>>>> the SWIG std::vector wrapper was removed to reduce the size of the
>>>> wrapper code, but perhaps the same could be achieved by using more
>>>> %ignore?
>>>>
>>>> Garth
>>> If the built-in wrappers work, I suggest we use them instead of the
>>> our homemade versions even if the code increases if that makes the
>>> wrapper code easier to maintain.
>> I've had a look at this. Using the SWIG wrappers I've deleted tons of
>> our complicated wrapper code, and things that didn't work now do
>> automatically. I'll push a first go soon.
> 
> I'am not at all satisfied with this change. I would have hoped that you at 
> least could wait for my response on this issue, as the amount of hours of both 
> payed and free time, I have put down on the code is quite large. I do not want 
> to be grumpy, but I think the point is legitimate, as DOLFIN is a community 
> project, and this change really turned me off.
>

That's what we have 'bzr revert' for. ;) Fell free to change it back if
you have a manageable solution.

> I see your point of having a manageable SWIG interface. It's a strong one. 
> However the lack of compatibility with NumPy still exists. 
> 

Maintainability has to be the overriding consideration. I have spent a
lot of time trying (and sometimes occasionally succeeding) to make just
small updates and changes. The time required is not sustainable. Also,
the difficulty of working with the SWIG interface will make it near
impossible to engage new contributors/maintainers.

> NumPy is the natural choice when one want to use contiguous arrays back and 
> forth to Python. I would say that a strong design goal is to have a Python 
> interface that works smoothly with NumPy, which neither std::vector nor 
> std_vector.i do.
> 

Is there a fundamental reason why std::vector and can't NumPy play well
together? Since vectors use contiguous arrays, sounds to me like there
is scope for adding a numpy.i file to SWIG.

It would be nice to have the NumPy integration, but the typemaps are too
complicated for us mere mortals.

> A better solution, in my point, would either be to stay with double/uint * for 
> the communication of contiguous arrays, or to add a light weight wrapped class 
> in C++ for these data structures.
>

>From the C++ side, I would like to see plain pointers removed from the
user interface.

Garth

> Johan
> 
>> Garth
>>
>>> --
>>> Anders