Error in .vtk surface files outputted from QuasiLocalMeasures

[Former user]

When running the example parameter file for simulating the BBH merger GW150914 (with modifying the .rpar file to have a non-zero out3d_every variable), the surface .vtk files from the QuasiLocalMeasures thorn are not spheres as expected, but some odd shape.

Roland has reproduced this bug, and suggested commit 56a98ded "QuasiLocalModes: Simplify VTK output routine to speed up build times" may be at fault.

[Erik Schnetter]

I wrote this patch? I have no recollection of this happening.

Do you have more information about the problem? Do you e.g. have one of the VTK files that is broken?

[Roland Haas]

Please see http://lists.einsteintoolkit.org/pipermail/users/2021-February/007767.html for the file and http://lists.einsteintoolkit.org/pipermail/users/2021-February/007765.html for a rendering (I’m not the reporter, I assume Chris is).

[Roland Haas]

Reverting 56a98ded makes the rendering go back to normal (tested using 12 MPI ranks each).

[Erik Schnetter]

The array indices are mixed up, and the points are written in the wrong order. Internally, Cactus uses Fortran array ordering, but VTK expects C array ordering. I’m working on a patch.

[Roland Haas]

Pull request is here: https://bitbucket.org/einsteintoolkit/einsteinanalysis/pull-requests/17/quasilocalmeasures-correct-array-indexing

[Roland Haas]

Please apply.

[Roland Haas]

Applied as git hash 380fe756 "QuasiLocalMeasures: Correct array indexing" of einsteinanalysis