dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Nov 26, 2009 at 10:49:16PM -0800, Johan Hake wrote:
> On Thursday 26 November 2009 16:09:53 Garth N. Wells wrote:
> > Anders Logg wrote:
> > > On Thu, Nov 26, 2009 at 09:42:22PM +0000, Harish Narayanan wrote:
> > >> Anders Logg wrote:
> > >>> Looks like the new Expression interface might be working now but more
> > >>> tests are needed. Please help out getting all the demos over to the
> > >>> new interface.
> > >>>
> > >>> The changes to the interface are as follows:
> > >>>
> > >>> 1. V=V argument in Expression should be removed
> > >>>
> > >>> 2. mesh argument in Constant should be removed
> > >>>
> > >>> 3. Subclasses of Expression overloading eval must overload dim if not
> > >>> scalar
>
> Ok, this might seem to be a bit far fetched but I think it is quite nice.
>
> What with:
>
>   class MyExpression(Expression):
>       def eval(self, x):
>           ....
>           return x_values, y_values
>
> The value dimension would then just be the length of the return argument. The
> _actual_ eval function would then, using the fabulous metaclass, be:
>
>    def eval(self, values, x):
>        values[0], values[1] = user_eval(self, x)
>
> where user_eval is the eval method defined above by the user.
>
> This will solve the value dimension problem for python expressions, and make
> the eval method the user specify more pythonic.

Being able to do return sin(x[0]), cos(x[1]) would be very nice.

But I guess we would still have to implement the dim() function when
subclassing Expression?

> How do we evaluate the value dimension for multi line C++ expression? Do we
> require the user to initialize the base Expression class using either the uint
> dim constructor or the vector<uint> value_shape constructor?
>
> If so I do not see that the code in __init__ take care of this case, yet...

I have assumed that the cpparg input is either a single string (and
then it's scalar), a tuple of strings (and then it's a vector) or a
nested tuple (and then it's a tensor).

Are there other cases I have missed?

> We also need a cleanup of different erroneous user cases. The one that Garth
> sketches below, should issue an error. Now it assume the the V is a "cpparg",
> and somehow gets through.

Yes.

> I have also provided the protected attribute _ufl_element. Now there seems to
> be an element, and a degree attribute. The latter is OK, but I think the
> former should use the _ufl_element attribute, as other code use the method
> ufl_element() to access this.

ok.

> > How should subclaases be initialised?
> >
> >   f = Source(V)
> >
> > works, but
>
> Should issue an error.
>
> >   f = Source
> >
> > doesn't.
>
> Here you just tell f to be the subclass Source. With the present design you
> should just use:
>
>   f = Source()
>
> I have pushed a fix for a bug that prevented this :)

I thought f = Source() worked already. It did when I tested yesterday.

Or did you mean you remove the f = Source(V) thing?

There were quite a few references to function spaces and V in
expression.py when I left it yesterday. Did you clean those out as
well?

--
Anders

Attachment: signature.asc
Description: Digital signature