Every Riemann solver in shammath:
- permute & rotate the vector components of the two input PrimState/DustPrimState operands,
- call the *_flux_x solver,
- permute the resulting ConsState/DustConsState flux back with the mirror functions.
Adding a new solver currently means writing 6 near-copy-pasted wrappers by hand, when the permutation logic is really just fixed rotation matrices (axis swaps + a sign flip) applied to vel/rhovel.
The goal would be replace the six hand-written wrappers per solver with a single generic call that uses compile (NTTP) or runtime (by value) matrices and their inverse to perform the suitable rotations. (maybe we should rewrite the riemman solver to be direction agnostic but i'm not sure if that's the best idea ...)
Note that clang 15 has known issues with vector/floating-point NTTPs, so a Tvec value can't be used directly as an NTTP on that toolchain.
Every Riemann solver in shammath:
Adding a new solver currently means writing 6 near-copy-pasted wrappers by hand, when the permutation logic is really just fixed rotation matrices (axis swaps + a sign flip) applied to vel/rhovel.
The goal would be replace the six hand-written wrappers per solver with a single generic call that uses compile (NTTP) or runtime (by value) matrices and their inverse to perform the suitable rotations. (maybe we should rewrite the riemman solver to be direction agnostic but i'm not sure if that's the best idea ...)
Note that clang 15 has known issues with vector/floating-point NTTPs, so a Tvec value can't be used directly as an NTTP on that toolchain.