A similar issue comes up with div -- it has a natural coordinate-based interpretation for a vector of H1 functions, but (should) have another when acting on a contravariant (e.g. Raviart-Thomas) field. One solution, which would be correct if pervasive, would be to make div as well as the jump operators under discussion atoms in the tree, with meaning determined by context, rather than immediately jumping to a coordinate-based particular definition.
> On Jun 10, 2014, at 7:55 AM, "Jed Brown" <[email protected]> wrote: > > Anders Logg <[email protected]> writes: >>> 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). > > Yes, naturally. It should contract the covariant index: > > (grad u)^i_j n^j > >> It seems messy to distinguish between these cases - scalar, vector, >> matrix as arguments to jump(). > > Yes, but it is crystal clear and unambiguous if you distinguish > covariance and contravariance (though we also need invariance). > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
