Feature/ufs case gen exact mode

[dustinswales]

This PR adds back in the "exact-mode" for the UFS case generation.

There is a new argument to the UFS cases generation scripts, exact_mode (-ext), that sets a different path through the code that derives the SCM forcings using diagnostic dynamic tendencies from UFS history files.

To run in exact-mode one needs to run the UFS with additional diagnostic fields, set in the diag_table. If a user requests exact-mode, but does not provided the correct fields, the forcings will be computed using the UFS state (e.g approximate mode). Additionally, in these cases, the following warning message is provided:

@grantfirl There is a "stub" in place for computing the total tendencies (i.e. DVar/Dt = dVar/dt + udVar/dx + vdVar/dy), in addition to the current formulation, DVar/Dt = dVar/dt. This will need to be expanded, or reworked with your additions.

[dustinswales]

@hertneky All should be working (I'm done making changes, I promise:))

[grantfirl]

@dustinswales @hertneky I added yet another method for calculating geostrophic winds on a larger stencil for which the geostrophic balance assumption should be more valid. The previous method only used 3 or 5 points in either direction. Now, it uses as many as necessary to achieve a mean Rossby number smaller than a critical value set in the script. As noted in my comment on Slack, this still doesn't fix the oscillation/turning of the winds. I think that when SCM-modeled winds are significantly different than geostrophic, we'll get the oscillation/turning. I think that this just means that the modeled/calculated Coriolis force is stronger than the pressure gradient force and therefore we should be assuming geostrophic balance for that case/time.

There is a in-script flag use_actual_geos_wind that is set to False by default. Setting this to true activates the new functionality. There is another flag use_oro_for_geos_wind that could be important for calculating geostrophic winds around strongly-sloping terrain. I've seen sources differ on whether the surface geopotential should be taken into account when calculating the geostrophic winds or not, so I'm leaving an in-script option. The default is false, so geostrophic winds are calculated on the base geoid.

Two other script-level "constants" are the critical Rossby number, or the Rossby number below which geostrophic balance can be assumed. Dynamicists say that geostrophic balance is valid when Ro << 1, but that is, of course, not specific enough for code! Therefore, I have a constant set to 0.1 by default. A lower number needs more grid points for a given horizontal wind to achieve "balance". There is just a check in the code if the chosen grid point is too close to the poles to be able to have enough grid points to add on to the horizontal stencil. This could be made more robust, but it is OK for now, I guess.

If use_actual_geos_wind is kept False, the geostrohpic wind is just calculated as the mean wind for each level over the chosen point's neighbors (after Brown et al. (2002) or dal Gesso (2015)). This just assumes that the averaged modeled wind is close to geostrophic balance (which isn't a great assumption, since Rossby numbers can be well over 1, but it is useful nevertheless). The geostrophic wind should go to zero near the surface, so I have a simple linear return-to-zero in the PBL, below the PBL_top_for_geos script-level variable.

[grantfirl]

@dustinswales @hertneky For testing for the release, I don't think that we need to test everything. Perhaps just re-test with wind nudging on (-wn) vs geostrophic forcing using modeled profiles (the default now when -geos is specified). We can keep fm=2 and vm=2, which should also be defaults, IMO.