I agree with this. Let's stick with the current definition and add
tensor_jump (alt 1).
--
Anders
On Wed, Jun 18, 2014 at 05:53:43PM -0500, Douglas N Arnold wrote:
> 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
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
