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. 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 :) /Dag > > > ------------------------------------------------------------------------ > > _______________________________________________ > DOLFIN-dev mailing list > [email protected] > http://www.fenics.org/mailman/listinfo/dolfin-dev
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
