Questions on using era5_to_int with ERA5 model-level netCDF files

[jjang]

Hello.

I am using the era5_to_int tool to use "ERA5 model-level netCDF files" to create an MPAS initial file. I would appreciate your clarification on the following points:

1. Workflow clarification:
To use ERA5:YYYY-MM-DD_HH for running init_atmosphere, could you confirm whether the following steps are required? It seems that running calc_ecmwf_p.exe is necessary because it generates geopotential height (GHT), which is needed for init_atmosphere. If running calc_ecmwf_p.exe and appending the PRES file to ERA5 are required, it would be helpful to include this information in the README (GitHub - NCAR/era5_to_int: A simple Python script for converting ERA5 model-level netCDF files to the WPS intermediate format)?

% era5_to_int.py 2018-04-14_00
==> output: ERA5:2018_04_14_00

% vi namelist.wps
&share
start_date = '2018-04-14_00:00:00',
end_date = '2018-04-14_00:00:00',
/

&metgrid
fg_name = 'ERA5'
/

% calc_ecmwf_p.exe
==> output: PRES:2018-04-14_00

% cat PRES\:2018-04-14_00 >> ERA5\:2018-04-14_00

2. Error in calc_ecmwf_p.exe with ERA5 model-level data
While running calc_ecmwf_p.exe, I encountered the following error:

Found SOILHGT field in ERA5:2018-04-14_00
munmap_chunk(): invalid pointer

Program received signal SIGABRT: Process abort signal.
Backtrace for this error:
#0 0x14c0937b1dbf in ???
#1 0x14c0937b1d2b in ???
#2 0x14c0937b33e4 in ???
#3 0x14c0937f7c26 in ???
#4 0x14c0937ffcc9 in ???
#5 0x14c0937fff9b in ???
#6 0x405c82 in ???
#7 0x406146 in ???
#8 0x14c09379c24c in ???
#9 0x4017a9 in _start
at ../sysdeps/x86_64/start.S:120
#10 0xffffffffffffffff in ???
Aborted (core dumped)

This issue appears to originate from the following lines in calc_ecmwf_p.F

402 if (allocated(tt)) deallocate(tt)
403 if (allocated(qv)) deallocate(qv)

This error occurs specifically with ERA5 model-level data. In era5_to_int.py, some surface variables are on the 0.25 deg lat-lon grid (1440x721), while model-level variables are on a ~0.281 deg Gaussian grid (1280x640). As a result, temperature (TT) contains a Gaussian grid for 137 model levels and a lat-lon grid for 2m temperature. But calc_ecmwf_p.F assumes that nx and ny are the same for both cases. For example, "tt" is allocated for the number of model levels plus one extra level for surface.

236 if (.not. allocated(tt)) then
237 allocate(tt(ecmwf_data%nx,ecmwf_data%ny,n_levels+1)) ! Extra level is for surface
238 tt ( : , : , : ) = 0.0
239 end if
240
241 if (nint(ecmwf_data%xlvl) >= 1 .and. &
242 nint(ecmwf_data%xlvl) <= n_levels) then
243 tt ( : , : , nint(ecmwf_data%xlvl) ) = ecmwf_data%slab
244 else if (nint(ecmwf_data%xlvl) == 200100) then
245 tt ( : , : , n_levels+1 ) = ecmwf_data%slab
246 end if

It seems necessary to modify calc_ecmwf_p.exe for ERA5 model-level data, specifically to read temperature (TT) separately for the model levels and the surface. (Please see the attached file)


Could you clarify the procedure for converting ERA5 model-level netCDF files to the WPS intermediate format for MPAS initialization and update the code to handle this grid mismatch?


Thank you so much for your help.
Jihyeon

 

[mgduda]

I think your assessment of the issue is correct: in the calc_ecmwf_p code, we've assumed that the surface temperature and surface specific humidity fields have the same horizontal dimensions as the upper air fields. Although I haven't tested them, your proposed changes to the calc_ecmwf_p.F code seem reasonable. Alternatively, since the new ttsfc and qvsfc are not actually used, it could be simpler to just ignore the TT and SPECHUMD fields at level 200100.0 in calc_ecmwf_p.

 

[jjang]

Hi Michael,

Thank you so much for your quick response. Yes, I agree it would be simpler to ignore TT and SPECHUMD fields at the surface level in calc_ecmwf_p.F.

Jihyeon