Error when running the real.exe

[sekluzia]

Dear Colleges,

The real.exe program fails to run. I successfully run the WPS executables processing ECMWF operational model level data (137 levels+surface). The met_em.d0* files are created.

I am running the WRF v3.9. Please find attached the rsl.error and namelist.input files.

Best regards,
Artur

 

[kwerner]

Hi Artur,
The error in your rsl file is:

FATAL CALLED FROM FILE:  <stdin>  LINE:    1194
grid%p_top > previous value

This error typically occurs when your input data are non-isobaric and have varying levels that don't always reach the same height, for every time period (for example, if you were using an isentropic data set). You'll need to take a look through your met_em* files and find the minimum (physically lowest in the atmosphere, largest pressure value) pressure that your data reach for every time period, and you'll need to set that as your p_top_requested value in namelist.input. This value can be anything - it doesn't need to be one of the standard pressure levels. It expects a 'real' value, so it can have decimals if you'd like. Keep in mind that p_top_requested is given in Pa.

Kelly

 

[sekluzia]

Dear Kelly,

How can I check pressure values:
" You'll need to take a look through your met_em* files and find the minimum (physically lowest in the atmosphere, largest pressure value) pressure that your data reach for every time period,"

Do I need to look the values of PRES variable in my ?

2) I have 21 met_em* files for d01 and one for d02. But I need to set single for value p_top_requested value in namelist.input. How can I do that?


Artur

 

[kwerner]

Artur,
You can use something like ncview to look at the PRES variable. At the top, it will tell the full "displayed range" in each file. In the attached screenshot, for example, for this date/time, the range is from 100 to 102741 Pa. So the minimum pressure I could use for p_top_requested would be 100 Pa. Since all of my files have the same values, that would be safe for me to use (as long as I made sure to use enough vertical levels - by setting e_vert high). However, because we assume that you may have differences in the minimum available pressure you have in each file (hence the error), you will need to do this for each of your files, separately. Take note of the minimum value of each, and whatever is the highest minimum value will be what you need to make sure to set p_top_requested to (or any higher pressure value).

So say that you had 3 met_em* files, with the ranges as:
5000 to 10000 Pa
5500 to 10000 Pa
5000 to 10000 Pa

Then you would need to set p_top_requested no less than 5500. Does that makes sense?

Kelly

 

[sekluzia]

Dear Kelly,

I carefully followed your recommendations.
I opened my met_em* files with Panoply and looked into the data at each time step from 00 to 06 UTC. You can see the figures are attached. In my case minimum pressure value is also not changing and equals to 1.000183 . I checked the minimum pressure values carefully with Scale Range. So I set p_top_requested = 1.000183,
But again, the same error appears (the rsl.error and namelist files are attached).

Best regards,
Artur

 

[kwerner]

Hi,
Can you actually send your met_em* files that you are using to run real (for the 6 hour run)? If the files are small enough to attach here, that is great. Otherwise, take a look at the home page for this forum for information on uploading larger files. If you do that option, please package the files as .tar, instead of .rar. Unfortunately I'm unable to open a .rar file here. Also, please let me know if you upload files so that I know to go look for them.

Thanks,
Kelly

 

[sekluzia]

Dear Kelly

Please use this link to download my met_em* files that I am using to run real (for the 6 hour run, met_em.tar.gz ):
https://figshare.com/s/b587ba95078f0c40c753

I would like to inform you that the same input data have been successfully processed with the WPS and WRF v4.0 on another machine where smpar is used (the rsl.out file is attached), but I want to see the simulation results on the current cluster where the WRF v3.9 is compiled with the dmpar. Please, see more details on this issue in my another post:

http://forum.mmm.ucar.edu/phpBB3/viewtopic.php?f=47&t=649&e=1&view=unread#p2055

Artur

 

[sekluzia]

Hi Kelly,

Were you able to process the met_em* files with the real.exe?

