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 <[email protected]>"
>> 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 <[email protected]>"
>> 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 <[email protected]>"
>> 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
>> [email protected]
>> http://www.fenics.org/mailman/listinfo/dolfin-dev
> _______________________________________________
> DOLFIN-dev mailing list
> [email protected]
> http://www.fenics.org/mailman/listinfo/dolfin-dev
_______________________________________________
DOLFIN-dev mailing list
[email protected]
http://www.fenics.org/mailman/listinfo/dolfin-dev
