On Tue, Jun 10, 2014 at 11:17:30AM +0200, Jed Brown wrote:
> Anders Logg <[email protected]> writes:
> > I also don't see the point in defining jump(v, n) for vector valued u
> > as in the paper. If the result of jump(v, n) is a scalar quantity,
> > there is no way to combine the normal n with the thing it should
> > naturally be paired with, namely the flux (or grad(u)). It only works
> > out in the special case of scalar elements.
>
> The point of the definition in the paper is that "flux" or gradient
> jumps are dotted with the normal (thus reducing their rank).
The problem here is that when jump(v, n) returns a scalar for a vector
v, then the flux will *not* get dotted with the normal n since n has
already been dotted... I want to write
{grad u} . [v]_n
> The
> overload in FEniCS is problematic because a multi-component "vector"
> (which just happens to have the same number of components as the
> gradient of a scalar) is being confused with the one-form (a covector).
>
> Note that while a vector (as in DG formulations for elasticity or
> Stokes) is contravariant, 3-species diffusion has the same dimensions,
> but is invariant.
>
> It may be more effort than it's worth to distinguish contravariant,
> covariant, and invariant "vectors" in the type system, but doing so
> would fix these ambiguities.
Perhaps, as one would also want to express terms like this one:
[grad u]_n
When u is a vector, I would want the above to be a contraction
(matrix-vector product). It seems messy to distinguish between these
cases - scalar, vector, matrix as arguments to jump().
--
Anders
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
