On 10 June 2014 14:33, Anders Logg <[email protected]> wrote:

> 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


If you want to dot the gradient with the normal, why don't
you just dot the gradient with the normal like I suggested?


>  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().
>

Isn't that what jump(grad(u),n) does today?

Feel free to e.g. introduce three new operators to make it clearer and in
the control of the user:

value_jump(u), dot_jump(u, n), outer_jump(u, n)

or any better names you can think of, without any behaviour depending on
the argument.

However the current definition of jump is well defined, documented in
several publications,
and with user codes depending on its behaviour, so changing it is not a
good idea.

Martin
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics

Reply via email to