← Back to team overview

fenics team mailing list archive

Re: The order of test and trial functions

 

Anders Logg wrote:
On Mon, May 03, 2010 at 11:08:13AM +0200, Kent Andre wrote:
On Mon, 2010-05-03 at 09:36 +0100, Garth N. Wells wrote:
On 03/05/10 08:48, Kent Andre wrote:
I am in favour of a(u,v), simply because it is the way I am used to
read and write it. Also, very few users need to care about this due to
the high-level syntax in UFL which implicitly takes care of the
ordering.

They do need to worry about it on the DOLFIN side with the creation of a
Form:

    Poissin::Bilinearform a(V0, V1);

Garth

Yes, of course, sorry, in C++ this is important,

Anyway, I think both alternatives have their advantages.
But, as Godel put it, you must choose between consistency and
conformity :)

I've been thinking some more, and I'm getting more convinced that the
problem is really the ordering of rows and columns in matrices, which
should be (column, row) rather than (row, column) because a matrix is
really a set of columns that span the range of A, so A_i should be
column i and A_ij should be element j of that column.

So then a(u, v) would be consistent with *that* notation but it would
be a pain for us to have an unorthodox matrix index notation.

Which leaves us with the following options:

1. Keep a(v, u) as we have now and not change anything.

2. Change to a(u, v) and comment on the need for swapping the indices
when we define the matrix (tensor) in the text (book and manual).

Alternative (2) would imply the following changes:

(i) Redefine the UFC interface so that the test space is the last
space, not the first.

(ii) Swapping of indices inside Assembler.cpp.

Further comments?



Vote in favor of (1).

--
Marie

--
Anders
------------------------------------------------------------------------

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




Follow ups

References