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 <[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)
>>> 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.

It would be neat if we could somehow make member functions 'private' to 
PyDOLFIN.

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

Reply via email to