dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Wednesday 30 September 2009 11:22:14 Anders Logg wrote:
> 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

I think the 2. and 3. is enough. The first might just confuse the user. 
Passing one an element or functionspace as a kwarg might ease any confusion 
about not being a finite element function.

I have started on the Python side but nothing is near to finish. I will keep 
on working on this, but not until after the weekend. Sorry for that, but real 
life interfere. 

In the meantime I see that the special functions (or should we call them 
special expressions now?) also need some care.

Johan

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