Automate ProjectionPlot

[chongchonghe]

Describe the proposal

We can automate projection plot calculation and ask the user to specify the state variables to store at runtime.

Additional context
#1339

[dosubot]

The ProjectionPlot feature supports 3D projections along the x, y, and z axes, but will abort with an error (exit code 4) if an invalid direction is specified in projection.dirs or if the direction is not supported for the current problem dimensionality. This is enforced by runtime checks using amrex::Error("invalid direction for projection!") in the code, which causes a hard failure rather than a catchable exception. Typos or unsupported directions in your input file (for example, a misspelled axis or a direction not valid for your simulation) will trigger this abort and result in the observed CI failure. The expectation is that you implement the ComputeProjections method for your problem; if omitted, the code will output empty projection files but not crash. If you are specifying valid directions and still seeing the error, double-check for typos and confirm your simulation is truly 3D and supports the requested axes. For more details, see the implementation in simulation.hpp and projection.cpp.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[BenWibking]

@chongchonghe Did you implement ComputeProjections: https://quokka-astro.github.io/quokka/insitu_analysis/#2d-projections ?

[chongchonghe]

Oh, I missed that. I see, i have to write computePlaneProjection myself.

[chongchonghe]

but this shouldn't be necessary. It's straight forward to do projections of existing components. We can either specify which components to compute projections for by giving a list of integers or strings representing the default variable names.

[BenWibking]

Yes, setting things at runtime would be better.

For the shock-cloud problem, I wanted to compute projections of derived variables like this:

quokka/src/problems/ShockCloud/cloud.cpp

Line 628 in b642c02

return (H_mass_fraction * rho) / m_H;

[chongchonghe]

I'll create a PR for that soon. Here is my idea. Please let me know what you think.

I'll define a runtime parameter projection.vars as a list of strings. For variable that belong to an existing components, say, one of the six hydro components listed below, it will simply do a line integral. Since all of them are volume density of some quantity, their line integral is meaningful.

std::vector<std::string> hydroNames = {"gasDensity", "x-GasMomentum", "y-GasMomentum", "z-GasMomentum", "gasEnergy", "gasInternalEnergy"};

For undefined components, the user has to define how to compute it in the problem generator, using this format:

if (var == "nH") {
  const Real rho = state(i, j, k, HydroSystem<ShockCloud>::density_index);
  return  rho / m_H;
} else if (var == xxx) {
  ....
}

[chongchonghe]

return (H_mass_fraction * rho) / m_H;

If H_mass_fraction is a constant, and it seems like it is, this is simply the density surface density times H_mass_fraction/m_H.

[BenWibking]

I think it should probably always do a line integral, with an option to be either mass-weighted or volume-weighted (like the histograms).

I think allowing runtime selection of either the conserved quantities or the derived vars would be ideal. Then I can convert all of the existing projections in ShockCloud to be of derived vars.

For now, the derived vars probably still have to be defined with the ComputeDerivedVars function in the problem file.

[BenWibking]

In the future, this could be integrated with more advanced machinery for derived fields: #1190

[BenWibking]

I think the best thing to do now is to just to copy the current slice machinery that works for either conserved or derived vars and use it to compute projections (i.e. line integrals): https://quokka-astro.github.io/quokka/insitu_analysis/#2d-slices