dolfin team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

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))

--
Martin