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. 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. -- Martin _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
