[WIP] Compute emf

[BenWibking]

Description

TODO:

• is the amount of numerical resistivity consistent with other second-order CT codes?
• fix wavespeeds
• reconstruct face-centered Riemann velocities to edges
• print warning when running MHD problems that MHD is currently experimental
• prevent users from turning on both MHD and AMR (for now)
• require a gamma-law EOS when MHD is enabled
• compute error norm in the same way as the HydroWave test?

Related issues

Fixes #648.

Checklist

Before this pull request can be reviewed, all of these tasks should be completed. Denote completed tasks with an x inside the square brackets [ ] in the Markdown source below:

• I have added a description (see above).
• I have added a link to any related issues (if applicable; see above).
• I have read the Contributing Guide.
• I have added tests for any new physics that this PR adds to the code.
• (For quokka-astro org members) I have manually triggered the GPU tests with the magic comment /azp run.

[github-advanced-security]

CodeQL found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

[BenWibking]

The current sheet problem (https://www.astro.princeton.edu/~jstone/Athena/tests/current-sheet/current-sheet.html) runs, but produces very low densities, so I stopped it after the timestep got too small to continue (at about t ~ 1.9). It is stable with either arithmetic averaging scheme, but it has significant oscillations in the magnetic field (which is expected for arithmetic averaging):

[BenWibking]

This is not very clear from the text, but the average transverse face-centered velocity ${\bar v}_i$ (Equation 29) is actually (almost exactly) the face-centered velocity returned by the HLLD solver that we already compute and store in the face-centered Multifabs. (Strictly speaking, it is only identical if we were to use an HLL solver for the hydro fluxes, since Equation 29 is the exact face-centered Riemann velocity state for the HLL solver.)

Neco has currently implemented Equation 27 below.

But I think it will make the code much simpler (and avoid the problematic method of reconstructing two directions in two different ways from Felker & Stone) to instead implement Equation 28 (https://ui.adsabs.harvard.edu/abs/2021JCoPh.42409748M/abstract):

[BenWibking]

Ok, so it crashes in the AlfvenWave test if you turn on the HLL emf solver from LD04:
https://github.com/quokka-astro/quokka/actions/runs/13528028184/job/37803398004?pr=900

[BenWibking]

It probably makes sense to use a much larger tolerance for the magnetic field L1 norm:

Checking cc-quantities
Relative rms L1 error norm = 1.762394815e-08
Checking fc-quantities in the 0 direction
Relative rms L1 error norm = 0, with err_norm = 0 and sol_norm = 12384
Checking fc-quantities in the 1 direction
Relative rms L1 error norm = 0.03801034604, with err_norm = 0.0003221579543 and sol_norm = 0.008475533318
Checking fc-quantities in the 2 direction
Relative rms L1 error norm = 0.03801035536, with err_norm = 0.0003345151396 and sol_norm = 0.008800631733

[sonarqubecloud]

Quality Gate passed

Issues
46 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
9.5% Duplication on New Code

See analysis details on SonarQube Cloud