dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sat, Sep 06, 2008 at 04:10:03PM +0200, Martin Sandve Alnæs wrote:
> 2008/9/6 Garth N. Wells <gnw20@xxxxxxxxx>:
> >
> >
> > 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

Attachment: signature.asc
Description: Digital signature