dolfin team mailing list archive

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

Johan Hake wrote:
> On Tuesday 01 December 2009 11:21:00 Garth N. Wells wrote:
>> Johan Hake wrote:
>>> On Tuesday 01 December 2009 11:06:43 you wrote:
>>>> Anders Logg wrote:
>>>>> On Tue, Dec 01, 2009 at 09:59:18AM -0800, Johan Hake wrote:
>>>>>> On Tuesday 01 December 2009 00:45:50 Anders Logg wrote:
>>>>>>> Would it help to add a new class on the C++ side that is used only
>>>>>>> for passing array data back and forth between C++ and Python? We have
>>>>>>> had this before (SimpleArray) and it would be fairly easy to extend
>>>>>>> the C++ with extra functions in the interface that use SimpleArray
>>>>>>> instead of std::vector.
>>>>>>>
>>>>>>> Then perhaps we can have one single typemap that hits SimpleArray
>>>>>>> everywhere and converts it to a NumPy array.
>>>>>> Yes, something in that direction is what I had in mind. In addition we
>>>>>> could also add a foo.array() function to get a NumPy view from this
>>>>>> class. This would be nice when we do not want to have all the
>>>>>> communication through typemaps, but actually using the SimpleArray in
>>>>>> Python as return argument from some function that wants to resize the
>>>>>> array.
>>>>>>
>>>>>> We would also need some stuff to handle memory management.
>>>>>>
>>>>>> I see two fundamental ways such a class could be used:
>>>>>>   1) A replacement for the previous use of double/uint/int*, now
>>>>>> std::vector 2) A replacement for communication using std::vector where
>>>>>> resize flexibility is needed.
>>>>>>
>>>>>> I think 1, speaks for it self. 2 is where we need to resize any passed
>>>>>> vector. This goes for GenericMatrix.getrow, foo.intersection,
>>>>>> GenericFunction.comput_vertex_values.
>>>>>>
>>>>>>> And the work would be to add the extra stuff on the C++ side. The
>>>>>>> advantage would be less complex wrapper code and that Garth and I
>>>>>>> are capable of handling the complexities on the C++ side.
>>>>>> Yes this must be a goal. I agree that the present SWIG situation has
>>>>>> grown out of hands.
>>>>>>
>>>>>>> But what I don't understand is why it would be easier to write a
>>>>>>> typemap for SimpleArray than for std::vector. Both of them use
>>>>>>> contiguous memory.
>>>>>> Yes, but in std::vector it is now way, I suppose, to prevent a vector
>>>>>> to delete its data when it goes out of scope. This is necessary in a
>>>>>> typical in typemap.
>>>>> ok, let's create a very flexible array class that is targeted at
>>>>> simple communication between C++ and Python/NumPy. We had a class
>>>>> before named SimpleArray. We might call it NumPyArray or PythonArray.
>>>> Can we just call it Array? It will be visible in the C++ interface (e.g.
>>>> in eval) so it would be good to have a nice name.
>>> Agree.
>>>
>>>>> I have created a blueprint:
>>>>>
>>>>> https://blueprints.launchpad.net/dolfin/+spec/array-typemaps
>>>> I'll add something. I was thinking already about this. With a smart
>>>> pointer to the underlying data we should be to devise an elegant memory
>>>> model and be able to tell an Array object when it does and doesn't own
>>>> the data upon construction, and be able to change during execution.
>>> Sounds fancy.
>>>
>>>>> We can fill out the details together.
>>>>>
>>>>>> I will fix the interface of getrow this evening. I was about to do it
>>>>>> yesterday, but instead I got grumpy :) But a good night sleep makes
>>>>>> wonders!
>>>>> Good! :-)
>>>>>
>>>>> Will you make a fast/temporary fix so that we can get ready for a
>>>>> release of 0.9.5 and then we can move the PythonArray implementation
>>>>> to a future release?
>>>> The fast fix would be revert back to the
>>>>
>>>>     eval(double*, std::vector<double>&)
>>>>
>>>> interface. No point wasting time on typemaps for std::vector if we're
>>>> not going to use them.
>>> Fell free to make this change, I have a fool proof plan for the other
>>> temporary fix though. No new typemaps, just reusing old ones.
>> OK, we need to make a decision.
>>
>> Option 1: Revert changes to eval.
>>
>> Option 2: Get SWIG working with the eval(std::vector<double>&, const
>> std::vector<double>&) interface.
>>
>> What's it going to be? I'm inclined to Option 1 since it requires no
>> work and it's been well tested.
> 
> Isn't the amount of files that are touched with option 1 much larger (all 
> cpp/demos)? 

Yes, but it's easy. I can just selectively revert files.

But if you do the changes feel free. I can take a look at it this
> evening if there's something left to do. The new expression.py should at least 
> still be working I think, only compile_expressions.py needs an update.
> 

Yes.

Perhaps you could push your std:vector work to a branch so we have a
record of it and don't go re-inventing the wheel in the future.

Garth

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