On Sat, Sep 06, 2008 at 04:10:03PM +0200, Martin Sandve Alnæs wrote: > 2008/9/6 Garth N. Wells <[EMAIL PROTECTED]>: > > > > > > 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 > >> > > > > Sounds fine. I thought that a DiscreteFunction already had a > > FiniteElement. Should a DiscreteFunction own its FiniteElement? > > > > Could FFC or whatever/whoever generates the ufc::finite_element somehow > > provide a unique identifier for that element type? I don't particularly > > like the precompiled elements, and an identifier would help on this front. > > > > Garth > > As a future solution, we could add a "std::string ufl() const=0;" to > all ufl::* classes. > These can return repr(x) where x is the UFL object the code was generated > from. > The repr-string can be stored in the XML. The problem is that this is rather > implementation-specific, depending on the current version of UFL at all times. > So maybe we want to instead store the element input data: (family, > polygon, degree). > > The ufc-to-ufl string would enable some other cool stuff though: > ufl_form = eval(ufc_matrix_form.ufl()) > form_action = ffc.jit(ufl.action(ufl_form))
I think this looks very good. Hopefully, UFL can be as stable as UFC so it's not a problem to depend on it. Perhaps one could also include the UFL version in the string so that one gets an error messages if the versions don't match. -- Anders
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
