dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Sep 30, 2009 at 09:31:01AM +0200, Johan Hake wrote:
> On Wednesday 30 September 2009 09:12:46 Garth N. Wells wrote:
> > Johan Hake wrote:
> > > 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?
> > 
> > We can from the function space.
> 
> Yes, but when the user does not pass the space we cannot.
> 
> > > 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.
> > 
> > Doesn't this defeat the purpose of having 'Expression' (i.e. no function
> > space)? Could we just pass the cell type?
> 
> Not sure the cell type would fit all purposes. When we compile an Expression 
> using the extended syntax where the user define the whole C++ code, we cannot 
> automatically extract the value rank. 
>
> We also need to pass the ufl.FiniteElement in some way so the ufl.Function can 
> be initialized correctly. This so we can define forms using the newly created 
> Expression (i.e. ufl.Function). This was previously done by using the 
> ufl.element passed by the FunctionSpace. 

What we need is the UFL FiniteElement. This can be extracted from any
of the following:

  1. The shape and the expression (if we assume piecewise linears)
  2. A UFL FiniteElement
  3. A FunctionSpace

Perhaps we should allow all three? The basic usage would be

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

It might also be possible to leave the shape as "undefined" and then
automatically set the shape during assembly.

> On a side note:
> Should we consider changing the name of ufl.Function to ufl.Coefficient? I do 
> not think the name is used in UFL now.

Yes, that seems like a good idea. Any objections from Martin?

-- 
Anders

Attachment: signature.asc
Description: Digital signature