fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Apr 29, 2010 at 02:19:44PM +0100, Garth N. Wells wrote:
>
>
> On 29/04/10 11:03, Anders Logg wrote:
> >As you are all aware, FEniCS uses a somewhat unorthodox convention for
> >the order of test and trial function, which is to place the test
> >function first:
> >
> >   a(v, u)
> >
> >At some point in history, u was chosen as a name for the unknown and v
> >was chosen as a name for the test function. At another point in
> >history, i was chosen as the name of the row index in a matrix and j
> >was chosen as a column index. So people tend to write
> >
> >   a(u, v)
> >   A_ij
> >
> >This is somewhat unfortunate, since i (rows, equations) corresponds to
> >the test function v and j corresponds to the trial function u.
> >
> >So we must define the matrix A by
> >
> >   A_ij = a(phi_j, phi_i)
> >
> >Notice the swapping of i and j here. This might not be much of a
> >problem but it's certainly a problem when we consider multilinear
> >forms and their corresponding tensors (as we do frequently in FEniCS):
> >
> >   A_i = a(..., phi_i3, phi_i2, phi_i1)
> >
> >For this reason, Rob and I decided to change the order of u and v and
> >write
> >
> >   a(v, u)
> >
> >when we wrote the first FFC paper back in 2005. Rob is not so much to
> >blame for this, but I've been pushing this quite hard since then with
> >the result that v is before u in the current draft version of the
> >FEniCS book, as well as in all demos.
> >
> >The question is now, should we stick by this? The reason for doing so
> >are:
> >
> >   1. It the logic thing: v<-->  i and u<-->  j
> >
> >   2. UFL, UFC and the DOLFIN assembler are all based on this
> >
> >The reasons for not doing so are:
> >
> >   1. a(u, v) looks better (alphabetical ordering)
> >
> >   2. It's what most people are used to
> >
> >If we choose this second option, we need to define the order of
> >arguments in a form to start from the right in all text that relates
> >to finite element assembly (in the FEniCS book) and in all code that
> >deals with forms (UFL, UFC, DOLFIN). Note that this means we don't
> >need to change any code at all, but the text would need changing.
> >In particular, the UFC function create_finite_element(0) would still
> >return the finite element for the test space so that the assembler
> >would assemble A and not A transposed.
> >
> >So for a bilinear form
> >
> >   a(u, v)
> >
> >we would need to say that v is the first argument (numbered 0) and u
> >would be the second argument (numbered 1).
> >
> >And for a semilinear form (see FEniCS book chapter on forms), we would
> >need to write
> >
> >   F(v_r, ..., v_3, v_2, v_1; w_1, w_2, w_3, ..., w_n)
> >
> >where {v_i} are arguments (basis functions) and {w_i} are
> >coefficients.
> >
> >This is a bit awkward (and the reason for changing the order) in the
> >first place, but this would only appear deep down in the more
> >technical parts of the text and so most users would not see it. They
> >will only see the swapping of i and j when defining the matrix for
> >Poisson.
> >
> >I hope we can have a long and good discussion on this so we settle
> >this once and for all. All comments/votes are welcome.
> >
>
> I don't feel particularly strongly either way, but have a slight
> leaning to go with a(u, v). Both a(u, v) and a(v, u) are commonly
> used, and which is more common depends on the field.

Where is a(v, u) used? I only hear comments that a(u, v) is used
*everywhere* else and we need to change.

--
Anders

Attachment: signature.asc
Description: Digital signature