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

 

[otitov]

Hi Jihyeon,

I am following very same workflow and I got a bit different error in calc_ecmwf_p.exe with ERA5 model-level data:

  135         3.757813  0.9950029850
  136         0.000000  0.9976300001
  137         0.000000  1.0000000000

Reading from ERA5 at time 2024-02-08_00
Found PSFC field in ERA5:2024-02-08_00
Found SOILHGT field in ERA5:2024-02-08_00
double free or corruption (out)

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x87f51623e59 in ???
#1  0x87f51622e75 in ???
#2  0x87f5124532f in ???
        at ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
#3  0x87f5129eb2c in __pthread_kill_implementation
        at ./nptl/pthread_kill.c:44
#4  0x87f5129eb2c in __pthread_kill_internal
        at ./nptl/pthread_kill.c:78
#5  0x87f5129eb2c in __GI___pthread_kill
        at ./nptl/pthread_kill.c:89
#6  0x87f5124527d in __GI_raise
        at ../sysdeps/posix/raise.c:26
#7  0x87f512288fe in __GI_abort
        at ./stdlib/abort.c:79
#8  0x87f512297b5 in __libc_message_impl
        at ../sysdeps/posix/libc_fatal.c:134
#9  0x87f512a8ff4 in malloc_printerr
        at ./malloc/malloc.c:5772
#10  0x87f512ab11f in _int_free_merge_chunk
        at ./malloc/malloc.c:4676
#11  0x87f512addad in __GI___libc_free
        at ./malloc/malloc.c:3398
#12  0x572164fcd663 in ???
#13  0x572164fcdcd4 in ???
#14  0x87f5122a1c9 in __libc_start_call_main
        at ../sysdeps/nptl/libc_start_call_main.h:58
#15  0x87f5122a28a in __libc_start_main_impl
        at ../csu/libc-start.c:360
#16  0x572164fc9354 in ???
#17  0xffffffffffffffff in ???
Aborted (core dumped)

First of all I would like to discard the possibility of this error due to used compiler. I used GNU Fortran (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0. Which compiler did you use?