Add Entropy Variables to libCEED fluids NS mini-app

[zatkins-dev]

This PR introduces physical entropy variables to libCEED fluids (see Hughes et al for full formulation). Support for entropy variables mirrors that of primitive and conservative variables, with conversion and forward physics functions.

Also adds additional unit tests for variable conversion.

[zatkins-dev]

Huh, turns out that waiting 7 months and rebasing can sometimes fix issues... I'm no longer seeing strange artifacts with gaussianwave.yml or with the density current problem.

I will add some tests, but I think this MR actually may be pretty much ready.

[jrwrigh]

Few comments, particularly regarding the naming of the components. Otherwise looks good to me.

[jrwrigh]

Do we not have more specific names for these?

[zatkins-dev]

I'm not sure. Jed's suggestion in the past was to go the opposite route, and just name them V1, V2, V3 or something like that. I'm starting to think that might be best, since I don't know how to name them otherwise.

e.g.

• The quantity I'm currently calling temperature is $-\frac{\rho}{P}$, which has units $\frac{kg}{J}$ or $\frac{s^2}{m^2}$.
• The quantity I'm calling velocity is $\mathbf{U}\cdot\frac{\rho}{P}$, which has units $\frac{s}{m}$.

[zatkins-dev]

I think the units for V1 are $kg$ (since it has $\frac{\rho}{P}(e_{\text{kinetic}} + e_{\text{potential}})$), which seems....interesting

[zatkins-dev]

@jedbrown should I use similar naming for the state components? E.g.

typedef struct {
  CeedScalar S_density;
  CeedScalar S_momentum[3];
  CeedScalar S_energy;
} StateEntropy;

[jedbrown]

🤷 Consistency is good so if we're going to name them, may as well make them match. I'm not sure it's easier in the code.

BTW, did you do anything here that may impact performance of the primitive or conservative variable code?

[zatkins-dev]

Minorly, yes. The StateFrom* functions now also compute the entropy variables.

[jedbrown]

Is that necessary? We added both conservative and primitive to avoid recomputing the equation of state each time that quantity is needed in fluxes, but I don't think entropy variables are used that way so we could probably remove the V member from State.

[zatkins-dev]

How would we use entropy variables then? We use StateFromQ and StateFromQ_fwd all over the place, and that relies on the given state variables to be in State

[jedbrown]

I don't think that's necessary? State is just our internal representation. We can import entropy variables to that representation without making it part of State.

[zatkins-dev]

I don't think that I understand what you mean by "import entropy variables to that representation without making it part of State".

Tangentially, one of the major uses for entropy variables is in making the fluxes symmetric, which while not implemented here, would justify storing V in State.