ufl team mailing list archive

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

It seems important to you, so I won't argue any further.
You're right that it's non-intrusive, so it won't be a big problem.

Martin


2009/4/1 Anders Logg <logg@xxxxxxxxx>:
> On Wed, Apr 01, 2009 at 08:58:09AM +0200, Martin Sandve Alnæs wrote:
>> 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.
>
> ok, so replace it by
>
>  a = inner(v, grad(inner(w, grad(u))))*dx # works
>  a = (v, grad((w, grad(u))))*dx           # ???
>
> The point is operators can't be applied to a tuple until it has been
> multiplied by a measure and turned into a Form.
>
>> 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.
>
> No, it's different. What we have now is a language for expressing
> *integrands*. Then one expects to be able to operate on the
> integrands. The tuple notation is for L^2 inner products and then it's
> not clear on may operate on the inner products except addition, which
> works, and multiplication, which does not work.
>
>> > 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
>
> Yes.
>
>> and
>>   f*dx(0)
>> which is similar to and defined to represent
>>   \int_{\Omega_0} f dx
>
> Yes,
>
>> and
>>   (u,v)*dx
>> which is similar to and defined to represent
>>   (u, v)_{\Omega}
>
> This can be replaced by (u, v).
>
>> and
>>   (u,v)*dx(0)
>> which is similar to and defined to represent
>>   (u, v)_{\Omega_0}
>
> This can be replaced by (u, v, dx(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.
>
> But it *is* possible in this case. The notation is
>
>  (u, v)
>
> and the implementation is
>
>  (u, v)
>
>> > 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.
>
> Not for the user, but it separates the tuple notation from the form
> language. The form language remains nice and clean (no tuples, just
> UFL objects) with an additional utility function to transform a tuple
> into a Form.
>
> From the user's perspective, there are two ways to express a form,
> either by writing out the integrands or by writing out the L^2 inner
> products. The form compiler automatically figures out which notation
> is used (either it is a tuple or not a tuple) and makes a simple call
> to tuple2form when necessary. It is simple (it just involves a single
> function call), non-invasive (it doesn't modify the form language like
> the current mix) and it's already implemented.
>
>> It still isn't enough to place this in the form compiler, for example
>> rhs and similar functions require a Form.
>
> We can either live without lhs and rhs for the tuple notation, or we
> could add a simple call to as_form for a limited number of operators
> (like lhs and rhs) that are used to operate on an entire form, which
> is everything in formoperators.py:
>
>  lsh
>  rhs
>  action
>  adjoint
>  derivative
>
> --
> Anders
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAknTbY8ACgkQTuwUCDsYZdEYpwCgljQhHg5AcVOZjGTro1+AJYvG
> PmEAn14HoIXVinGLM186YdW53WBDy8dH
> =ntRz
> -----END PGP SIGNATURE-----
>
>