| Thread Previous • Date Previous • Date Next • Thread Next |
Johan Hake wrote:
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 ofthe 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.
It would help me understand what to do on the C++ side if I knew what the Python would/should look like. In C++ we can do
// We know that u0 will share the data because of the reference Function& u0_ref = u[0]; // We know that u0 will be a copy because there is no reference Function u0_copy = u[0]; What's the plan to distinguish the two cases in Python? Garth
JohanI don't really understand how things work on the Python side for Functions, so I'm clutching at straws.GarthIt would be neat if we could somehow make member functions 'private' to PyDOLFIN.We can, just rename them in dolfin_function_pre.i %rename (_foo) dolfin::Function::foo; We do this for some of the functions (_sub: operator[] and _in for in) already.I meant C++ member functions which are intended for use through PyDOLFIN only.I see :) We could hide some python specific classes, like the DiscreteFunction class, by not including it in dolfin_function.h, and then manually add it to dolfin_headers.i. With this we hide it from #include <dolfin.h> We then have to manually add them as #includes in dolfin.i and to dolfin_headers.i. We can automate this by adding a dolfin_pydolfin_headers.i, which lists the #includes. This file is then parsed by generate.py. If this sounds reasonable I can look into it. JohanGarth
| Thread Previous • Date Previous • Date Next • Thread Next |
