Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

ERA5 landmask error

B

blueade7

New member
Hi,

In short: I have a job which runs successfully using the met data from the Hurricane Michael tutorial job. I would like to run this same configuration for a different period, so sourced ERA5 data via era5_to_int, with the only namelist changes being to the start and end dates, interval_seconds (as my ERA5 met data is 3-hourly), num_metgrid_levels, and constants_name. But the job fails.

More detail:
I have downloaded ERA5 netcdf data from rda.ucar.edu, then successfully used era5_to_int (using --isobaric, and 3-hourly output)
Since the resultant intermediate files contain invariant data, I set constants_name to point to one of these files (the earliest). But this resulted in:
"ERROR: Cannot combine time-independent data with time-dependent data for field LANDSEA.mask"

I then downloaded the ERA5_INVARIANT file from How to Process ERA5 Data, pointing constants_name to this, but this gave the same error as above.

My understanding is that invariant data is not strictly required, so I tried again without defining constants_name in WPS. Metgrid now completes successfully. But I get the following error in rsl.error.0000:

FATAL CALLED FROM FILE: <stdin> LINE: 70
program wrf: error opening wrfinput_d01 for reading ierr= -1021

wrfinput_d01 is not created, so I believe this is a problem in real.exe
But what precisely the problem is I don't know, and I'd greatly appreciate some help here. Please find attached my namelist files, rsl.error.0000, and process_output.log

Thanks
 

Attachments

  • namelist.wps
    801 bytes · Views: 3
  • process_output.log
    19.3 KB · Views: 1
  • rsl.error.0000
    1 KB · Views: 1
  • namelist.input
    10.1 KB · Views: 4
Last edited:
Hi,
I just run a quick test using the python script from NCAR MMM, which can be downlaoded from GitHub - NCAR/era5_to_int: A simple Python script for converting ERA5 model-level netCDF files to the WPS intermediate format

This script works just fine and WPS/WRF run to the end successfully in my test.

Would you please download the script from the website I provide, then follow the instruction to run it? After you get the intermediate files, please follow the normal steps to run metgrid.exe, real.exe and wrf.exe. I don't think you need to specify constants_name in your namelist.wps.
 
Hi Ming,

Thanks for getting back to me. I did download era5_to_int from the location you mention, and it ran successfully.
GeoGrid and MetGrid runs successfully.
Real.exe fails - wrfinput_d0x files are not generated
 
Last edited:
Hi Ming,

I now realise that the rsl.error file I attached was for wrf.exe. I have attached here the rsl.out file from real.exe. The error message is:
error in the grid%tsk
i,j= 50 1
grid%landmask= 0.0000000E+00

The only reference I can find to this problem using ERA5 data is Persistent "grid%tsk unreasonable" Error in real.exe , for which there has not been a solution posted.

Any guidance you can provide on this would be much appreciated.
 

Attachments

  • rsl.out.0000
    2.2 KB · Views: 0
Last edited:
I run a quick test using your namelist.wps and namelist.input, with the only changes below:

parent_id = 1, 1, 2 ( in your file, it is parent_id = 0, 1, 2) ,

And my case is done successfully. Can you. make the same change as I didi, then try again? Please let me know if it works for you.

By the way, what command did you issue to run era5_to_int.py ?
 
Hi Ming,

Thanks very much for this.

The command I ran was:
python era5_to_int.py --isobaric --path C:\Support 2016-01-01_00 2016-01-01_23 3

I tried with the edit to parent_id, but am still getting the same error, which suggests a problem with the landmask?:

error in the grid%tsk
i,j= 50 1
grid%landmask= 0.0000000E+00

Below is what the landmask variable looks like from the met_em.d01 file. I notice the values are not binary, as has been noted before: Using the ERA5 land/sea mask data in WRF However, there is no mention of the error I am getting in that thread.

1745961373495.png
 
Last edited:
Please send me the list of ERA5 data you downloaded, --- I am suspicious that something is wrong with the invariant field.
 
