dolfin team mailing list archive

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

2008/11/5 Johan Hake <johan.hake@xxxxxxxxx>:
> On Tuesday 04 November 2008 23:08:33 Martin Sandve Alnæs wrote:
>> 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.
>
> Would it? The point with a global list was to store a reference to the python
> object, which then wont be destroyed, when the __init__ function go out of
> scope. But when the program go out of scope they will be destroyed.

A memory leak is not when something isn't deleted at the end of the program,
in that case the OS should collect the memory anyway. A memory leak is
when something never gets deleted _during_ the application run, even though
it isn't used anymore. Say you have an application that first solves
one problem,
then another, and don't need all the functions from the first problem during the
second stage. Then this would waste memory, effectively just like 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.
>
> Yes this is probably the best solution.
>
> Johan


-- 
Martin