fenics team mailing list archive

[Hans Petter Langtangen <hpl@xxxxxxxxx>]

I am probably the one to blame for introducing the confusion of two
notations in a FEniCS context. In the tutorial (to appear first in the
FEniCS book), I initially adopted the a(v,u) notation, simply because
that was the notation used in the book's intro chapter to FEM and
because I immediately realized the logical arguments that Anders
states for this choice.

However, the tutorial was used in a FEM course by Doug Arnold, and he
and his students complained about a(v,u). Most books write a(u,v), and
it was confusing to see that even the very first FEniCS example used a
different notation.  There will be many newcomers to FEniCS that are
also newcomers to FEM.  I think these users should be given the most
widespread and traditional notation so that the first experience with
FEniCS maximizes good vibrations. This argument was strong enough to
make me shift from a(v,u) to a(u,v).

The chapters in the FEniCS book where the a(v,u) notation is
preferable can use this notation, with a little argument the first
time the notation appears. Obviously, consistency throughout a book is
always desirable, but in my opinion this argument is weaker than
pleasing newcomers to FEniCS and minimizing potential confusion during
the first 30 min trial of the software. Remember that many (most?)
people will stop there and not have time to become heavy users, but
they will then have a very good impression of the software - this is
extremely important for widespread use and recognition in the long run.

Hans Petter


Thu, 29 Apr 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.
> 
> --
> Anders



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