dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Tuesday 29 September 2009 22:39:02 Anders Logg wrote:
> 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.

Ok. No big dealt for me. In Python we can solve this for Expressions anyway.

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

Yes, but a user can initialize an Expression with the wrong 
FunctionSpace/FiniteElement compared to what the expression looks like.

> and automatically using piecewise linears if not
> otherwise specified. 
>
> The function space could be an optional argument:
> 
>   f = Expression("sin(x[0])", V=V)

We cannot automatically figure out the topological dimension, can we?

Should we require that an Expression is instantiated using just a 
ufl.FiniteElement? In this way it would be clear that the Expression is not 
defined in a FunctionSpace? It would then look like:

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

or something.

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

Ok.

Johan