dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

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

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