dolfin team mailing list archive

["Anders Logg" <logg@xxxxxxxxx>]

ok, what does Johan J think?

/Anders

> I think the design looks good, and I agree on the conditions 1-3.
> 
> Additional details include the possibility of fast evaulation, given the 
> current Cell, to be used in the assembly.
> 
> /Johan
> 
> > Here is a suggestion for a redesign of the Function classes in DOLFIN.
> >
> > The class Function is central in DOLFIN and so it is important that
we get
> > it right. Please comment on the following suggestion of a redesign
of the
> > Function class (and related classes).
> >
> > First some initial conditions:
> >
> > 1. The main purpose of a Function is that one should be able to evaluate
> > it. The central method of a Function is thus
> >
> >    real operator() (const Point& p, real t);
> >
> > 2. The class Function should be allround, simple to use and hide its
> > current representation to the user. A user shouldn't need to care
whether
> > or not a Function is represented in terms of a list of degrees of
freedom
> > or if the Function is specified in terms of some expression.
> >
> > 3. One should be able to inherit from the class Function to create one's
> > own Functions.
> >
> > Condition 2 calls for an envelope-letter design pattern: The class
> > Function holds a pointer to a GenericFunction. Several classes inherit
> > from GenericFunction. At all times, the pointer inside Function is
> > instantiated to one of the subclasses of GenericFunction. The choice of
> > subclass is handled by the constructor of the class Function, which
> > determines the type based on the arguments to the constructor.
> >
> > I can think of three types of Functions, each implemented as a
subclass of
> > GenericFunction:
> >
> > StaticFunction: constant in time function (until changed)
represented by a
> > list of degrees of freedom (a Vector) on a Mesh. This will in large
parts
> > be the same as the current DofFunction.
> >
> > DynamicFunction: time-dependent function with data partly stored in a
> > file.  It should internally hold a variable t telling the current
time. If
> > data is requested at a time other than the current time, new data is
> > fetched from file. We could also add things such as caching of data
(like
> > with ODEFunction).
> >
> > FunctionPointerFunction: a function represented by a function pointer.
> > Replaces the current class ExpressionFunction. (I think we might be
> > needing the name for something else later, maybe there can be a class
> > FunctionExpression which allows a simple algebra for functions?)
> >
> > This design is quite similar to what we have now.
> >
> > To meet condition 3, we need in addition to make the methods in Function
> > virtual so that people can make things like
> >
> > class MyFunction : public Function
> > {
> > public:
> >   real operator() (const Point& p, real t) { return p.x*p.y; }
> > };
> >
> > This means that we also need to add an empty constructor to Function and
> > GenericFunction. For a user-defined Function, the pointer to
> > GenericFunction  is instantiated to a GenericFunction. This means in
turn
> > that the methods in  GenericFunction should be virtual but not pure
> > virtual (=0). The impplementations of these functions in GenericFunction
> > should just say something like
> >
> >    dolfin_error("Not implemented.");
> >
> > By the way, this is the same design as we have for the Matrix classes,
> > motivated by the fact that the actual representation of a Matrix
(dense or
> > sparse) should be hidden, but users should also be able to create their
> > own Matrix class by inheriting from the class Matrix.
> >
> > Then there's also the question of the design of the class
VectorFunction,
> > but that may be a separate discussion?
> >
> > What do you think? Is this a good design? Can we start writing the code?
> >
> > /Anders
> >
> > PS: I'm waiting for my computer to arrive, which means I'm stuck with
> > Windows XP for a few days. This means that all I'll be able to do is
write
> > emails for a few days...
> >
> >
> >
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxxxxxxxxxxxxxx
> > http://bamse.math.chalmers.se/cgi-bin/mailman/listinfo/dolfin-dev
> >
> >
> >
> 
>