dolfin team mailing list archive

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

2007/4/11, Anders Logg <logg@xxxxxxxxx>:
> On Tue, Apr 10, 2007 at 06:14:12PM +0200, Garth N. Wells wrote:
> > Connected to Kristian's work on quadrature in FFC, we should think about
> > how to work with functions which do not come from a finite element
> > space. Such functions (like stress for a plasticity model or viscosity
> > for a non-Newtonian flow) are evaluated at quadrature points, rather
> > than at nodes.
> >
> > Garth
>
> The current design (including UFC) assumes that all functions can be
> interpolated to a finite element basis, but I think it will work for
> the quadrature code generation to imagine that you have a finite
> element basis where the quadrature points are the same as the nodes.
> (But you never need to know the basis functions.)
>
> The array of coefficients (double** w) that comes in to the function
> tabulate_tensor() should contain the coefficients, but for the
> quadrature these will be the same as the values at the quadrature
> points, and this should work out fine since the values that go in to w
> are decided by the evaluate_dof() function that also gets
> generated.
>
> So the quadrature code generator just needs to make sure that
> evaluate_dof() picks the values at the quadrature points.
>
> /Anders

Perhaps we could define a superclass for finite_element which only
contains the functions needed for this, to make this more obvious?

class coefficient_function
{
 ... global_dimension(...) // == elements * quadpoints
 ... local_dimension(...) // == quadpoints
 ... evaluate_dof(f, ...) // == evaluate f in quadpoint
}

class finite_element: public coefficient_function
...

It would require some more changes in the interface though, and it
wouldn't add any functionality.

martin