Need help to solve the issue "---- ERROR: Could not find matching time in input file met_em.d01.2024-09-29_00:00:00.nc"

N

NGGANESHI

New member
I am trying to run the "./real.exe"
Got the error

****
Domain 1: Current date being processed: 2024-09-29_00:00:00.0000, which is loop # 1 out of 3
configflags%julyr, %julday, %gmt: 2024 273 0.00000000
d01 2024-09-29_00:00:00 Yes, this special data is acceptable to use: OUTPUT FROM METGRID V4.6.0
d01 2024-09-29_00:00:00 Input data is acceptable to use: met_em.d01.2024-09-29_00:00:00.nc
metgrid input_wrf.F first_date_input = 2024-09-29_00:00:00
metgrid input_wrf.F first_date_nml = 2024-09-29_00:00:00
1 input_wrf: wrf_get_next_time current_date: 2024-09-29_00:00:00 Status = -4
d01 2024-09-29_00:00:00 ---- ERROR: Could not find matching time in input file met_em.d01.2024-09-29_00:00:00.nc
NOTE: 1 namelist vs input data inconsistencies found.
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 1347
NOTE: Please check and reset these options
-------------------------------------------
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 1347
NOTE: Please check and reset these options
-------------------------------------------
STOP wrf_abort

****

geogrid ungrib and metgrid run is successful but still I am getting this error

namelist file attached for the reference.

Please help to solve the issue
 

Attachments

Hi,
From your real/wrf running directory, can you issue

Code: 
ls -ls met_em* >& met.txt

and attach the met.txt file? Can you also check that you're able to use some sort of netCDF viewer/reader to view your met_em* files (e.g., ncview or ncdump). Thanks!
 
Thanks. met.txt attached to the email.
*****
ncdump -h met_em.d01.2024-09-29_00:00:00.nc
netcdf met_em.d01.2024-09-29_00\:00\:00 {
dimensions:
Time = UNLIMITED ; // (0 currently)
DateStrLen = 19 ;
variables:
char Times(Time, DateStrLen) ;

// global attributes:
:TITLE = "OUTPUT FROM METGRID V4.6.0" ;
:SIMULATION_START_DATE = "2024-09-29_00:00:00" ;
:WEST-EAST_GRID_DIMENSION = 150 ;
:SOUTH-NORTH_GRID_DIMENSION = 130 ;
:BOTTOM-TOP_GRID_DIMENSION = 34 ;
:WEST-EAST_PATCH_START_UNSTAG = 1 ;
:WEST-EAST_PATCH_END_UNSTAG = 149 ;
:WEST-EAST_PATCH_START_STAG = 1 ;
:WEST-EAST_PATCH_END_STAG = 150 ;
:SOUTH-NORTH_PATCH_START_UNSTAG = 1 ;
:SOUTH-NORTH_PATCH_END_UNSTAG = 129 ;
:SOUTH-NORTH_PATCH_START_STAG = 1 ;
:SOUTH-NORTH_PATCH_END_STAG = 130 ;
:GRIDTYPE = "C" ;
:DX = 15000.f ;
:DY = 15000.f ;
:DYN_OPT = 2 ;
:CEN_LAT = 33.00002f ;
:CEN_LON = -79.f ;
:TRUELAT1 = 30.f ;
:TRUELAT2 = 60.f ;
:MOAD_CEN_LAT = 33.00002f ;
:STAND_LON = -79.f ;
:POLE_LAT = 90.f ;
:POLE_LON = 0.f ;
:corner_lats = 23.78065f, 40.96011f, 40.96011f, 23.78065f, 23.772f, 40.94821f, 40.94821f, 23.772f, 23.7159f, 41.02873f, 41.02873f, 23.7159f, 23.70727f, 41.01681f, 41.01681f, 23.70727f ;
:corner_lons = -89.59726f, -92.71286f, -65.28714f, -68.40274f, -89.66803f, -92.80371f, -65.19629f, -68.33197f, -89.58783f, -92.72858f, -65.27142f, -68.41217f, -89.65854f, -92.81952f, -65.18048f, -68.34146f ;
:MAP_PROJ = 1 ;
:MMINLU = "MODIFIED_IGBP_MODIS_NOAH" ;
:NUM_LAND_CAT = 21 ;
:ISWATER = 17 ;
:ISLAKE = 21 ;
:ISICE = 15 ;
:ISURBAN = 13 ;
:ISOILWATER = 14 ;
:grid_id = 1 ;
:parent_id = 1 ;
:i_parent_start = 1 ;
:j_parent_start = 1 ;
:i_parent_end = 150 ;
:j_parent_end = 130 ;
:parent_grid_ratio = 1 ;
:sr_x = 1 ;
:sr_y = 1 ;
:NUM_METGRID_SOIL_LEVELS = 4 ;
:FLAG_METGRID = 1 ;
:FLAG_EXCLUDED_MIDDLE = 0 ;
:FLAG_SOIL_LAYERS = 1 ;
:FLAG_SNOW = 1 ;
:FLAG_PSFC = 1 ;
:FLAG_SM000010 = 1 ;
:FLAG_SM010040 = 1 ;
:FLAG_SM040100 = 1 ;
:FLAG_SM100200 = 1 ;
:FLAG_ST000010 = 1 ;
:FLAG_ST010040 = 1 ;
:FLAG_ST040100 = 1 ;
:FLAG_ST100200 = 1 ;
:FLAG_SLP = 1 ;
:FLAG_SNOWH = 1 ;
:FLAG_SOILHGT = 1 ;
:FLAG_UTROP = 1 ;
:FLAG_VTROP = 1 ;
:FLAG_TTROP = 1 ;
:FLAG_PTROP = 1 ;
:FLAG_PTROPNN = 1 ;
:FLAG_HGTTROP = 1 ;
:FLAG_UMAXW = 1 ;
:FLAG_VMAXW = 1 ;
:FLAG_TMAXW = 1 ;
:FLAG_PMAXW = 1 ;
:FLAG_PMAXWNN = 1 ;
:FLAG_HGTMAXW = 1 ;
:FLAG_MF_XY = 1 ;
:FLAG_LAI12M = 1 ;
:FLAG_SNOALB = 1 ;
:FLAG_CON = 1 ;
:FLAG_VAR = 1 ;
:FLAG_OA1 = 1 ;
:FLAG_OA2 = 1 ;
:FLAG_OA3 = 1 ;
:FLAG_OA4 = 1 ;
:FLAG_OL1 = 1 ;
:FLAG_OL2 = 1 ;
:FLAG_OL3 = 1 ;
:FLAG_OL4 = 1 ;
:FLAG_VAR_SSO = 1 ;
}


