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? >> 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. 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
