← Back to team overview

dolfin team mailing list archive

Re: PyDOLFIN interface

 

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.

> 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


Follow ups

References