dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

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.

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

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.

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.

Johan

> Garth
> 
> > --
> > Anders
>