On Monday 24 August 2009 13:04:45 Garth N. Wells wrote:
Johan Hake wrote:
On Monday 24 August 2009 10:30:52 Garth N. Wells wrote:
Johan Hake wrote:
On Monday 24 August 2009 10:11:49 Garth N. Wells wrote:
dolfin/swig/dolfin_headers.i description: Work on new sub
Function logic.
I am not sure we can completely wrap the new logic to
PyDOLFIN.
To be able to have the double inheritance of cpp.Function and
ufl.Function in PyDOLFIN, new Functions have to be
constructed in the Python interface (function.py).
The operator[] is mapped to a hidden function _sub. The
created Function that is returned from this is passed to the
copy constructor in the Python version of sub (creating a new
Function object). This is basically just how we did it before
the new design, because previously operator[] returned a
SubFunctionData, which was passed to a Function constructor.
The transition to the new logic works in PyDOLFIN because the
Function copy constructor is used instead of the removed
SubFunctionData constructor.
This means that the handy operator[], which returns a
Function with a shared vector, cannot fully be used from
PyDOLFIN. Would it be possible to add a shallow copy function
in some way. Would this work with the present SubFunction
design?
Would something like
Function::sub_function(Function& sub_function, uint i)
Yes I think so. If we could make this a constructor (shallow
copy constructor) I would be most happy!
So a constructor
Function::Function(uint i)
would be better?
Yes, but then we could not fetch the shared Vector?
I'm reluctant to add a constructor since it breaks the
paradigm that a Function constructor gives a deep copy.
Ok.
Could you create
an empty Function internally on the PyDOLFIN side and then pass
it to
Function::sub_function(Function& sub_function, uint i)
to attach the shared data to create the sub-Function
'sub_function'?
Yes, this should be fine. I guess such a function will then just
destroy any present vector and exchange it with the one shared
with the FullFunction?
Yes. We can throw an error if there is any data already attached
to the Function.
When we create a new Function in PyDOLFIN using the
DiscreteFunction, we do create a vector, so this will prevent us
using this class. We use the DiscreteFunction to circumvent some
director (SWIG stuff to be able to inherit a cpp.Function in
Python) overhead wrt to call the eval function during assemble. I
guess we will not assemble the function returned from operator[] so
then we can create the Function using cpp.Function instead.
What if we add a constructor to DiscreteFunction to take care of
sub-functions? Would that work?
Yes, this should work. Then we could add a constructor taking a
Function and a number as you suggested above.
This is trickier than I anticipated. The problem with
Function::Function(const Function& v, uint i)
is that v cannot be const since v keeps track of its sub-functions and
create and stores them on-demand. I could just create a sub-function
and not cache it, but then it would be re-created every time. The
problem with this is that creating a sub-dof map is not trivial if the
dof map has been renumbered.
I'm also a bit uncomfortable with shallow copies because bad things
can happen when something goes out of scope.
If we make _vector protected, we should be able to handle everything in
something like:
DiscreteFunction::DiscreteFunction(Function& v, uint i)
Here we just let the new DiscreteFunction share both _vector and
_function_space. Maybe this was what you did not like?
Could this be taken care of on the Python side by introducing
something like a SubFunction? Function::operator[] returns a
reference, and PyDOLFIN could take are of things through the
assignment operators of the Python Function and SubFunction classes?
This is exactly what happens now (if I understand your suggestion
correctly :) ) and this is probably why the new SubFunction design just
works in PyDOLFIN now. The thing is that we make a deep copy. The
sharing of data we get from operator[] is lost. This might not be a big
problem.
