dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Sep 29, 2009 at 10:29:14PM +0200, Johan Hake wrote:
> On Tuesday 29 September 2009 22:10:54 Anders Logg wrote:
> > On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
> > > I'm looking forward to seeing the new code. Is all the old functionality
> > > still in place?
> >
> > Yes and no. Everything except the generated CoefficientSet stuff
> > should still work in the C++ interface, but the Python interface won't
> > work until the corresponding changes have been made on the Python side.
> >
> > Here's some more information about the changes:
> >
> > 1. Subclassing Function and overloading eval() has been replaced by
> > the Expression subclass which works in the same way with eval().
> >
> > 2. All the old functionality/logic of the Function class is still in
> > place but it can now be cleaned up and simplified.
> >
> > 3. A Function will now *always* have a FunctionSpace and *always* have
> > a vector.
>
> Good!
>
> > 4. An Expression *never* has a FunctionSpace and *never* has a vector.
>
> Also good! Should we consider (re-)adding a value_rank and dimension method to
> the expression class?

Yes, perhaps. But it's very convenient not having to specify it. We
could make it optional.

> Also what would the preferred solution be for a Python expression. It should
> not have a FunctionSpace but we need a FunctionSpace to initialize the
> ufl.Function. Or rather the ufl.FiniteElement that comes with the
> FunctionSpace.
>
> I see two alternatives:
> 1) Instantiate an Expression with a FunctionSpace, then let the FunctionSpace
> reside in the Python layer. The ufl.FiniteElement is used to instantiate the
> ufl.Function.
>
> 2) Instantiate an Expression with a ufl.FiniteElement. The problem with this
> is that we have not exposed the ufl.FiniteElement in the PyDOLFIN interface
> previously. But the confusion with an expression having a FunctionSpace is
> partly avoided.
>
> In both cases I could add checks for rank and dimensions in the Python layer
> if we decides to not require it for the C++ interface.

I think we discussed the possibility of detecting the value dimension
from the expression and automatically using piecewise linears if not
otherwise specified. The function space could be an optional argument:

  f = Expression("sin(x[0])", V=V)

Then it would be clear that f is not a function in V, but V is only
some additional information about how f should be used in forms.

> > 5. FunctionSpaces are not attached to coefficients when doing a.f = f.
> >
> > 6. The DOLFIN wrappers have been simplified and now rely on the
> > new very simple CoefficientAssigner class.
> >
> > 7. The assembler works through the common base class Coefficient, in
> > particular the restrict() function for restricting to a local element.
>
> Nice!

This also removes one of the too many interpolate() functions which is
good.

> > 8. Some checks have been removed in Assembler since a Coefficient does
> > not (if it is an Expression) have a FunctionSpace so we can't check
> > value_rank etc.
> >
> > Things that need to be done now:
> >
> > 1. Clean up Function.
> >
> > 2. Use the Expression class in demos where appropriate (just need to
> > change the class name, everything else is the same).
> >
> > 3. Fix Python interface.
>
> I hope I can fix this tomorrow. Should actually make things easier (but
> cleanup also takes time...). We should for example be able to skip the
> DiscreteFunction class now.

Sounds very good!

--
Anders

Attachment: signature.asc
Description: Digital signature