Remove mixed valence dot_product?

[wthrowe]

I think we screwed up in adding the mixed-valence dot_product overload in #572. It breaks our tensor type safety, in that if you are mistaken about the valence of a vector the code will compile and do a (perhaps subtly) wrong thing. For example, this looks like a tensor contraction but is actually performing a non-covariant operation because you forgot we use a lower-index face normal:

tnsr::i<DataVector, volume_dim> my_covector(...);
auto n_dot_v = dot_product(my_covector, db::get<Tags::UnnormalizedFaceNormal<volume_dim>>(box));

If dot_product only worked on same-valence vectors this would still compile, but it would be clear from looking at the code that it was doing a Euclidean dot product rather than the intended contraction.

[wthrowe]

After conversations with several people, it looks like the preferred direction to go here is to remove the same valence dot_product overload (keeping the metric version) and instead add a Euclidean index type for Tensor that would be contractible with any index type. Most code that takes tensors as arguments (outside of systems, which should know whether they are Euclidean) is generic over the index valence, so this should not be too intrusive in existing code.

[wthrowe]

Some points from today's discussion (centered around #609):

• The appearance of tensors with both Euclidean and non-Euclidean indices in #609 is weird.
• The approach in #609 still has issues when Euclidean parts of the code (such as system-specific equations) receives non-Euclidean tensors from generic code.
• There was a general preference for making the generic parts of the code handle Euclidean tensors better, rather than trying to provide an interface between them and specialized Euclidean parts.
• The only parts of the generic code that really need to know if they are working with Euclidean indices are those adding indices to tensors, such as in derivatives and fluxes.
• Whether or not a system is Euclidean depends on the frame. The logical coordinates are rarely Euclidean, but nothing should care.
• If two frames are Euclidean, the Jacobian for the transformation between them is an orthogonal matrix. It is not clear whether knowing this is useful to us.

I've probably forgotten something, since I didn't think to make notes when it was fresh in my mind.

Since we determined that Euclideanness is really a property of a frame, I would next like to experiment with encoding the information in the frame type used in tensors (which would in practice probably be specified by the system, since the system implementation will assume either Euclidean or not).

[nilsdeppe]

Depends on results of #609

[wthrowe]

I've tried experimenting with encoding Euclideanness in frames. It seems more reasonable than the attempt with indices, but it requires more changes so I haven't gotten the entire code working with it. The difficulties I've found are:

• Analytic solutions, which are specialized to a particular coordinate system and so can do operations that don't make sense in general (taking the magnitude of the coordinate vector, for example).
• Strahlkorper, where I'm not sure I understand what is going on with frames. It looks like there is a Euclidean coordinate system where the Ylm expansion is done overlaid on the GR coordinates, and this results in some objects being valid in both frames.