ERA-5 remapping weights files flip longitude and latitude axes

[rmholmes]

My first test run with the https://github.com/COSIMA/1deg_era5_iaf repo has winds (and probably all the forcing fields) flipped in the longitude and latitude direction.

Jan 1981 zonal wind stress for ERA-5 (left) and JRA-55 (right);

This is likely a remapping weights issue, perhaps with the https://github.com/COSIMA/esmgrids/blob/master/esmgrids/era5_grid.py script?

[aekiss]

Actually, it appears from the phantom Australia in the North Atlantic and Africa in the Pacific that the data is flipped only in latitude, and offset (not flipped) in longitude.

ERA5 files, e.g. /g/data/rt52/era5/single-levels/reanalysis/10u/1979/10u_era5_oper_sfc_19790101-19790131.nc, have the latitude running in reverse from 90 to -90, which this np.flipud is apparently intended to deal with, but that doesn't seem the right thing to do if the data is not also being flipped.

esmgrids/esmgrids/era5_grid.py

Line 17 in 514b560

y_t = np.flipud(f.variables['latitude'][:])

ERA5 longitude starts at -180 (whereas JRA55-do starts at 0), which seems about right to explain the offset.

[rmholmes]

It looks like some reengineering of make_remap_weights.py and era5_grid.py is needed. Nic must have a version of make_remap_weights.py with the ERA5 options sitting around somewhere - but I can't find it. The changes look reasonably straightforward though - I can have a bash if no-one else is working on this?

For the latitude issue I could try just not flipping the latitude in era5_grid.py. For the longitude changes I could try modifying x_t in era5_grid.py. Otherwise understanding the ESMF_RegridWeightGen script will be neccessary.

[aekiss]

@nichannah's weights in /g/data/ik11/inputs/access-om2/input_20210915/common_1deg_era5 appear to have been generated by /g/data/v45/nah599/access-om2/tools/make_remap_weights.*.
I've pushed these into this PR: COSIMA/access-om2#258

[aekiss]

I'll be busy with other things today so feel free to have a go at fixing this issue. The first thing I'd try is omitting np.flipud and seeing what happens.

[aekiss]

CI tests failed on the PR. https://github.com/COSIMA/access-om2/runs/5964911440?check_suite_focus=true
I guess Nic didn't commit it because it had bugs?
I'll see if this is easily fixed.

[aekiss]

fixed bug that caused CI to fail.

[aekiss]

there are some tips on remapping here https://github.com/COSIMA/access-om2/wiki/Technical-documentation#creating-remapping-weights
and here https://github.com/COSIMA/access-om2/wiki/Tutorials#3-changing-the-oasis-remapping-files

[aekiss]

might need to be careful what version of ESMF_RegridWeightGen we use - see COSIMA/access-om2#216

[rmholmes]

Thanks @aekiss.

I've successfully generated remapping weights using module load esmf (which I think according to that issue should be ok for anything but the 1/10th-degree) without changing anything and am running a test (TBC).

If I try to remove the np.flipud on the latitude then a run into a check made in the make_corners routine in base_grid.py - it appears that the corner finding routines need latitude to be ordered south -> north.

We obviously don't want to derive new ERA-5 forcing files with latitude flipped. So it seems like the next step would be to rewrite the corner finding routines so that they work in both directions?

[aekiss]

thanks @rmholmes, that sounds sensible.

FYI I've put an executable using Russ' tripole bug fix here:
/g/data/ik11/inputs/access-om2/bin/ESMF_RegridWeightGen_f536c3e12d
and updated make_remap_weights.* in COSIMA/access-om2#258 to use it (as yet untested!)

[rmholmes]

Just a recap from my progress today:

If I remove the np.flipud in era5_grid.py and comment out the assert checks in make_corners (in base_grid.py) then the code succesfully creates remapping weight files, but nothing is changed. Similarly, if I add 90, 180 or 360 to x_t in era5_grid the files are created successfully but nothing is changed.

The code in esmgrids/base_grid.py seems apriori designed for dealing with latitude ordered south to north. Without this ordering, dy is negative which doesn't seem to be what is wanted. However, I don't have a good enough understanding of what the code is doing to figure out what should be done to fix things.

It is frustrating that the ERA-5 latitude data is ordered this way - doesn't seem to serve any practical purpose except to unneccesarily make things difficult.

[aekiss]

Thanks for all these experiments. I'll raise it at today's TWG meeting.

[aidanheerdegen]

Try this one
/scratch/v45/aph502/era5_mom10_wts.nc
I've tested it, and it gives the correct orientation.