dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

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? 

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.

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

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

Johan