On Tuesday 04 November 2008 23:08:33 Martin Sandve Alnæs wrote: > 2008/11/4 Johan Hake <[EMAIL PROTECTED]>: > > 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 <[EMAIL PROTECTED]>: > >> > > On Tuesday 04 November 2008 15:00:42 Martin Sandve Alnæs wrote: > >> > >> 2008/11/4 Johan Hake <[EMAIL PROTECTED]>: > >> > >> > On Tuesday 04 November 2008 13:59:22 Martin Sandve Alnæs wrote: > >> > >> >> 2008/11/4 Johan Hake <[EMAIL PROTECTED]>: > >> > >> >> > On Tuesday 04 November 2008 13:07:07 Martin Sandve Alnæs wrote: > >> > >> >> >> 2008/11/4 Johan Hake <[EMAIL PROTECTED]>: > >> > >> >> >> > 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 _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
