Problem in metgrid? Running real.exe throws error NUM_METGRID_SOIL_LEVELS must be greater than 1

[saschm]

Hi,
I am relatively new to WRF. For a project I want to run WRF with ERA5 data as boundary conditions. geogrid.exe, ungrib.exe and metgrid.exe work without errors, but when I want to run real.exe, it (correctly) complains, that there is only one soil level in the met_em files. However I don't know why, as I did practically the same run two weeks ago without problems, there should be 4 soil levels. Can you please point me to where I might solve that? My assumption was, that it is related to metgrid.exe, but I am not sure.
Please let me know, which other information you might need, I try to get it to you.
Best regards,
Sascha

 

[kwerner]

Hi,
Can you check your met_em* output to see if there are any soil levels?

 

[daankivits]

I have exactly the same issue! It seems as though since the DHS data center move by ECWMF the ERA5 data downloaded through the CDS API has an inconsistent amount of soil levels: sometimes the data has 4 levels, but sometimes 1. The distribution over the files seems to be completely random.

Is there an option somewhere to run WRF-CHEM with only 1 soil level? It now crashes at real.exe with the following error:

I have included the API request python scripts I am using as a reference, maybe something is going wrong there? I also dropped this question at the ECWMF support, to be sure it is not their API that is causing the issue.
Best regards,
Daan

 

[kwerner]

Okay, so it sounds like this is an issue with the data provider. I hope the support team are able to help. If you determine a workable solution, please post it here for future users who run into this problem, if you don't mind.

 

[daankivits]

I have contacted the ECMWF support, and after thoroughly checking the .grb1 and .grb2 files that are created through the aforementioned API requests, it became clear that this is indeed a WRF issue, and not an issue with the ERA5 data.
After checking the ungrib_sfc.<run_name>.log I found out that all the SFC:<yyyy-mm-dd_HH> files have an inconsistent file size, indicating that WRF processed the GRIB files incorrectly. I attached the ungrib_sfc.<run_name>.log, in which u can see that for pretty much all the simulated days (between 2018-06-24 and 2018-08-01) the 18:00 and 21:00 hrs files are filled with 4 soil levels, and sometimes also the 00:00 hrs file. For all the other processed timesteps, the files only contain 1 soil level.

Since I ran WRF with virtually the same input data three months ago and it was running as expected, I wonder what has happened to the model since that causes it to crash now. What could be the problem here, and how could we solve it?

 

[kwerner]

@daankivits

Have you updated the WPS or WRF model since you used it 3 months ago?

Can you attach a couple of your SFC data files? Based on the ungrib log, please send one of the files that ungrib processes as having 4 soil levels, and then another in which only a single level is processed? If those files are too large to attach, see the home page of the forum for instructions on sharing large files. Thanks!

 

[daankivits]

@kwerner A good suggestion but unfortunately no, I left the model as is and used the exact same modelling setup.

Here are some exemplary .SFC files (in a .tar archive). 'SFC:2018-07-01_00' has 4 soil levels, whereas 'SFC:2018-07-01_06' has only 1.

 

[daankivits]

After some extra help from the ECWMF Support, we found out that the problem might be caused by the ungrib process within WRF. Using the util/rd_intermediate.exe executable, I check both the 'SFC:2018-07-01_00' and 'SFC:2018-07-02_00' files and attached the output logs below. From the output logs it becomes clear that ungrib processed all four soil levels in 'SFC:2018-07-01_00', whereas it did not for 'SFC:2018-07-02_00'.

I have already been looking into some user-changable WRF settings that could affect the ungrib process of WRF, but have too little knowledge to pin-point the exact problem. What would be the next step to take?

 

[daankivits]

Any updates on this case? Would be awesome if I could still include WRF-CHEM runs in my thesis research.

Best regards,

Daan

 

[kwerner]

Hi,
Can you attach the SFC files prior to your running of ungrib (when they were still in gribbed format)? Can you also attach the Vtable you used? Thanks!

 

[daankivits]

Hi kwerner,
Sorry for the delay, I had to work on something else in the meantime. In that case I assume you mean the raw ERA5 files in .grb1 format, which contain the soil level data. I just uploaded the two raw ERA5 files corresponding to the aforementioned SFC:<yyyy-mm-dd_HH> files, all under the following tar file:
'ERA5_grb1_files.tar'. I hope you can find it, otherwise let me know!

The Vtable you requested I attached below.

 

[daankivits]

Bump!

 

[kwerner]

Hi,
Apologies for the long delay again. I was on vacation last week and have been spending nearly every moment this week conducting our biannual WRF tutorial. I just took a look at the data files and I think the issue is the order of the data in the files. So ungrib looks for data for a specific date in chronological order, and doesn't go backward. If you take a look at the file for 2018-07-01, for e.g., it contains data for
2018-07-01_00
2018-07-01_03
2018-07-01_06
2018-07-01_09
2018-07-01_12
2018-07-01_15
2018-07-01_18
2018-07-01_21

