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

WRF real.exe "grid%tsk unreasonable" error after Landuse preprocessing

aba0327

New member
Hi, I'm working on customizing Landuse data for WRF and encountered an issue when running real.exe. The model stops with the error message:

CSS:
grid%tsk unreasonable

I suspect the issue is related to Landuse preprocessing. Here are the steps I took to integrate the land cover data:

  1. Custom Landuse Data Source:
    • I used EGIS land cover data, which I converted to binary (.bil) format.
    • And in the bin file, I confirmed that the land cover code was properly mapped.
  2. Resolution & Projection: The dataset was projected to EPSG:4326 with a resolution of 0.0041666667.
  3. Preprocessing Workflow:
    • Used rasterio and rasterize() to convert shapefiles to a raster grid.
    • Assigned 1 to all no-data areas.
    • Processed GEOGRID.TBL with the following settings:
      INI:
      name=LANDUSEF
      priority = 1
      dest_type = categorical
      z_dim_name = land_cat
      dominant = LU_INDEX
      interp_option = egis_landuse:nearest_neighbor
      rel_path = egis_landuse:egis_landuse/
  4. Checking geo_em Files
    • Used ncdump -v LU_INDEX geo_em.d01.nc | less to check LU_INDEX values.
    • Found that all values were 17, which seems incorrect.
  5. Running real.exe
    • real.exe runs but fails with "grid%tsk unreasonable" error.
    • ncdump -v TSK met_em.d01.2023-06-01_12:00:00.nc shows no TSK variable.
Questions:

  1. What causes geo_em to be created with only one code of 17?
  2. Could this issue be caused by incorrect Landuse classification mapping?
  3. Any recommended debugging steps for Landuse-related real.exe errors?
Any insights would be greatly appreciated. Thanks!
 
Hi, I faced the same issue of grid%tsk unreasonable and here's how I solved it,

# it's possible that TSK variable is not present in your met_em* (hence metoa*) files as MET data (NARR or GFS) uses SKINTEMP instead of TSK (I might be completely wrong). Check if you have TSK variable in either metoa* or met* files
Code:
>> ncdump -v TSK metoa_em.d01.2023-06-21_00:00:00.nc
ncdump: TSK: No such variable

>> ncdump -v TSK met_em.d01.2023-06-21_00:00:00.nc
ncdump: TSK: No such variable

TRIAL: Try to find the variable that represents skin temperature of earth in your met or metoa* (if using nudging) files and check if the range of the variable values are reasonable (e.g., 270–320 K). There’s SKINTEMP variable in the NARR metoa* files, renaming it to TSK in all files
Code:
>> module purge all
>> module load nco
>> module load hdf5            #(you may need other modules as well, load as required)

#rename SKINTEMP variable in metoa* (in my case) netcdf files, directly copy paste these lines on command line
Code:
>> for file in metoa_em.d0*.nc; do
>> ncrename -O -v SKINTEMP,TSK "$file"
>> done

#check the last file to ensure SKINTEMP is renamed as TSK

Code:
>> ncdump -v TSK metoa_em.d03.2023-09-02_00:00:00.nc

# will print out TSK values

#Run REAL.EXE

Code:
>> cd ~/WRF-4.4.2/run

>> rm metoa*                        # will only remove the links but doesn’t hurt to start fresh

>> ln -s /projects/b1045/wrf-cmaq/OBSGRID/20230708/metoa* .

>> ./real.exe
 
Top