dolfin team mailing list archive

["Garth N. Wells" <g.n.wells@xxxxxxxxxxxxxxx>]

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

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.

Garth

> 
> 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
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
>