Error while running ungrib.exe with IFS global data

[ccalvosa]

Hi all,
I'm trying to run MPAS with IFS global data (0.1º horizontal resolution and pressure levels). In the last days, I have had several issues with ungrib.exe, that I have been solving. The main problems were about specific surface variables: SST, SD, CI, and LSM. These variables are not a continuous field and the ungrib.exe has an issue with this. However, I've seen some posts about this problem in this forum and solved it.

Currently, the ungrib.exe runs correctly and produces the intermediate files. But, when I want to build the init files (the interpolation of analysis and static fields) I have an error about LANDSEA:
----------------------------------------------------------------------
Beginning MPAS-init_atmosphere Error Log File for task 20 of 576
Opened at 2023/10/28 15:07:36
----------------------------------------------------------------------

ERROR: ********************************************************************************
ERROR: LANDSEA field not found in meteorological data file IFS:2023-10-18_00
CRITICAL ERROR: ********************************************************************************
Logging complete. Closing file at 2023/10/28 15:07:36

So... I'm trying again to include the land-sea mask in the intermediate files. However, I have the same error with the other surface variable which I removed:

Copen: File = /scratch/spcc/BCs_MPAS/ec.oper.an.sfc.128_172_lsm.regn1280sc.20231018.grb
Fortran Unit = 0
UNIX File descriptor: 3

----------------------------------------------------
rec GRIB GRIB Lvl Lvl Lvl Time Fcst
Num Code name Code one two hour
----------------------------------------------------
End-of-record mark (7777) not found 0
Sec0(1) = 26214508 0
1 172 LSM 1 0 0 2023-10-18_00:00 + 00
*** stopping in findgrib in gribcode ***\n
\tI could not find the GRIB string in the input file
\tafter testing the first 100,000 bytes.
\tThe file may be corrupt or it is not a GRIB file.
\tPerhaps a gzipped GRIB file or netcdf?\n
findgrib

Although I'm running MPAS in the ECMWF supercomputer, I've downloaded the IFS analysis files from RDA ds113.1 dataset. Is it possible to solve this problem?

Thank you in advance.

Carlos C.

 

[satjemkes]

Dear Carlos

could you help me with explaining the problems you encountered with ungrib.exe and how you resolved this.
Background: I am trying to generate the WRF input files from the T1279 spectral truncation of ECMWF operational forecast.
WPS 4.3.3 version
first problem was that the code ran into problem with Grib2 file or date problem.
The suggestion was to specify the record length in the namelist.wps file
ec_rec_len = 2621450

This did not solve the problem as it created another issue: Grid ID is 255 Onlz WAFS grids 37-44 are supported

this sounds like that the record length is not correct as when i run same software for T799 special truncation (same day-time) all seems to work fine

If you have solved the above problems please let me know.

Processing the atmosphere grib files is fine, but the surface files not.

thanks
stephen

 

[kwerner]

@satjemkes
Please post your question as a separate new thread. The two problems are not identical, and in an effort to keep posts organized and easier to read, we want to keep issues separate. Thanks!

 

[haini]

I'm using ds113.1 to drive WRF and running the ungrid.exe program produces the following error.
#############
End-of-record mark (7777) not found1962934390
Sec0(1) = 26214508 0
*** stopping in findgrib in gribcode ***\n
\tI could not find the GRIB string in the input file
\tafter testing the first 100,000 bytes.
\tThe file may be corrupt or it is not a GRIB file.
\tPerhaps a gzipped GRIB file or netcdf?\n
findgrib
#########
Check out previous posts. Modified namelist file and deleted unavailable data *isor*, etc., and the reported error persists.Thank you for your answer.

 

[Ming Chen]

To run ungrib program for ds113.1, a new namelist is needed for namelist record &ungrib:

ec_rec_len = 26214508,

This is needed for both upper air and surface data (note also that NCAR/CISL has provided this data differently than the previous).

However this fix does not work for all surface fields. In particular there are 13 of them that need to be removed before running the ugrib program, and these are *cvl* *cvh* *ci* *sdfor* *sdor* *isor* *anor* *slor* *lsm* *_al* *_slt* *_sd* *_sstk*.


As one may notice, we have to remove sstk from surface fields, but there is another field (skt) that contains water temp, and we hope it is just as good.

Please try and let me know whether the above approaches work. Thanks.

 

[haini]

Thank you for the answer, this does not solve my problem. I noticed that the ds113.1 dataset only includes the 6-hour surface forecast field. And I checked the file information and there is no height layer. I am using WPS version 4.1.

 

[haini]

At first I wanted to use the forecast data from this website "ECMWF Data Store (ECPDS)" to drive WRF, the data format is grib2. When I run it, I get an error that VTABLE is not available, and the g2.print.exe file can't be opened for the forecast data. Is there a solution to this problem?

 

[ccalvosa]

Hi Ming,

I tried removing all the fields that do not work with the new namelist record. However, MPAS needs the LANDSEA mask to work but I don't know how to add it in the Intermediate Files.

Thanks,

Carlos C.

 

[Ming Chen]

Hi Carlos,

Landsea mask values in ECMWF data lie between 0 and 1, which is different to WRF static data that have values of either 0 (grid box is fully covered by water) or 1 (grid box is fully covered with land). Please see the website below that describes landsea mask in ECMWRF:

Section 2.1.3.1 Land-Sea Mask - Forecast User Guide - ECMWF Confluence Wiki

confluence.ecmwf.int

I am suspicious that Landsea mask values in IFS global data follow the rule of ECMWF data, i.e., its values could be between 0 and 1. This might give rise to troubles when we run MPAS initialization.

Sorry that I don't have a solution yet how to handle this issue ....