On Thursday 06 November 2008 18:02:59 Martin Sandve Alnæs wrote: > 2008/11/5 Johan Hake <[EMAIL PROTECTED]>: > > 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. > > 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 _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