Here's the list of files. Please let me know if it would be useful for me to send anything else.
e5.oper.an.ml.128_134_sp.regn320sc.2016010100_2016010105.nc
e5.oper.an.ml.128_134_sp.regn320sc.2016010106_2016010111.nc
e5.oper.an.ml.128_134_sp.regn320sc.2016010112_2016010117.nc
e5.oper.an.ml.128_134_sp.regn320sc.2016010118_2016010123.nc
e5.oper.an.ml.128_134_sp.regn320sc.2016010200_2016010205.nc
e5.oper.an.ml.128_134_sp.regn320sc.2016010206_2016010211.nc
e5.oper.an.ml.128_134_sp.regn320sc.2016010212_2016010217.nc
e5.oper.an.ml.128_134_sp.regn320sc.2016010218_2016010223.nc
e5.oper.an.ml.128_134_sp.regn320sc.2016010300_2016010305.nc
e5.oper.an.ml.128_134_sp.regn320sc.2016010306_2016010311.nc
e5.oper.an.ml.128_134_sp.regn320sc.2016010312_2016010317.nc
e5.oper.an.ml.128_134_sp.regn320sc.2016010318_2016010323.nc
e5.oper.an.ml.128_134_sp.regn320sc.2016010400_2016010405.nc
e5.oper.an.pl.128_129_z.ll025sc.2016010100_2016010123.nc
e5.oper.an.pl.128_129_z.ll025sc.2016010200_2016010223.nc
e5.oper.an.pl.128_130_t.ll025sc.2016010100_2016010123.nc
e5.oper.an.pl.128_130_t.ll025sc.2016010200_2016010223.nc
e5.oper.an.pl.128_131_u.ll025uv.2016010100_2016010123.nc
e5.oper.an.pl.128_132_v.ll025uv.2016010100_2016010123.nc
e5.oper.an.pl.128_133_q.ll025sc.2016010100_2016010123.nc
e5.oper.an.pl.128_157_r.ll025sc.2016010100_2016010123.nc
e5.oper.an.sfc.128_031_ci.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_033_rsn.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_034_sstk.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_039_swvl1.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_040_swvl2.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_041_swvl3.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_042_swvl4.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_134_sp.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_139_stl1.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_141_sd.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_151_msl.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_165_10u.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_166_10v.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_167_2t.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_168_2d.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_170_stl2.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_183_stl3.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_235_skt.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_236_stl4.ll025sc.2016010100_2016013123.nc
e5.oper.invariant.128_129_z.ll025sc.1979010100_1979010100.nc
e5.oper.invariant.128_129_z.regn320sc.2016010100_2016010100.nc
e5.oper.invariant.128_172_lsm.ll025sc.1979010100_1979010100.nc
 
Is it a problem that e5.oper.invariant.128_129_z.regn320sc.2016010100_2016010100.nc has a different date (201601010100) to the other 2 invariant files (197901010100)?
 
Last edited:
Below is the list of files I used to test a case. Only the time is different, --- I test over 2008080100_2008083123 and your case is over a different period. Note that I extract invariant variables from e5.oper.invariant.128_129_z.regn320sc.2016010100_2016010100.nc. I am ot sure whether the invariant data from e5.oper.invariant.128_172_lsm.ll025sc.1979010100_1979010100.nc and e5.oper.invariant.128_129_z.regn320sc.2016010100_2016010100.nc are same. Can you just use data from e5.oper.invariant.128_129_z.regn320sc.2016010100_2016010100.nc and try again? Please let me know how it works.


e5.oper.an.pl.128_129_z.ll025sc.2008082000_2008082023.nc


e5.oper.an.pl.128_133_q.ll025sc.2008082000_2008082023.nc


e5.oper.an.pl.128_130_t.ll025sc.2008082000_2008082023.nc


e5.oper.an.pl.128_131_u.ll025uv.2008082000_2008082023.nc


e5.oper.an.pl.128_132_v.ll025uv.2008082000_2008082023.nc


e5.oper.invariant.128_172_lsm.ll025sc.1979010100_1979010100.nc


e5.oper.an.sfc.128_034_sstk.ll025sc.2008080100_2008083123.nc


e5.oper.an.sfc.128_235_skt.ll025sc.2008080100_2008083123.nc


e5.oper.an.sfc.128_039_swvl1.ll025sc.2008080100_2008083123.nc


e5.oper.an.sfc.128_040_swvl2.ll025sc.2008080100_2008083123.nc


e5.oper.an.sfc.128_041_swvl3.ll025sc.2008080100_2008083123.nc


e5.oper.an.sfc.128_042_swvl4.ll025sc.2008080100_2008083123.nc


e5.oper.an.sfc.128_139_stl1.ll025sc.2008080100_2008083123.nc


e5.oper.an.sfc.128_170_stl2.ll025sc.2008080100_2008083123.nc


e5.oper.an.sfc.128_183_stl3.ll025sc.2008080100_2008083123.nc


e5.oper.an.sfc.128_236_stl4.ll025sc.2008080100_2008083123.nc


e5.oper.an.sfc.128_031_ci.ll025sc.2008080100_2008083123.nc


e5.oper.an.sfc.128_167_2t.ll025sc.2008080100_2008083123.nc


e5.oper.an.sfc.128_168_2d.ll025sc.2008080100_2008083123.nc


e5.oper.an.sfc.128_165_10u.ll025sc.2008080100_2008083123.nc


e5.oper.an.sfc.128_166_10v.ll025sc.2008080100_2008083123.nc


e5.oper.an.sfc.128_033_rsn.ll025sc.2008080100_2008083123.nc


e5.oper.an.sfc.128_141_sd.ll025sc.2008080100_2008083123.nc


e5.oper.an.sfc.128_151_msl.ll025sc.2008080100_2008083123.nc


e5.oper.an.ml.128_134_sp.regn320sc.2008082000_2008082005.nc


e5.oper.invariant.128_129_z.regn320sc.2016010100_2016010100.nc
 
Thanks Ming. I will check this. Just to check though - I see 2 invariant data files in your list of files:
e5.oper.invariant.128_129_z.regn320sc.2016010100_2016010100.nc (bottom line)
e5.oper.invariant.128_172_lsm.ll025sc.1979010100_1979010100.nc (6th line from top)

Whilst I have 3 invariant files:
e5.oper.invariant.128_129_z.ll025sc.1979010100_1979010100.nc
e5.oper.invariant.128_129_z.regn320sc.2016010100_2016010100.nc
e5.oper.invariant.128_172_lsm.ll025sc.1979010100_1979010100.nc

So should I will try again with just the following?:
e5.oper.invariant.128_129_z.regn320sc.2016010100_2016010100.nc
e5.oper.invariant.128_172_lsm.ll025sc.1979010100_1979010100.nc
 
Last edited:
Hi Ming,

I've run era5_to_int again, using only the following files. Both the invariant files listed are necessary (these are the same two that appear in the list of input files you provided) - the script fails if I don't include both. This produces identical intermediate files to what I had previously. So it seems unlikely to me that this can be the source of the problem.

Do you have any other thoughts as to how to proceed?
Why else it could it be that your run works whilst mine doesn't? What version of WRF are you running? I am using vn4.3.

e5.oper.an.ml.128_134_sp.regn320sc.2016010100_2016010105.nc
e5.oper.an.ml.128_134_sp.regn320sc.2016010106_2016010111.nc
e5.oper.an.ml.128_134_sp.regn320sc.2016010112_2016010117.nc
e5.oper.an.ml.128_134_sp.regn320sc.2016010118_2016010123.nc
e5.oper.an.pl.128_129_z.ll025sc.2016010100_2016010123.nc
e5.oper.an.pl.128_130_t.ll025sc.2016010100_2016010123.nc
e5.oper.an.pl.128_131_u.ll025uv.2016010100_2016010123.nc
e5.oper.an.pl.128_132_v.ll025uv.2016010100_2016010123.nc
e5.oper.an.pl.128_133_q.ll025sc.2016010100_2016010123.nc
e5.oper.an.pl.128_157_r.ll025sc.2016010100_2016010123.nc
e5.oper.an.sfc.128_031_ci.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_033_rsn.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_034_sstk.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_039_swvl1.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_040_swvl2.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_041_swvl3.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_042_swvl4.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_134_sp.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_139_stl1.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_141_sd.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_151_msl.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_165_10u.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_166_10v.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_167_2t.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_168_2d.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_170_stl2.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_183_stl3.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_235_skt.ll025sc.2016010100_2016013123.nc
e5.oper.an.sfc.128_236_stl4.ll025sc.2016010100_2016013123.nc
e5.oper.invariant.128_129_z.regn320sc.2016010100_2016010100.nc
e5.oper.invariant.128_172_lsm.ll025sc.1979010100_1979010100.nc
 
