2008/9/6 Garth N. Wells <[EMAIL PROTECTED]>: > > > Dag Lindbo wrote: >> Anders Logg wrote: >>> There seems to be a problem (among many) with the current design of >>> the Function classes (see thread "evaluating higher order mesh function"). >>> >>> In particular, the finite element is missing in DiscreteFunction. My >>> suggestion would be to just add it and let a DiscreteFunction consist >>> of the following four items which are always available: >>> >>> mesh, x, dof_map, finite_element >>> >>> Is this enough, and what other issues to we need to fix? >>> >> >> One major issue which I just want to reiterate is ownership of data. As >> it stands, the DiscreteFunction may or may not be responsible for e.g. >> the dof vector x, depending on whether local_vector is a NULL pointer or >> not. Take a look at the thread "Ownership" from Garth on 06/26/2008. >> > > Yes, this is a big problem and has caused me a few headaches with bugs. > For example, passing a user-defined Function to a function to convert it > to a DiscreteFunction via a projection onto a finite element basis > causes a problem because the FiniteElement which the projected Function > points to goes out of scope once the function is exited. > >> A problem related to this is initialization of the DiscreteFunction. We >> had a bug previously where the LinearPDE class maintained ownership of >> the solution vector. The only way to prevent this was to break the >> encapsulation of DiscreteFunction by making it a friend of LinearPDE (as >> with XMLFile for the same reasons). Here is some of the code that >> handles this initializaton today (L101 in LinearPDE.cpp): >> >> u.init(mesh, *x, a, 1); >> DiscreteFunction& uu = dynamic_cast<DiscreteFunction&>(*u.f); >> uu.local_vector = x; >> >> This ain't poetry in my opinion :) >> > > Indeed, this isn't nice, and there is something similar in XMLFile.cpp. > > Garth
We should start to use std::tr1::shared_ptr. There is some support for it with python in swig 1.3.35, which is part of the upcoming Ubuntu Intrepid -- Martin _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
