fix: permute Data._decomposition and _modulo on transpose (fixes #2187)

[gaoflow]

Fix: permute Data._decomposition / _modulo on transpose

Fixes #2187.

Problem

A Data view created via .T, transpose(...) or swapaxes(...)
inherited the source's _decomposition and _modulo tuples unchanged
through __array_finalize__ (the self.ndim == obj.ndim branch
explicitly does self._modulo = obj._modulo,
self._decomposition = obj._decomposition). Both tuples are indexed by
axis, so after the axes are permuted they point at the wrong
dimensions. A subsequent slice goes through __getitem__ →
_index_glb_to_loc(glb_idx), which uses the (stale) _decomposition
to translate the global slice into local-axis ranges, and silently
returns a wrong-shaped view.

The minimal example from #2187:

import numpy as np
from devito import Grid, Function

grid = Grid(shape=(4, 6))
f = Function(name='f', grid=grid)

# NumPy reference -- expected shape (3, 2):
np.zeros((4, 6)).T[::2, ::2].shape   # (3, 2)

# Devito on `main` -- wrong shape:
f.data.T[::2, ::2].shape             # (2, 2)

f.data[::2, ::2].T (slice then transpose) works because the slice
goes through __getitem__ first and the second-step transpose only
flips a 2-element metadata tuple whose entries are already aligned.

Why both transpose() and T need overriding

ndarray.T is a C-level shortcut: it does not dispatch through
Python's transpose method on a subclass. Verified directly:

class A(np.ndarray):
    def transpose(self, *axes): print("called!"); return super().transpose(*axes)

a = np.zeros((3, 4)).view(A)
a.T              # silent -- C path
a.transpose()    # prints "called!"
np.transpose(a)  # prints "called!"

So overriding transpose alone leaves .T buggy; overriding T alone
leaves explicit transpose / swapaxes calls buggy. Three thin
overrides are added on Data:

• transpose(*axes) — normalize axes (no-arg, single
  tuple/list/iterable, or per-arg individual axes), call
  super().transpose, then permute _decomposition / _modulo into
  the new axis order and refresh _is_distributed so it stays
  consistent.
• swapaxes(axis1, axis2) — same treatment for the two-axis case.
• T — explicit Python property that forwards to transpose().

Verification

The two new tests in tests/test_data.py::TestDataBasic:

• test_slice_after_transpose — covers .T, transpose(),
  transpose((1, 0, 2)), swapaxes(0, 1), in both 2D and 3D, with
  the NumPy reference array as the source of truth (shape and
  values are compared).
• test_transpose_permutes_data_metadata — asserts
  _decomposition / _modulo end up in the new order (reverse for
  .T, swap for swapaxes, explicit permutation for
  transpose((1, 2, 0))).

Local run on main HEAD (no MPI installed; MPI-only tests pre-existing
failures are unchanged):

$ pytest tests/test_data.py -v -k "not gather and not singlempi and not Distributed and not mpi"
============ 37 passed, 2 skipped, ...
$ pytest tests/test_pickle.py tests/test_dimension.py -k "not parallel"
============ 600 passed, ...
$ ruff check devito/data/data.py tests/test_data.py
All checks passed!

Scope

Just devito/data/data.py (production fix) and tests/test_data.py
(regression tests). No public API change — transpose / T /
swapaxes signatures are unchanged; behavior matches NumPy.

[mloubout]

Thanks for that, looks sane and definitely a bug. Some small comments

[mloubout]

Can use devito.tools.as_tuple for these two cases

[mloubout]

Is this ever False?

[mloubout]

same

[mloubout]

ref = np.array(f.data)

[mloubout]

Thank you, please rebase with commit messages according to guidlines and this is gtg

https://github.com/devitocodes/devito?tab=contributing-ov-file#commit-messages-and-pull-request-titles