dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Nov 09, 2005 at 11:27:27PM +0100, Johan Jansson wrote:

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

Part of the problem with the current design is that not all Functions
should be associated with a particular FiniteElement. A user-defined
Function that just implements operator() (const Point& p) could be
reused in different forms and be associated with different
FiniteElements in each form (like in Andy's case).

Part of the reason I would like to break out the functionality in
subclasses is to be able to make some simplications. The logic of the
current implementation of Function is nontrivial.

If we make DiscreteFunction a separate subclass, it would be easier
to follow the logic and get it right.

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

I don't think that's much of an issue, as long as the stuff we do
inside the calls to Function::foo() dominates the function call.

The current implementation also needs to check which type of Function
is used so we would be able to replace some if-statements with
subclassing.

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

That's also an option.

/Anders