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: > >> Johan Hake wrote: > >>> On Monday 24 August 2009 09:56:55 Garth N. Wells wrote: > >>>> Johan Hake wrote: > >>>>> On Monday 24 August 2009 09:08:49 Garth N. Wells wrote: > >>>>>> Johan Hake wrote: > >>>>>>> On Saturday 22 August 2009 14:02:06 DOLFIN wrote: > >>>>>>>> One or more new changesets pushed to the primary dolfin > >>>>>>>> repository. A short summary of the last three changesets is > >>>>>>>> included below. > >>>>>>>> > >>>>>>>> changeset: 6833:30ddf63b8a1e25a6234703f1d47736ab90602376 > >>>>>>>> tag: tip > >>>>>>>> user: "Garth N. Wells <[email protected]>" > >>>>>>>> date: Sat Aug 22 12:03:42 2009 +0100 > >>>>>>>> files: dolfin/fem/VariationalProblem.cpp > >>>>>>>> dolfin/function/Function.cpp dolfin/function/Function.h > >>>>>>>> dolfin/function/SpecialFunctions.h > >>>>>>>> dolfin/function/SubFunctionData.h > >>>>>>>> dolfin/function/dolfin_function.h dolfin/swig/dolfin_docstrings.i > >>>>>>>> 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. > >> It 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. Johan > Garth > > > I guess we do not have to do this for all member functions? > > > > johan > > > >> Garth > >> > >>> Johan > >>> > >>>> Garth > >>>> > >>>>> Johan > >>>>> > >>>>>> work? > >>>>>> > >>>>>> Garth > >>>>>> > >>>>>>> Johan > >>>>>>> > >>>>>>>> The new logic is more consistent with conventions. > >>>>>>>> Function::operator[](uint i) now returns a reference to the sub > >>>>>>>> Function. A Function keeps track of its sub Functions. Therefore, > >>>>>>>> > >>>>>>>> Function& u0 = u[0]; > >>>>>>>> > >>>>>>>> and > >>>>>>>> > >>>>>>>> plot(u[0]); > >>>>>>>> > >>>>>>>> do not involve copying a vector. u and u0 share the same vector. > >>>>>>>> If a DofMap is renumbered after construction, the Function can > >>>>>>>> make sure that all its sub Functions are modified accordingly. > >>>>>>>> Likewise if the mesh is refined. > >>>>>>>> > >>>>>>>> Assignment makes a deep copy, i.e. you will get a new copy of > >>>>>>>> everything. Therefore with > >>>>>>>> > >>>>>>>> Function u0 = u[0]; > >>>>>>>> > >>>>>>>> a new vector will be created and u0 will not change when u > >>>>>>>> changes. > >>>>>>>> > >>>>>>>> What remains to be done is reseting the dof map for the reduced > >>>>>>>> dimension of the subfunction and extracting vector components upon > >>>>>>>> assignment. Eventually, for > >>>>>>>> > >>>>>>>> Function u0 = u[0]; > >>>>>>>> GenericVector& x = u0.vector(); > >>>>>>>> > >>>>>>>> the vector x will only contains components related to the sub > >>>>>>>> function u0. > >>>>>>>> > >>>>>>>> > >>>>>>>> changeset: 6832:887eaeeb4e81b30cf5e2031c77bd2d77f1faed18 > >>>>>>>> user: "Garth N. Wells <[email protected]>" > >>>>>>>> date: Fri Aug 21 18:00:56 2009 +0100 > >>>>>>>> files: dolfin/fem/DofMap.cpp > >>>>>>>> description: > >>>>>>>> Comment out duplicated code in DofMap. > >>>>>>>> > >>>>>>>> > >>>>>>>> changeset: 6831:da5b9081b7cbe9753b9ce833acffe0a9c6cac9e2 > >>>>>>>> user: "Garth N. Wells <[email protected]>" > >>>>>>>> date: Fri Aug 21 17:23:38 2009 +0100 > >>>>>>>> files: dolfin/log/LogStream.cpp dolfin/log/LogStream.h > >>>>>>>> dolfin/nls/NonlinearProblem.h description: > >>>>>>>> dolfin::cout fix for 32 bit systems. > >>>>>>>> > >>>>>>>> ------------------------------------------------------------------ > >>>>>>>>-- -- For more details, visit http://www.fenics.org/hg/dolfin > >>>>>>>> _______________________________________________ > >>>>>>>> DOLFIN-dev mailing list > >>>>>>>> [email protected] > >>>>>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> DOLFIN-dev mailing list > >>>>>>> [email protected] > >>>>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