I would like to inform you that I also tried to run the real.exe on my PC where the WRF v3.9 is installed with dmpar mode (4 CPUs). The same issue takes place (the rsl.error and namelist files are attached).

Artur

 

[kwerner]

Hi Artur,
I apologize for the delay. It can sometimes take us a few days to get back to each forum post, due to other obligations. Thank you for your patience.

I was able to recreate the problem you are seeing, but I think I see why this is happening. Your initial met_em.d01.2018-08-10_00:00:00.nc file looks okay, and as you indicated, the pressure goes all the way up to 1.00018 Pa. However, beginning with the next met_em file (for hour 01, and then continuing through hour 06), the fields seem corrupt (which is probably why real.exe stops at hour 01). I am attaching a couple of screen shots. One shows a comparison of the PRES field in the 00 file, and the 01 file. The other just shows that other fields are bad, as well (it's the 01 file, showing soil temperature).

I'm not immediately sure what went wrong with the processing of these files. Since you are using ECMWF input data, if the data are sigma-level data, then you likely need to use the calc_ecmwf.exe utility during the WPS process. If you didn't do this, take a look at the description here (section C):
http://www2.mmm.ucar.edu/wrf/users/docs/user_guide_v4/v4.0/users_guide_chap3.html#_WPS_Utility_Programs_1

That may not be the problem though. I would start by looking at all of the raw input files to verify that they look okay.

At this time, I have no explanation as to why an smpar run would complete without errors (while the dmpar run does not). I did a test with an smpar build, as well, and it also completes without an error; however, when I look at the pressure range in the wrfinput_d01 file, the range goes into the negatives, so it doesn't exactly seem to be working correctly either - for some reason, it's just not displaying the error as in the dmpar build.

One more thing I'd like to note, as I should've mentioned this in the previous post above: although your data (at least at the initial time) do go up to 1.00018 Pa, the WRF model is incapable of going higher than about 1000 Pa. The default is 5000. So if you are able to get the met_em* files sorted out, you should keep p_top_requested at a pressure no lower than 1000 Pa.

Kelly

 

[sekluzia]

Dear Kelly,

Thanks for your efforts to help me with this issue!
Let me provide some further comments as well:

1. I use the calc_ecmwf.exe utility during the WPS process. Please, download the raw ECMWF input data in grib1 (for surface fields) and grib2 (for model-level fileds) format necessary to run the WRF model for the first 6 hours using the following link:
https://figshare.com/s/b51662f1f1da94706a76

2. I would like to inform you that I face the same issue when processing the ERA5 reanalysis model level data (at 137 sigma levels), again, only for the dmpar runs.

3. I am also seeing the negative pressure values in the wrfinput_d01 file obtained from the smpar run. However, the simulation results are more accurate when the ECMWF model level fields are applied compared to those forced by the ECMWF pressure-level fields (25 pressure levels).

Hope, we can solve this complicated issue.

Artur

 

[sekluzia]

One more thing, when I look into my wrfinput_d01 file obtained from the dmpar run and ECMWF 25 pressure-level data, I also find negative pressure values, if you mean the perturbation pressure variable (P). Please, find attached the P map for the WRF 52 nd sigma level.

Artur

 

[kwerner]

Hi,
Can you also send your ecmwf_coeffs file so that I can take a look?
And will you let me know which Vtable(s) you used?

Thanks,
Kelly

 

[sekluzia]

Hi Kelly,

I use standard Vtable.ECMWF_sigma file for processing the surface data, but the model level data are in grib2 format, and therefore, I have to use separate Vtable (Vtable_ECMWF_ML).
I use the ecmwf_coeffs file obtained from the following link:
http://www.ecmwf.int/en/forecasts/documentation-and-support/137-model-levels

These three files are attached.

Artur

 

[kwerner]

Hi Artur,

I noticed that you don't have any geopotential height data in your 3d data. This is a field that is mandatory. Can you try to obtain that data for your 3d files, add it to the Vtable, and then try this again? That could potentially be causing the problem.

As for the ERA5 data, take a look at this forum conversation that discusses an ongoing known problem with this particular dataset:
http://forum.mmm.ucar.edu/phpBB3/viewtopic.php?f=34&t=278&p=1285&hilit=era5#p1285

 

[sekluzia]

Thanks for sending me helpful link on the ERA5 issue, I will try to run the WRF with the ERA5 data on Gaussian grid. Hope this will work.

Yes, you are right, I don't have any geopotential height data in my 3d data, but this is in line with the content of the Vtable.ECMWF_sigma, it does not contain the geopotential height variable, while the Vtable for ECMWF pressure-level data contains this variable. Do you still believe that this could potentially be causing the problem?

Artur

 

[kwerner]

Actually, the calc_ecmwf_p utility should be able to calculate geopotential height, as long as you have soil height (or soil geopotential), 3-d temp, and 3-d specific humidity (which it looks like you do). However, in your met_em* files, there is no geopotential height. Do you mind sending me your namelist.wps file so that I can run a couple of tests?

 

[sekluzia]

Yes, you are right, that is why the geopotential height is not mandatory input variable for the case of model level data. I checked both soil height (or soil geopotential) and 3-d specific humidity are available in my surface and model-level grib data.

Please find attached my namelist.wps file. Please note I run the ungrib.exe program twice, i.e. once for the model level data (prefix = 'ERA5_ML') and the second time for processing the surface data (prefix = 'ERA5_SFC'), then I run the calc_ecmwf_p.exe, and the avg_tsfc.exe utilities. Finally, I run the metgrid.exe with fg_name = 'ERA5_SFC','ERA5_ML','PRES',.

 

[kwerner]

Hi,
I just want to let you know that I haven't forgotten about you. I've been trying to run some tests to figure out what may be the problem. I'm having our WPS specialist take a look at it to. I'll hopefully get an answer to you soon.

 

[kwerner]

Hi,

Okay, so it looks like the calc_ecmwf_p utility doesn't like when the intermediate atmospheric and surface data are in separate files. It expects only one file prefix to look through. You can get around this problem by concatenating the files together. So, for example, if you run ungrib for the surface data, using a prefix 'SFC', and then you run ungrib for the 3D atmospheric data, setting the prefix to '3D,' you then will have files for each time that begin with SFC and 3D. Then you can use the cat command to combine them:
cat SFC:2018-08-10_00 >> 3D:2018-08-10_00
cat SFC:2018-08-10_01 >> 3D:2018-08-10_01
etc...(do this for all times)

Then the calc_ecmwf_p utility should successfully calculate the PRES, GHT, and RH variables (you can use the util/rd_intermediate.exe utility to check the 'PRES:2018-08-10_0*' to make sure. You then will only need to set in the metgrid section of the namelist:
fg_name = '3D', 'PRES'

for running metgrid. At that point, metgrid should have all the variables that the real.exe program expects. Let me know if that helps.

Kelly

 

[sekluzia]

Hi Kelly,

I carefully followed your suggestions, but the same error arrives when running the real.exe.

1. I concatenated surface and model-level data into one file using a prefix 'ECMWF_ML'
cat ECMWF_SF:2018-08-10_00 >> ECMWF_ML:2018-08-10_00
cat ECMWF_SF:2018-08-10_01 >> ECMWF_ML:2018-08-10_01
etc...(do this for all times)

I use Vtable.ECMWF for processing the surface data, and Vtable_ECMWF_ML for processing the model level data.
the WPS program, again, successfully creates meteorological fields.


The calc_ecmwf_p utility successfully calculates the PRES, GHT, and RH variables (I checked that by the util/rd_intermediate.exe utility). You can download my intermediate files at:
https://figshare.com/s/771643b0c9a932634246

I am also able to see the GHT (geopotetial height) in my met_em* files. You can download my met_em* files at:
https://figshare.com/s/7bdec56909a9a8ebd1c9

My Vtable, namelist and rsl.error files are also attached.

Artur