ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

Here are some more thoughts about the (v, w) notation.

On paper, we have two different ways to express a form. Assuming here
that v and w are two vector-valued functions, one may either write
out the integrals explicitly:

  (1.a)  \int_{\Omega} v \cdot w dx
  (1.b)  \int_{\Omega} v_i w_i dx

or use the shorthand L^2 inner-product notation:

  (2)    (v, w)

UFL currently supports both (1.a) and (1.b) but not (2).
I think we should support all three.

What we have now is a mix:

  (3)    \int_{\Omega} (v, w) dx

This doesn't really make sense and we run into all sorts of trouble.
Just consider something like

  a = v*div(inner(w, grad(u)))*dx # works
  a = v*div((w, grad(u)))*dx      # ???

So I suggest we remove tuples from the form language, in particular
multiplying a tuple with a measure, but add back the possibility to
create a Form from a tuple. This means that there are two different
notations: (1) and (2) and one can be transformed into the other, just
as on paper. Sometimes one notation is convenient, sometimes the
other.

To make it even more explicit, we can move the extraction of a UFL
Form from the constructor of the Form class to a function named
something like tuple2form and place it under ufl.algorithms. The form
compiler may then check the input argument to see whether or not a
call to tuple2form is necessary.

-- 
Anders

Attachment: signature.asc
Description: Digital signature