dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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