dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Sep 30, 2009 at 03:55:22PM +0200, Johan Hake wrote:
> 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.

Agree.

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

ok.

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

Looks like Garth has fixed this.

--
Anders


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

Attachment: signature.asc
Description: Digital signature