dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Thursday 06 November 2008 18:02:59 Martin Sandve Alnæs wrote:
> 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.

Yes, of course.

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