dolfin team mailing list archive

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

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

> 
> Johan
> 
>> 2. The strategy for selecting degree in FFC. Please comment on this
>> (in another thread I just opened).
>>
>> 3. ?
>>
>> --
>> Anders
>>