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

Soil Categories and Landmask Inconsistencies

S

scapps

New member
When running real.exe we noticed the following warnings:
"points artificially set to land"

Since version 3.8, the change described below was implemented:

"In V3.8, we changed default surface_input_source option value from 1 to 3, which uses the dominant categories computed in geogrid. But we neglected that when dominant categories for land and soil are recomputed in real, the real program does checks for mismatches, making sure the lower resolution isltyp matches with landmask data. This has two effects: one is the actual isltyp, ivgtyp, and xland can be different from that from surface_input_source = 1 (a check later in real program effectively matched ivgtyp based on isltyp); and the other effect is that for certain cases, the WRF model would stop due to un-matched isltyp and ivgtyp. This change fixes this problem, and isltyp, ivgtyp, and xland are now identical to those coming from surface_input_source = 1."

When using the default soil category (soiltype_top_30s and soitype_bot_30s) dataset, this now creates a problem around coastlines when running at high resolution (2-3km). The default soil category data set says it is 30s resolution, but it is clearly not resolving the coastlines at 2km resolution. However, it does resolve the inland lakes.

Due to the recent implementation described above, real.exe then changes the landmask to have the same coarse, unrepresentative coastlines. Which is not what we want.

We have also tried the bnu_soil_30s soil categories which resolve coastlines much better. however, the inland lakes are not resolved or missing for some reason in this dataset (at least with the default GEOGRID.TBL). So, when real.exe runs, the lakes are removed from the landmask. Which is also not what we want.

After trying many diiferent approaches, we did the following:
To trust the landmask field created from the Landuse dataset (in this case, MODIS30s), we changed the following lines in the module_initialize_real.f90 to:

! BEGIN: SCAPPS 02/2020
IF ( ( grid%landmask(i,j) .LT. 0.5 ) .AND. &
( grid%ivgtyp(i,j) .NE. config_flags%iswater .OR. grid%isltyp(i,j) .NE. 14 ) ) THEN
IF ( grid%tslb(i,1,j) .GT. 1. ) THEN
grid%ivgtyp(i,j) = config_flags%iswater
grid%isltyp(i,j) = 14
ELSE IF ( ( grid%landmask(i,j) .GT. 0.5 ) .AND. &
( grid%ivgtyp(i,j) .EQ. config_flags%iswater .OR. grid%isltyp(i,j) .EQ. 14 ) ) THEN
IF ( grid%tslb(i,1,j) .GT. 1. ) THEN
grid%ivgtyp(i,j) = 5
grid%isltyp(i,j) = 8
! END: SCAPPS 02/2020

Does this sound correct? Or, am I missing another fix such as changing GEOGRID.TBL or METGRID.TBL entries to mask where water? Adding masked=water to the following entries in GEOGRID.TBL results in missing values over water. These pose a problem as SOILCBOT and SOILCTOP 3D fields should have 0s everyhere except where the soil category exists.
 
There is a lot going on here.

1. The land use categories have many names: lu_index, ivgtyp, etc. The land / water mask should come directly from these fields. Is that not the case?

2. The soil categories do tend to be coarser. If I understand the problem, the real program is taking the safe solution and defaulting to a water point if either land use or the soil categories indicate a water point.

Can you show us some images of the before vs after?

Dave
 
@scapps,
Can you also attach your namelist.wps and namelist.input files so that we can take a look at that too? Thanks!
 
Hello,

I'm experiencing a similar problem.

The first two plots are from met_em file generated by WPS. The second two are from real.exe

Is there some update to fix it on new WRF releases or the best option is to use the solution proposed by scapps?

Thank you for any help.

With best regards,

Taoan
 

Attachments

  • wrf_real_mask.jpeg
    wrf_real_mask.jpeg
    94.5 KB · Views: 26
  • wrf_wps_mask.jpeg
    wrf_wps_mask.jpeg
    83.5 KB · Views: 23
Taoan,
Can you provide some additional information regarding your case? Please let me know the resolution of the input data, the version of WPS/WRF you are using, and please include your namelist.wps and namelist.input file. Thanks!
 
Hello,

Sorry for the delayed response.

I am working with a 1km resolution grid.

I attached my namelists for checking.

I applied the solution proposed by scapps and it solved the problem. However, I think it would be usefeul to improve the new versions of Real with the ability to prioritize the input landuse map when define landmask and interpolate the data on grids.

I am using REAL_EM V4.0 PREPROCESSOR

With best regards,

Taoan
 

Attachments

  • namelist.zip
    1.7 KB · Views: 4
Hi Taoan,
Thanks for clarifying. I guess I'm still struggling a bit to understand the problem and whether it's different than the other user's issue. In the plots you sent, it looks like landmask was shown at a much higher resolution after running real.exe, and therefore you weren't still experiencing the "blocky" problem the previous user was experiencing. Or was the second plot you sent showing the improvement after you used Scapps's solution? If not, please clarify the following:
1) Are you using a new soil or other type of landuse input data? If so, what is the resolution of those data?
2) What variables are showing problems, and after which stage of the process (e.g., after real.exe)?
3) What is the unwanted outcome that is occurring?

Thanks, and apologies for my continued confusion.
 
You must log in or register to reply here.
Top