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