EXF not reading/interpolating input as expected

[DaniJonesOcean]

Problem statement and example

I'm attempting to force SO-WISE with a subset of the ERA5 dataset. However, the output of EXF is incorrect. For example, let's look at the 2m air temperature as represented in this binary file ERA5_sowise_tmp2m_degK_issue01_1992. In Matlab, we can view it using:

fid=fopen('ERA5_sowise_tmp2m_degK_issue01_1992','r','ieee-be');
A=fread(fid,'float32');
A3D = reshape(A,[725 249 1464]);
pcolor(A3D(:,:,1)),shading flat,colorbar

which produces the following, presented without any rotation or coordinates, on the ERA5 grid:

That is an example of the kind of field that is given to MITgcm via the `EXF package. However, EXF is not reading and interpolating this field as expected. Here is a snapshot of 2m air temperature from the MITgcm diagnostics package after a single timestep:

It looks like a single longitudinally-varying profile is repeated at each latitude.

Second example: v wind

The issue appears in each of the forcing fields, so it's not just an issue with one file. As a second example, consider the meridional winds from ERA5. In Matlab, we can view it using:

fid=fopen('ERA5_sowise_v10m_issue01_1992','r','ieee-be');
A=fread(fid,'float32');
A3D=reshape(A,[725 249 1464]);
pcolor(A3D(:,:,1)),shading flat,colorbar

which produces the following:

But the output from EXF, via a snapshot from the diagnostics package, appears as follows:

Note that both the pattern and the values are wrong.

Things I've checked

As part of my troubleshooting, I've confirmed the following:

• EXF is expecting a single-precision real number (i.e. exf_iprec = 32 and exf_yftype = RL in data.exf
• The binary files are oriented in the way that MITgcm expects (as confirmed by comparison with a SOSE input field)
• The input field grid parameters are correct in data.exf
• Updated to the latest version of MITgcm and recompiled
• I used a byteswap IO flag at compile time, so I think the endian-ness should be consistent throughout

Ideal behavior

Ideally, EXF would read in the binary file on the ERA5 grid and interpolate onto the SO-WISE grid

More context

Some additional context/details that may be helpful:

• The code used to download the ERA5 subset is available here: https://github.com/so-wise/ERA5
• The build options file is here: https://github.com/MITgcm/MITgcm/blob/master/tools/build_options/linux_ia64_cray_archer2
• The data.exf file I'm currently using is here: https://github.com/so-wise/so-wise-gyre/blob/main/input/data.exf

Thanks in advance for any help or insight you can provide 🌊

[DaniJonesOcean]

I regridded ERA5 onto the SO-WISE grid, so we are no longer using the on-the-fly EXF interpolation at runtime. Unfortunately, that did absolutely nothing. We still have almost exactly the same problem

[DaniJonesOcean]

I have tried every permutation of indices, i.e. (x,y,t), (y,x,t), (t,x,y), and (t,y,x), and none of them worked. Regardless of the order of indices, the diagnostic output from EXF still looks like this:

[DaniJonesOcean]

Note that, having switched to a python-based regridding scheme xESMF, I now use this command for creating the binary files:

var_out.astype('>f4').tofile(os.path.join(fout, filename.replace('.nc', '')))

[DaniJonesOcean]

Fixed! I pushed it to main...because I live dangerously 😎

It had to do with how the grid is specified in data.exf. You have to specify:

field_lat_inc = Ny*0.25

where Ny is the number of latitude points in the forcing dataset.

More detail in this thread:
http://mailman.mitgcm.org/pipermail/mitgcm-support/2023-February/013342.html

[DaniJonesOcean]

How lovely. Closing now!