Fix indexing for tau in gw_front subroutine

[whannah1]

This fixes a simple bug identified by Jim Foucar while porting the GW schemes to C++.

Fixes #7845

[non-BFB]

[whannah1]

The plot below shows the result of a 1-month test without the fix (left) and with the fix (right).

NOTE - the color bar for the frontal gw scheme tedenencies uses non-uniform spacing. For the difference plot the color levels on each side of zero are as follows:
0.01,0.02,0.05,0.1,0.2,0.4,0.8,1.6,3.2,6.4

From my experience in recent years focused on issues with our QBO we know that the frontal scheme provides too much forcing on the QBO - so the reduction of magnitude in the tropical stratosphere is a welcome change. Other changes in the works will provide further reductions to the tropical tendencies that are erroneously induced by gradients associated with topography.

The high-latitude changes are more substantial, but it is unclear how much of this is just noise from diverging weather.

[jgfouca]

Thanks for taking a deeper look at this to see if the climate changes made sense! I rebased and updated the C++ to match the fixed fortran.

[jjbenedict]

I only checked the sign change in the Fortran code. The change seems warranted, and clearly gives a different answer in the test simulation. Variable fav is set in gw_front_init and is defined as "Average value of gaussian over gravity wave spectrum bins, multiplied by background source strength (taubgnd)". Based on my limited search, fav is only a function of wavenumber. I wondered if fav is symmetric, such that the sign in front wouldn't matter... but apparently it is not symmetric. In any case, the code modifications seems justified.

[whannah1]

I did a longer 1-year test on Chrysalis and the results look very consistent

[whannah1]

I'm going to continue for another 4 years and run the E3SM diags

[whannah1]

I ran a pair of 5-year runs to examine the impact of this bug on the long-term solution, and there are some small, but systematic changes, especially in polar regions. The sea-level pressure map is one area that this crops up - the various zonal mean plots are another good one to look at. Despite those changes, the TOA energy fluxes don't seem to be qualitatively affected - so while this is an "answer changing" fix, it's not the sort of change that would necessitate a major retuning.

E3SM Diags

• control => model_vs_obs
• bug fix => model_vs_obs
• bug fix => model_vs_model diagnostics

[whannah1]

Adding @crterai @xuezhengllnl and @wlin7 for review of this "slightly answer changing" bug fix.

In a recent discussion of this the issue how this might impact the HR runs came up. It seems that we might want to wait to merge this until after a tag has been created that reflects the state of the model that was used for the HR simulation campaign. Although, I'm a bit confused about whether that has already happened yet or not.

[rljacob]

The freeze on science changes for production configs is in effect. So yes it will be up to the v3HR, BlueTip and HES leads on if they want this in 3.1.

[bpbond]

Thanks for the clear documentation and assessment.

[whannah1]

Jack Chen at NCAR is now insisting that this is NOT a bug... but his reasoning would imply that changing the code should not lead to any real change in the model.. but this doesn't make sense with how things are coded. So I need to take some time to examine the NCAR code and check a few things.

[whannah1]

After further consideration I'm leaning towards concluding that this was not actually a bug. I'm still unclear on several details, but I'm going to assume that all the differences I found in my tests were just a fluke, and that the systematic differences just showed up by chance. Therefore, I'm going close the PR and potentially revisit in the future.

[jgfouca]

I'm confused. I thought someone said yesterday that this was a bug that someone at NCAR fixed in their version of cam?