Last edited:
Please confirm that you still use the same namelist.wps and namelist.input posted Monday for this case. I will see whether I can repeat your issue. Thanks.
 
Nearly the same (just with parent_ID adjusted as discussed above, and with timestep reduced). I've uploaded these updated namelists here.
Thanks very much Ming!
 

Attachments

  • namelist.wps
    801 bytes · Views: 1
  • namelist.input
    10.1 KB · Views: 1
Hi,

I repeated your case using your namelist.wps and namelist.input. However, I change num_soil_layers from 0 to 4, since you run with Noah LSM.
To save computation time, I only run wrf.exe for 1 hour and the case is done successfully.

Below is what I did:
(1) ./era5_to_int.py -i 2016-01-01_00 2016-01-01_06 6
(2) under WPS, run geogrid.exe and metgrid.exe
(3) run real.exe and wrf.exe

For the error in the grid%tsk you have seen , I am suspicious that you may use a wrong ERA5 data. Attached is the file list, and namelist.input and nameist.wps I used to repeat your case. Can you use my files to rerun this case? Please let me know if you still have any issues.
 

Attachments

  • filelist.txt
    9 KB · Views: 1
  • namelist.wps.txt
    715 bytes · Views: 1
  • namelist.input.txt
    9.3 KB · Views: 2
Hi Ming,

Thanks very much for this.

I regenerated my intermediate files, for both 00 and 06 times. My era_to_int output for the 00 time alone is identical to yours (filelist.txt you posted above). I have used the namelist.wps and namelist.input files you posted above. My only edit is in namelist.wps to geog_data_path, to reflect my particular folder structure.

I have figured out the immediate problem! The solution seems to be as indicated here, by akash.pathaikara: Persistent "grid%tsk unreasonable" Error in real.exe

I simply removed the tilda in the path below
geog_data_path = '~/work/DATA/WPS_GEOG',
... and instead supplied the full path, and this seems to fix the problem - real.exe now completes successfully. Apologies for not having tried this sooner, but I was really surprised to find this was the solution, as (a) geogrid ran fine previously (even with the tilda in the path name), and (b) the Hurricane Michael tutorial job ran fine all the way to completion with tilda in the path name.

That's the good news. The bad news is my job still fails...

Real.exe runs to completion, but WRF.exe fails due to model instability after 12 minutes, with e.g.:
"21 points exceeded w_flag_cfl in domain d01 at time 2016-01-01_00:12:00 hours"
See attached rsl.error file.

Could you please clarify that your run completed the full hour successfully? If so, do you have any ideas as to why my run would be going unstable, despite me using the same namelist files as you, and the same met data? Could it be that the GEOGRID.TBL.ARW and METGRID.TBL.ARW files we are using are different?
 

Attachments

  • rsl.error.0005.txt
    15.9 KB · Views: 1
Last edited:
Hi,
Thanks for your update. the CFL violation indicates that the model is numerically unstable. Please reduce time step and increase epssm, then try again.
 
Thanks Ming, yes I will try this. But I understood from your message yesterday that when you ran it using exactly the same namelists, wrf ran successfully for the full hour to completion?
 
Yes I confirm that all works fine with your namelist. One thing I didn't mention is that I changed the path to WPS static data. You can find that information in 'namelist.wps' I attached to you the other day, --- this is an obvious chnage because I cannot access your data in your machine.
 
Hi Ming, I reduced the timestep to 30 seconds (for the outer nest with dx = 9 km). So that's 3.3 dx. I also increased epssm to 0.5 for all 3 nests.
The job now runs to completion. Which is excellent news. Thanks again very much for your help!
I will try reducing epssm now to see if it still runs.
 
You must log in or register to reply here.
Top