dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

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 <gnw20@xxxxxxxxx>"
> > 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)

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 <gnw20@xxxxxxxxx>"
> > 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 <gnw20@xxxxxxxxx>"
> > 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
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/mailman/listinfo/dolfin-dev
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev