Here is my summary and take on this discussion.
As has been pointed out, the current definition of jump(v, n)
in UFL matches the definition of [[v]] in our paper from SINUM
2002. This definition has two advantages that led us to use it:
(1) it does not depend on the choice of normal on an edge (or,
equivalently, on how you choose to assign the labels '+' and '-'),
and (2) it leads to the fundamental integration by parts formula
(equation 3.3 in the paper)
-int div_h(g) v dx
= int g . grad_h(v) dx + int {g}.[[v]] ds + int [[g]] {v} ds
for piecewise smooth vector-valued function g and scalar-valued
function v. This formula is core to the analysis of DG methods
(typically applied with g = grad_h u), so it is nice that it can be
written compactly. If we were to have used the the proposed operator
tensor_jump(g, n) = outer(g('+'), n('+')) + outer(g('-'), n('-'))
then to express the [[g]] that appears in the fundamental formula,
we would have had to introduce a matrix trace, making it a little
more unwieldy. HOWEVER, note that even though the term
int [[g]] {v} ds appears a lot in the analysis of DG methods,
it does NOT appear in typical DG methods themselves, so it is
may not be important that it be easy to code in UFL.
Now just as the theory of DG for scalar elliptic equations works
nicely with a jump operator that assigns vector jumps to scalars
and scalar jumps to vectors, for vector elliptic equations we
would want the jump to assign matrix jumps to vectors and vector
jumps to matrices. The former would be the proposed tensor_jump.
(I don't know what the latter would be, but, again, this is not
something that often needs to be coded).
To summarize:
Alternative 1. Keep the current definitions and add tensor_jump.
Pro: The current definitions are fairly standard.
Con: Results in 3 jump operators, jump(v), jump(v, n), and
tensor_jump(v, n).
Alternative 2. Get rid of the current jump(v, n), using that
syntax for the tensor_jump(v, n).
Pro: This won't affect most codes for scalar problems, and will
save the six characters "tensor_" for vector problems.
Con: Not backward compatible for the rare case where someone has
coded jump(v, n) for vector v, and not compatible with
the current documentation or the standard notation used
in the literature.
I vote for alternative 1 (but could live with either).
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
