← Back to team overview

fenics team mailing list archive

Re: The order of test and trial functions

 



On 29/04/10 14:41, Anders Logg wrote:
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.



Here are two 'a(v, u)' books from a quick scan of my book shelves

  - Hughes, TJR, The Finite Element Method
  - Donea and Huerta, Finite Element Methods for Flow Problems

Engineering numerical analysis and mechanics book often use a(v, u), I assume because when considering the weight function as a 'variation', it's common to use the order

   \delta u u

Garth


--
Anders




Follow ups

References