handle vector groups of vectors correctly in Periodic, RotatingSymmetry90, RotatingSymmetry180, etc.

[Roland Haas]

I think only the RotatingSymmetry ones need work since Peridic does not need to know what type of object it acts on. See #1236

Keyword: RotatingSymmetry180RotatingSymmetry90

[Roland Haas]

I attach in vectors90.patch a patch to support groups of vectors the same way reflectionsymmetry does. The parfile tests this with Luke Robert's thorn. It requires access to Zelmani. Please ignore the no_local_reductions90.patch file as I only uploaded that one accidentally.

Please comment on whether this is an acceptable way of implementing the functionality (or whether we want a separate variable "tensorcomponent" rather than all the "/ tensorlength").

[Erik Schnetter]

Yes, this is a good way.

[Roland Haas]

removed leftover printf from patch.

[Roland Haas]

Applied as rev 89 of RotatingSymmetry90.

[Roland Haas]

A patch for rotatingsymmetry 180 is missing. The implementation for roatingsymmety90 has a bug in the symmetry interpolation code (boundary condition work fine).

[Roland Haas]

I added a patch to correct interpolation in rotatingsymmetry90, before it would have failed (triggered an assert) if multiple vector components were interpolated at the same time. There is a very helpful comment in the code just above the assert (interpolate.c lin 886) , many thanks to whoever put the comment there.

[Roland Haas]

bump priority since people are actually hit by this and I am no longer sure if the assert() catches all usage cases (eg it might not catch the case where only vel[1] is interpolated). The bug manifests itself as always interpolating the x component of vel[] even if vel[1] is requested.

[anonymous]

Reviewed ok! Please apply!

[pmoesta]

Reviewed ok! Please apply!

[Roland Haas]

applied as rev90 of RotatingSymmetry90. Leaving ticket open to remind someone to implement the same code in RotatingSymmetry180.