← Back to team overview

dolfin team mailing list archive

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

 

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

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


Follow ups

References