But the data are all out of order. So if you look at soil temperature (STL1, STL2, STL3, STL4), they are listed like

 10 139 STL1     112    0    7  2018-07-01_00:00 + 00
  11 170 STL2     112    7   28  2018-07-01_00:00 + 00
  12 183 STL3     112   28  100  2018-07-01_00:00 + 00
  13 236 STL4     112  100  255  2018-07-01_00:00 + 00

  21 139 STL1     112    0    7  2018-07-01_06:00 + 00

  24 139 STL1     112    0    7  2018-07-01_12:00 + 00

  27 139 STL1     112    0    7  2018-07-01_18:00 + 00

  44 139 STL1     112    0    7  2018-07-01_03:00 + 00
  45 170 STL2     112    7   28  2018-07-01_03:00 + 00
  46 183 STL3     112   28  100  2018-07-01_03:00 + 00
  47 236 STL4     112  100  255  2018-07-01_03:00 + 00

  62 170 STL2     112    7   28  2018-07-01_06:00 + 00
  63 183 STL3     112   28  100  2018-07-01_06:00 + 00
  64 236 STL4     112  100  255  2018-07-01_06:00 + 00

  82 139 STL1     112    0    7  2018-07-01_09:00 + 00
  83 170 STL2     112    7   28  2018-07-01_09:00 + 00
  84 183 STL3     112   28  100  2018-07-01_09:00 + 00
  85 236 STL4     112  100  255  2018-07-01_09:00 + 00

 101 170 STL2     112    7   28  2018-07-01_12:00 + 00
 102 183 STL3     112   28  100  2018-07-01_12:00 + 00
 103 236 STL4     112  100  255  2018-07-01_12:00 + 00

 121 139 STL1     112    0    7  2018-07-01_15:00 + 00
 122 170 STL2     112    7   28  2018-07-01_15:00 + 00
 123 183 STL3     112   28  100  2018-07-01_15:00 + 00
 124 236 STL4     112  100  255  2018-07-01_15:00 + 00

 140 170 STL2     112    7   28  2018-07-01_18:00 + 00
 141 183 STL3     112   28  100  2018-07-01_18:00 + 00
 142 236 STL4     112  100  255  2018-07-01_18:00 + 00

 160 139 STL1     112    0    7  2018-07-01_21:00 + 00
 161 170 STL2     112    7   28  2018-07-01_21:00 + 00
 162 183 STL3     112   28  100  2018-07-01_21:00 + 00
 163 236 STL4     112  100  255  2018-07-01_21:00 + 00

So ungrib locates all 4 levels for 00, then only a single level for 06, 12, and 18, and because it has already processed through time 18, it's not going to go back and use the data later in the file for times 03, 09, or 15, nor is it going to use the other levels for times 06, 12, and 18. It then finds time 21 and find all four for levels.

Unfortunately this is how the ungrib program works. I know many people use ERA5 data successfully, so there must be another format or means to obtain the data in a way that does not put the dates out of order.

 

[daankivits]

Thanks for tracking down the issue! For everyone having the same issues:The ECWMF Support helped me to find out how I can re-order the data to match the format that WRF wants. You have to use the grib_copy command of the EcCodes package:

grib_copy -B'dataDate:i asc, dataTime:i asc, validityDate:i asc, validityTime:i asc, shortName asc' <ERA5_SFC_INPUTFILE> <ERA5_SFC_INPUTFILE_REORDERED>

hope that helps!

 

[kwerner]

I'm so glad you were able to get support from ECMWF, and thank you for sharing the solution for other users!

 

[Amadou]

Thanks for tracking down the issue! For everyone having the same issues:The ECWMF Support helped me to find out how I can re-order the data to match the format that WRF wants. You have to use the grib_copy command of the EcCodes package:

grib_copy -B'dataDate:i asc, dataTime:i asc, validityDate:i asc, validityTime:i asc, shortName asc' <ERA5_SFC_INPUTFILE> <ERA5_SFC_INPUTFILE_REORDERED>

hope that helps!

Hello,

Please, I need more details about this post. Do you mean to re-download the ERA5 data? What to do mean grib_copy command?

I have the same issue here:
d01 2021-03-03_00:00:00 ---- ERROR: NUM_METGRID_SOIL_LEVELS must be greater than 1
----------------- ERROR -------------------
namelist : num_metgrid_soil_levels = 4
input files : NUM_METGRID_SOIL_LEVELS = 1 (from met_em files).
d01 2021-03-03_00:00:00 ---- ERROR: Mismatch between namelist and global attribute NUM_METGRID_SOIL_LEVELS

But it works last week when I used the same script of real.exe.

 

[daankivits]

