"Dependent variables" is a bad idea, let's get rid of it

[inducer]

(Follow-on from review of #7)

• Obnoxious logistics imposed on every user of these variables
• Lots of extra arguments floating around
• Computers can figure this out, let's make them

[MTCam]

I am curious about this - especially the part about it being obnoxious and introducing lots of extra arguments. As far as I know the only place in the Euler code right now that does anything with something called DV is at I/O time.

Dependent variables is not something I made up; it is the common name used for the dependent quantities calculated from the solution state (usually the macro thermodynamic properties of pressure and temperature, but often also includes other quantities), and is used throughout CFD. I could see a CFD user/developer finding the hiding or obfuscation of the DV data and its handling obnoxious, so we should be careful about what we do here in this regard.

[anderson2981]

We need (I would like?) the code to generate fields for things like temperature, pressure that may not be easily computed by post-processing software, without extensive knowledge of the equation of state. Others, like velocity, or 1/rho can easily be left out.

And it's often nice (PC2 feature) to be able to specify any internally stored variable for output. This eases debugging in my experience. For example, PC2 will print the full curvilinear grid metric, jacobian determinant, speed of sound, CFL number, etc, at each dump interval if they are requested.

[inducer]

Dependent variables is not something I made up

Huh, TIL.

As I said, my main objection is that they need to be passed around to avoid computing them twice, which amounts to logistics that the user has to take care of. The difficulty of these logistics creates a temptation to "stick them someplace central and easy to get to". I'm not at all opposed to including widgetry to evaluate them. I just don't like global (or morally global) variables, and I also don't particularly like argument lists that overflow with this stuff for efficiency's sake, although I can live with that much more easily than with global variables.

There are many ways out of this, I would just like us to be purposeful in how we navigate this. At the extreme spectrum of this scale (and I'm not sure I'm advocating for this), it's not hard to make lazy evaluation infrastructure eliminate redundant computation after the fact.

I'm not at all opposed to making it easy to output these to visualization.

[MTCam]

One intended feature of the current EOS is to provide a user-facing interface that returns (potentially dimensional, and identified) dependent variables that can be (are currently) written to file, and a solver-facing interface to compute the (probably non-dimensional) quantities required by the solver.

The user-facing DV, or its handling should never appear inside the solver, or need to be passed around. It is up to the user to grab and/or use the DV as they require. The solver-facing part is intended to be used to compute required quantities in-place, and never to create a buffer that is passed around.

This separation also helps defer the discussion of (non)dimensionalization until it is needed.