ufl team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

2009/4/1 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

Not really. It's a definition, see below.

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

1) This doesn't even make any sense. Inner always returns a scalar.
2) A proper error message will trigger so it's not a problem.
3) The definition of inner(.,.) and (.,.) is not the same, *dx is
currently part of the _definition_ of the latter syntax.
4) Your tuple syntax (u,v) still runs into all sorts of trouble, e.g.,
k*(u,v), so you're arguing against that as well.

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

The way I see it, we have
  f*dx
which is similar to and defined to represent
  \int_{\Omega} f dx

and
  f*dx(0)
which is similar to and defined to represent
  \int_{\Omega_0} f dx

and
  (u,v)*dx
which is similar to and defined to represent
  (u, v)_{\Omega}

and
  (u,v)*dx(0)
which is similar to and defined to represent
  (u, v)_{\Omega_0}

Neither of these look exactly the same in UFL as anyone would
write on paper, because we're working within the constraints of
a programming language embedded in Python. There are lots
of mathematical operations that we cannot write as simply
as on paper, so that's not an argument in itself.

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

That's what load_forms did the short while this was implemented.
It doesn't make it any more explicit for the user.

It still isn't enough to place this in the form compiler, for example
rhs and similar functions require a Form.

Martin