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