dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Monday 24 August 2009 10:30:52 Garth N. Wells wrote:
> Johan Hake wrote:
> > 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.
>
> What if we add a constructor to DiscreteFunction to take care of
> sub-functions? Would that work?

Yes, this should work. Then we could add a constructor taking a Function and a 
number as you suggested above.

> >> 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 meant C++ member functions which are intended for use through PyDOLFIN
> only.

I see :) 

We could hide some python specific classes, like the DiscreteFunction class, 
by not including it in dolfin_function.h, and then manually add it to 
dolfin_headers.i. 

With this we hide it from 

  #include <dolfin.h>

We then have to manually add them as #includes in dolfin.i and to 
dolfin_headers.i. We can automate this by adding a dolfin_pydolfin_headers.i, 
which lists the #includes. This file is then parsed by generate.py.

If this sounds reasonable I can look into it.

Johan

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