← Back to team overview

fenics team mailing list archive

Re: The order of test and trial functions

 

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


i don't know if my argumentation does help, but i think you do a better job with a(v, u) since all the books on fem and variational/weak formulations i came across write something like,

'...multiply by a testfunction (v in our case) and integrat over the domain ....'

and what they do is put the testfunction v in front of your term to integrate over when forming the linear, bilinear or even multilinear forms, so the most stuff i came across looks always something like

\int_G v:u dG  or int_G v:f dG etc.

in the full write out. but the 'short hand' notation, using a(_,_) it is reversed, the a(u, v) way. i don't know why they do this, but so it appears to me that you (fenics) are consistent and the others are not. i vote for consistency and logics, thus i like your writing with a(v, u). that's the way how to do it and not care about 'what most people are used to'. i always have the most problems figuring out some mathematics in paper or book, because in there, the people tend to use 'what most people are used to' and just leave some definitions or obvious things (which appear totally non-obvious to me, especially if you do such stuff for the first time) away and the like. that way it takes ++++time to figure out what they actually did. go for logics. use a(v, u) as you have.
best,
patrick

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.

--
Anders


------------------------------------------------------------------------

_______________________________________________
Mailing list: https://launchpad.net/~fenics
Post to     : fenics@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~fenics
More help   : https://help.launchpad.net/ListHelp




References