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 : [email protected]
Unsubscribe : https://launchpad.net/~fenics
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~fenics
Post to : [email protected]
Unsubscribe : https://launchpad.net/~fenics
More help : https://help.launchpad.net/ListHelp
