← Back to team overview

dolfin team mailing list archive

Re: [HG DOLFIN] Work on new sub Function logic.

 

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?

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


Follow ups

References