dolfin team mailing list archive

[Johan Jansson <johanjan@xxxxxxxxxxxxxxxx>]

On Thu, Nov 10, 2005 at 09:28:06AM +0100, Johan Hoffman 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).
> >
> > I think that Functions defined by an expression and not associated with an
> > element are sufficiently different to make them separate sub-class.
> > Sub-classes
> > of functions seems to me a natural approach and affords flexibilty for
> > future
> > (as yet unknown) functionality.
> 
> I think the sub-class model is good since it would make a Function object
> separate from the Form object. In the assembly it makes sense to involve
> the Form object (to get element), but we might wanna use a Function in
> other situations, like postprocessing for example, where it does not make
> sense to include Form in the function call.
> 
> We had this design previously in DOLFIN, and it worked ok.
> 
> >> 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.
> 
> I agree that efficiency in the assembly is critical. But I'm not sure how
> the two approaches differ in this respect?
> 

The overhead of subclassing is that you have to use virtual functions,
and that means that every function call becomes a little more
expensive (the call has to figure out which subclass the function call
should go to). So if you have many function calls where each call does
very little, this overhead could become significant.

But perhaps we don't have so many function calls in this case. I was
under the impression that we had a Function for each component for
vector-valued functions, but that's not true. So it's probably an ok
solution.

  Johan