[BUG/ISSUE] Incorrect regridding if file latitude data ends in +/- 90

[sdeastham]

Describe the bug If data is read from a file where the first or last latitude is +/- 90 degrees (as listed in the file's "lat" variable), then the data can be regridded badly. This is clearest when running at very high resolutions.

To Reproduce Steps to reproduce the behavior:

1. Run GCHP at C180 with MERRA-2 input data
2. Wait for failure in wet deposition, due to a negative box height (resulting from bad met read-in). Specifically, conditions at the poles end up outside of the possible range of temperatures (over 400 K) and pressures (over 10,000 hPa)

Expected behavior MERRA-2 meteorological data should be read correctly.

Required information

• GEOS-Chem/GCHP version 12.6.0
• gfortran 8.2.0
• OpenMPI 3.1.1
• NetCDF 4.1.3
• Running on Odyssey (huce_intel)
• Error produced with both 16 nodes or 20 nodes (24 cores each)

Additional context I suspect this error will affect any lat/lon input file which has latitudes including +/- 90.

[lizziel]

Ben Auer (GMAO) is able to replicate the issue. Here is his response:

I was able to reproduce this. Ingesting the MERRA2 inputs on a 576x361 lat-lon grid with the lons going from -90 to 90 and conservatively regridding to c90 I see the temperature going to 400 degrees, clearly unphysical. Bilinear regridding seems to work fine in that the temperatures are in a the reasonable range.

Here is a minmax of the temperatre array across 6 pe’s with the conservative: bma minmax 184.0073 308.4941 bma minmax 178.6505 386.3013 bma minmax 185.3079 310.2529 bma minmax 178.0578 309.8543 bma minmax 177.3138 306.4670 bma minmax 159.5444 422.1973

and with the bilinear bma minmax 159.5366 300.5818 bma minmax 177.3158 306.4455 bma minmax 178.0620 309.8484 bma minmax 184.0130 308.4452 bma minmax 185.3194 310.2030 bma minmax 178.6491 291.9043

two of the faces are off.

Looking into this more, for these types of files I believe the corners are being computed wrong. It takes the latitude spacing between the first and second values and adds half that to the last value to get the corner so you end up with the corner lats looking like this! bma corner -90.2500000000000 90.2500000000000 bma corner -90.2500000000000 90.2500000000000 bma corner -90.2500000000000 90.2500000000000 bma corner -90.2500000000000 90.2500000000000 bma corner -90.2500000000000 90.2500000000000 bma corner -90.2500000000000 90.2500000000000

Seb, when you shifted the first and last centers, this unintentionally “fixed” the corners as it now computes the latitude spacing as ½ of the correct value and the corners end up being -90 and 90.

I will push fix for this and put some logic in when we detect if the grid is pole center to correct the first and last corner so they don’t go out of bounds. Thanks for finding this.

[lizziel]

There is a GEOS-ESM/MAPL pull request for a fix here: https://github.com/GEOS-ESM/MAPL/pull/72

However, Ben most recently wrote this: Maybe it should just a be general protection, after computing the corners, whatever the centers, something like this that it always applies so the corners are always bounded by -90,90

         if (this%lat_corners(1) < -90) this%lat_corners(1)=-90
         if (this%lat_corners(jm+1) > 90) this%lat_corners(jm+1)=90

I (Lizzie) will test a 1-month GCHP benchmark with 12.6.0 plus this MAPL fix to see if it makes any improvements on the differences we have seen in the benchmarks since updating to the new MAPL and ESMF regridding (12.5 and 12.6).

[lizziel]

This update appears to have no impact on running GCHP with GEOS-FP fields but does correct problems when running with MERRA2. This fix will be included in 12.6.1.

[yantosca]

Now included in GCHP 12.6.1, released on 28 Oct 2019.