dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

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. 


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.

Johan

> Garth
> 
> >> 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
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/mailman/listinfo/dolfin-dev
>