Hi @Amadou ! You would need to download the ecCodes module/package (which is the successor of the grib_api package/module) on the machine you are working on (see the download instruction over at the EcCodes installation page. If everything went OK, you should be able to run the terminal command called 'grib_copy' on the machine on which you installed EcCodes. Be sure to run the command as follows and please insert your own files in between the brackets ([ ]):

grib_copy -B'dataDate:i asc, dataTime:i asc, validityDate:i asc, validityTime:i asc, shortName asc' <ERA5_SFC_INPUTFILE> <ERA5_SFC_INPUTFILE_REORDERED>

The header of the resulting file will be in a different order, and if all is good the re-ordered file should work with WRF.

 

[Amadou]

Hi @Amadou ! You would need to download the ecCodes module/package (which is the successor of the grib_api package/module) on the machine you are working on (see the download instruction over at the EcCodes installation page. If everything went OK, you should be able to run the terminal command called 'grib_copy' on the machine on which you installed EcCodes. Be sure to run the command as follows and please insert your own files in between the brackets ([ ]):

grib_copy -B'dataDate:i asc, dataTime:i asc, validityDate:i asc, validityTime:i asc, shortName asc' <ERA5_SFC_INPUTFILE> <ERA5_SFC_INPUTFILE_REORDERED>

The header of the resulting file will be in a different order, and if all is good the re-ordered file should work with WRF.

Hello,

I am getting the following error:

CMake Warning:
No source or binary directory provided. Both will be assumed to be the same as the current working directory, but note that this warning will become a fatal error in future CMake releases.

CMake Error: The source directory "/data/home/amadou.coulibaly/build" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.

I proceed as follow:
Since I am using a remonte system, I downloaded and unzip /eccodes-2.31.0-Source.tar.gz in this directory data/home/amadou.coulibaly/WRF_model/WRF-4.2.2/run
After in the same directory, I did:
mkdir build ; cd build
And when I run the following command:
cmake -DCMAKE_INSTALL_PREFIX=/data/home/amadou.coulibaly/WRF_model/WRF-4.2.2/run/eccodes-2.31.0-Source
I am getting the above error. What is wrong with me?

 

[Amadou]

Hello,

I am getting the following error:

CMake Warning:
No source or binary directory provided. Both will be assumed to be the same as the current working directory, but note that this warning will become a fatal error in future CMake releases.

CMake Error: The source directory "/data/home/amadou.coulibaly/build" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.

I proceed as follow:
Since I am using a remonte system, I downloaded and unzip /eccodes-2.31.0-Source.tar.gz in this directory data/home/amadou.coulibaly/WRF_model/WRF-4.2.2/run
After in the same directory, I did:
mkdir build ; cd build
And when I run the following command:
cmake -DCMAKE_INSTALL_PREFIX=/data/home/amadou.coulibaly/WRF_model/WRF-4.2.2/run/eccodes-2.31.0-Source
I am getting the above error. What is wrong with me?

Hello

I have solved this steps with using the following commands:
cd /data/home/amadou.coulibaly/WRF_model/WRF-4.2.2/run/eccodes-2.31.0-Source
cmake -S . -B build/ # this has created the build directory as follow:
/data/home/amadou.coulibaly/WRF_model/WRF-4.2.2/run/eccodes-2.31.0-Source/build

In this build directory, I successfuly run:
> make
> ctest
But when I run the following command:
> make install
I am getting the following error:
....................................
[100%] Built target eccodes_f_grib_print_data_static
Install the project...
-- Install configuration: "RelWithDebInfo"
-- Installing: /usr/local/include/eccodes_ecbuild_config.h
CMake Error at cmake_install.cmake:46 (file):
file INSTALL cannot copy file
"/data/home/amadou.coulibaly/WRF_model/WRF-4.2.2/run/eccodes-2.31.0-Source/build/eccodes_ecbuild_config.h"
to "/usr/local/include/eccodes_ecbuild_config.h": Success.

Makefile:129: recipe for target 'install' failed
make: *** [install] Error 1

 

[Amadou]

Hello

I have solved this steps with using the following commands:
cd /data/home/amadou.coulibaly/WRF_model/WRF-4.2.2/run/eccodes-2.31.0-Source
cmake -S . -B build/ # this has created the build directory as follow:
/data/home/amadou.coulibaly/WRF_model/WRF-4.2.2/run/eccodes-2.31.0-Source/build

In this build directory, I successfuly run:
> make
> ctest
But when I run the following command:
> make install
I am getting the following error:
....................................
[100%] Built target eccodes_f_grib_print_data_static
Install the project...
-- Install configuration: "RelWithDebInfo"
-- Installing: /usr/local/include/eccodes_ecbuild_config.h
CMake Error at cmake_install.cmake:46 (file):
file INSTALL cannot copy file
"/data/home/amadou.coulibaly/WRF_model/WRF-4.2.2/run/eccodes-2.31.0-Source/build/eccodes_ecbuild_config.h"
to "/usr/local/include/eccodes_ecbuild_config.h": Success.

Makefile:129: recipe for target 'install' failed
make: *** [install] Error 1

Hello,
After running the following command:
>python3 -m eccodes selfcheck
Found: ecCodes v2.27.0.
Your system is ready

I think ecCodes has been successful. Now my question is:
What represent <ERA5_SFC_INPUTFILE> <ERA5_SFC_INPUTFILE_REORDERED> files?