dolfin team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2008/11/4 Johan Hake <hake@xxxxxxxxx>:
> On Tuesday 04 November 2008 19:59:35 Johan Hake wrote:
>> On Tuesday 04 November 2008 19:45:10 Martin Sandve Alnæs wrote:
>> > 2008/11/4 Johan Hake <hake@xxxxxxxxx>:
>> > > On Tuesday 04 November 2008 15:00:42 Martin Sandve Alnæs wrote:
>> > >> 2008/11/4 Johan Hake <hake@xxxxxxxxx>:
>> > >> > On Tuesday 04 November 2008 13:59:22 Martin Sandve Alnæs wrote:
>> > >> >> 2008/11/4 Johan Hake <hake@xxxxxxxxx>:
>> > >> >> > On Tuesday 04 November 2008 13:07:07 Martin Sandve Alnæs wrote:
>> > >> >> >> 2008/11/4 Johan Hake <hake@xxxxxxxxx>:
>> > >> >> >> > Hello!
>> > >> >> >> >
>> > >> >> >> > I have started the work on the PyDOLFIN. We can now define the
>> > >> >> >> > forms in the poisson demo, using the syntax previously
>> > >> >> >> > discussed, see python poisson demo.
>> > >> >> >> >
>> > >> >> >> > A FunctionSpace now inherits both dolfin::FunctionSpace and
>> > >> >> >> > ffc.FiniteElement, and it can be used to instantiate user
>> > >> >> >> > defined Functions which can be used to define forms.
>> > >> >> >> >
>> > >> >> >> > We need to discuss how to implement a discrete function. This
>> > >> >> >> > is a bit complicated using the metaclass magic that is
>> > >> >> >> > implemented now. Now we cannot do:
>> > >> >> >> >
>> > >> >> >> >  u = Function(V)
>> > >> >> >> >  x = u.vector()
>> > >> >> >> >
>> > >> >> >> > as Function is just a dummy class for creation of userdefined
>> > >> >> >> > functions.
>> > >> >>
>> > >> >> I don't quite understand the problem here.
>> > >> >> Are you saying that type(u) is not a subclass of cpp_Function or
>> > >> >> what?
>> > >> >
>> > >> > With the metaclass implementation, Function cannot inherit
>> > >> > cpp_Function or ffc.Function. A derived class of Function will
>> > >> > inherit Function, cpp_Function and ffc.Function though. Function is
>> > >> > as it is now, only an more or less empty class that can be
>> > >> > inherited.
>> > >> >
>> > >> > The syntax above can be valid with some __new__ magic in Function,
>> > >> > probably much in line with what you had in mind.
>> > >>
>> > >> But in the metaclass __new__ function you have explicit control of the
>> > >> bases of the new class you're building, so where's the problem?
>> > >> Just set bases = (cpp_Function, ufl.Function).
>> > >
>> > > Of course. When I wrote the code I never intended Function to be
>> > > instantiated.
>> >
>> > Sure. With the new Function design that will of course happen all the
>> > time.
>> >
>> > > Would it make sense to always create a Function that is discrete when
>> > > we just write, u = Function(V)?
>> >
>> > Yes, just like cpp_Function(V). Anything else would be insane :-)
>> >
>> > By the way, this gives a segmentation fault:
>> >
>> > from dolfin import *
>> > mesh = UnitSquare(2,2)
>> > V = FunctionSpace(mesh, "CG", 1)
>> > u = cpp_Function(V)
>> > v = u.vector()
>> >
>> > Happy debugging :-/
>>
>> The same to you ;)
>>
>> Urgh... I used two hours to track a similare bug yesterday. It was a
>> forgotten NoDeleter to a shared pointer that caused the havoc.
>
> Ok, this one also took some time...
>
> The local dolfin::DofMap, dolfin::FiniteElement, ufc::DofMap and
> ufc::FiniteElement are all destroyed by python when FunctionSpace.__init__ is
> left. Is it safe to set thisown = 0? It fixes the problem, but will it be
> destroyed when the pyhton program end?

When the python process ends, the OS releases all memory.
But this approach produces a memory leak nonetheless.

> We could also store a reference to them locally a la, FunctionSpace.__dofmap
> or we could also store them in a global list in the function.py module.
>
> Any comments?
>
> Johan

The global list produces the same effect as a memory leak.
Since we have the python class, we may as well store them as V._dofmap etc.
I believe that's what the old dolfin.Function did.

--
Martin