dolfin team mailing list archive

[Johan Jansson <johanjan@xxxxxxxxxxxxxxxx>]

On Wed, Nov 09, 2005 at 11:52:01AM -0600, Anders Logg wrote:
> As noted in an earlier post, we need to make some improvements to the
> Function class and it's probably worth the effort to implement a new
> design.
> 
> Here's some suggestions/thoughts:
> 
> - Use the envelope-letter design that we had before and split up the
>   Function class in several sub classes so we can separate the concerns
>   of user-defined functions and functions defined by degrees of freedom.
>   
>   This is similar to what we have for the file formats.
> 
>   class Function serves as the common interface.
>   class GenericFunction serves as a base class for Function classes.
> 
>   class Function keeps a pointer to a GenericFunction.
> 
>   class DiscreteFunction implementes functions defined by (x, mesh, element).
>   class ExpressionFunction implements functions defined by a function pointer.
> 
>   operator() (const Point& p) can be overloaded for user-defined functions
> 
>   There will thus be two ways to define a user-defined function:
>   either by a function pointer or by subclassing Function.
> 
> - Keep a list of elements in Form, one for each Function and pass it
>   along as argument to Function::interpolate() in Form::updateCoefficients().
>   This should fix the problem that Andy has.
> 
> - Implement slices/components of Functions defined on mixed
>   elements. This should be possible since FFC now generates all the
>   information that is needed. With the new design, we can add new
>   subclasses of GenericFunction to implement special functionality
>   without disturbing or complicating the basic functionality of
>   Function.
> 
> What do you think?
> 
> /Anders
> 

I think we should go with suggestion #2 and/or #3 (slicing). Since
functions are associated with a finite element (in FFC for example),
the association needs to be stored.

Functions are used in the inner assembly loop, so they need to be as
close to optimal as possible. I don't think we can afford to make them
too abstract.

If we want to make DOLFIN very user-friendly later, I think it's
better to add a layer in Python on top of PyDOLFIN (since C++ isn't
very user-friendly in the first place). Then we don't need to be
optimal at all times, since the possibility exists of using the
underlying C++ interface directly.

  Johan