New cdms2 results

[doutriaux1]

@gleckler1 @durack1 @dnadeau4 I need feedback here before merging

There are 2 commits.

The first one are the changes necessary to make the test suite pass with the same parameters as before due to the latest cdms2 changes. @dnadeau4 we're using esmf/linear in the failed test, should your changes have affected this?

The second commit are the changes due to switching from esmf/esmpy 7.0 to 7.1. It's a bit worrisome as well.

We need 7.1 in order to get python3 going.

Please let me know how you would like to proceed.

[gleckler1]

@doutriaux1 @dnadeau4 As far as I can tell, the diffs in these results all involving masking and are therefore not surprising and I'd say within the limits of acceptable changes, presuming we are moving in a direction of increased confidence in the results. Note, there are some "global" results, but they are for 'salinity' so masking is built-in (i.e., present even for "global" results). I'm not caught up enough to know what the hesitancy is in merging... again presuming we are moving in the direction of increased confidence.

[durack1]

@gleckler1 agreed, I think we should push ahead to a new stable build/test suite and I can cross-check some of these results independently once we have a candidate for tagging

@doutriaux1 want to merge this?

[doutriaux1]

I'll confirm with @dnadeau4 that it is all expected and will merge.

[dnadeau4]

So I regridded a native E3SM file (cube-sphere) using the same map file as NCO and got the same min/max/mean

myTemperature max()      315.871831959
NCOTemperature max()   315.872
myTemperature min()       194.912899589
NCOTemperature min()    194.913
myTemperature mean()    278.305242769
NCOTemperature mean() 278.305053711

    def test_Regrid2(self):
        #
        # Read E3SM weights
        #
        regridf = readRegridder("/LLNL-Drive/E3SM/map_ne30np4_to_fv129x256_aave.20150901.nc")
        #
        # Read Cube-Sphere data.
        #
        f = cdms2.open("/LLNL-Drive/E3SM/TS_000101_002012.ne30.nc")
        ts = f('TS')
        time = ts.getTime()
        f.close()
        #
        # Regrid using E3SM weights!!
        #
        fvdata = regridf(ts)
        #
        # Compare results!
        #
        lat = fvdata.getLatitude()[0,:]
        lon = fvdata.getLongitude()[:,0]
        grid = cdms2.createGenericGrid(lat, lon, order='xy')
        grid.getAxis(0).id='lon'
        grid.getAxis(1).id='lat'
        myTS = cdms2.createVariable(fvdata[:], axes=[time]+grid.getAxisList(), id="TS")
        #
        # Read their NCO regridder results!
        #
        h = cdms2.open('/LLNL-Drive/E3SM/TS_000101_002012.fv129x256.nc')
        theirTS = h("TS")
        #
        # Is everthing the same?
        #
        self.assertTrue(cdms2.MV2.allclose(myTS, theirTS))

[gleckler1]

@dnadeau4 @doutriaux1 did comparison with NCO include masked/missing data? That is where the problem has been. A good test would be with all land or ocean points missing values.

[dnadeau4]

no, E3SM does not missing/masked data.

[gleckler1]

@dnadeau4 @doutriaux1 @taylor13 If its too complicated to start a new example with NCO using masked data, thats ok we can easily test things internally. ESMF_conservative should "closely" match Karl's regridder (regrid2). It has been all along, except for the case with missing data, so that is the test case we should be shooting for.