dolfin team mailing list archive

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

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