*****
 

Attachments

Thanks for sending that. Hmm - this is odd. Can you share your met_em* files with me? They likely will be too large to attach here, so see the home page of the forum for instructions on sharing large files. Thanks!
 
@kwerner @NGGANESHI

Was there ever a solution for this issue? I have the exact same issue. I was able to run ungrib, geogrid, and metgrid successfully. But when it comes to real.exe, I get the same error message. I have determined the issue is probably related to WPS. Because on a different computer with a compiled version of WPS, I was able to use the generated met_em* files, and real.exe worked fine.

However, I got no error messages in my WPS or WRF build on the current computer. I even tried building WPS with the compile option --build-grib2-libs. But it still didn't work.
On the computer where I don't get an error, it is Ubuntu based.
On the computer where I do get an error, it is Fedora based.
However, in the past, I have been able to run WRF successfully on both computers.

The only clue I have seen is the following output in the WPS compile, that is shown for the WPS build that does not generate the error downstream in real.exe. The warning below doesn't show in the build that does generate the error in real.exe:

cio.c: In function ‘bn_seek_’:
cio.c:151:31: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘off_t’ {aka ‘long int’} [-Wformat=]
151 | printf(" lseek return=%d, *mode=%d\n", i, *mode);
| ~^ ~
| | |
| int off_t {aka long int}
| %ld

I also see this a few times:
ar: `u' modifier ignored since `D' is the default (see `U')
 
I have determined the issue is likely with Metgrid. Despite Metgrid claiming that the run was successful, the resulting file size is much much smaller than what the file size is for a met_em* file that does not produce the error in real.exe. 15271 vs 7346297 bytes. Also I checked the files with ncdump -h, and I see the difference right at the top:

File that causes real.exe to fail:
dimensions:
Time = UNLIMITED ; // (0 currently)
DateStrLen = 19 ;
variables:
char Times(Time, DateStrLen) ;

// global attributes:
:TITLE = "OUTPUT FROM METGRID V4.6.0" ;
:SIMULATION_START_DATE = "1988-01-01_00:00:00" ;
:WEST-EAST_GRID_DIMENSION = 110 ;
File that causes real.exe to work:
dimensions:
Time = UNLIMITED ; // (1 currently)
DateStrLen = 19 ;
west_east = 109 ;
south_north = 109 ;
num_metgrid_levels = 30 ;
num_st_layers = 4 ;
num_sm_layers = 4 ;
south_north_stag = 110 ;
west_east_stag = 110 ;
z-dimension0012 = 12 ;
z-dimension0016 = 16 ;
z-dimension0021 = 21 ;
variables:
char Times(Time, DateStrLen) ;
float PRES(Time, num_metgrid_levels, south_north, west_east) ;
PRES:FieldType = 104 ;
PRES:MemoryOrder = "XYZ" ;
PRES:units = "" ;
PRES:description = "" ;
PRES:stagger = "M" ;
PRES:sr_x = 1 ;
PRES:sr_y = 1 ;

I really appreciate the help as soon as possible on this issue.

Attached is my WPS log.compile file.
 

Attachments

I have built WPS and WRF successfully using GNU Fortran (GCC) 13.2.0.
I have built WPS and WRF successfully using GNU Fortran (GCC) 14.2.1. (However, this is where I see the above bug while running real.exe due to the failure of Metgrid to process the data correctly).

This means that there is likely some type of hidden WPS compile error that happens with GNU Fortran (GCC) 14.2.1. I have seen some discussion from others on GitHub related to some differences in the compilers that may case issues while building WPS or WRF. I saw that some fixes were made, but I guess there is still this hidden problem.

I don't have the computer skillz to figure out how to fix this issue, so hopefully someone else can investigate. Maybe I just messed up the build of WPS/WRF when trying it with the GNU Fortran (GCC) 14.2.1. But still, I think compile of WPS should have failed, before I get to real.exe, and find out then.

Attached is my WPS log.compile file for GNU Fortran (GCC) 13.2.0. The one for GNU Fortran (GCC) 14.2.1 is provided in the post above. For GNU Fortran (GCC) 14.2.1, I also used the --build-grib2-libs option, but I also tested it without this option, and I got the real.exe error as well.

Josh
 

Attachments

Hi Josh,
Apologies for the long delay in response while our time has been out much over the past few weeks, due to conferences and holidays. Thank you for your patience. Are you able to use V13.2.0 of GNU, instead of V14.2.1? GNU is a free compiler, so you should be able to try to install it on either system.
 
Yes, V13.2.0 of GNU works. It allows WPS and WRF to compile correctly, and there are no runtime errors.

Note that V14.2.1 of GNU did compile WPS and WRF without any error messages, but the generated met_em* files are not written correctly when using WPS utilities compiled by this GNU version. Thus real.exe fails as well. I believe the problem is that WPS doesn't compile right with V14.2.1 of GNU, even though it doesn't show there were any error messages. The error shows up during runtime.

Josh
 
Hi Josh,

I'm having exactly the same problem. I installed WRF and its utilities using the WRF-MOSIT package: GitHub - HathewayWill/WRF-MOSIT: This BASH script installs all the required libraries, packages, software, dependencies, etc for the Weather Research & Forecasting model suite.

which installs everything WRF needs to be run. It also builds WRF and WPS so you can run a real case. However, when I arrived to the point of executing metgrid (I'm following a real case tutorial: ARW Online Tutorial), it fails to create the met_em_ files. I already contacted the package developer to see if he is aware of this problem. I tried to make sure if the problem could be a mismatch between GFS variable name, but I seriously doubt it.

I'm currently using Debian 13 Trixie in my laptop, and the version of the GNU is:
GNU Fortran (Debian 14.2.0-19) 14.2.0
Copyright (C) 2024 Free Software Foundation, Inc.

What would you reccomend? I'm thinking of compiling WRF first and then WPS using an older version of GNU.

Thanks a lot,

Ivan
 
You must log in or register to reply here.
Back
Top