Low resolution of Soil moisture(SMOIS) in wrf_out file

[Hyejin Lim]

Hi!

I have some problem with SMOIS.

I just used ERA5 data for meteorological input, and wrf.exe worked just well, but variable SMOIS in wrf_out file appears little bit weird.
I think this is affected by different ISLTYP, but when I changed the data to fnl data with same condition, this problem doesn't appear even though this fnl data uses the same ISLTYP!

[initial stage]

[7 hours later]

[ISLTYP]

horizontal resolution is 1 km, and that 1 patch size is about 5 X 5 km.

that patch slowly disappear when time passes about 20 days to 1 month..

What should I change?

 

[kwerner]

Hi,
Can you let me know which version of WRF you are using, and can you attach your namelist.input file? Thanks!

 

[Hyejin Lim]

(1) I'm now using WRF version 4.1.3, and version 3.8.1 also showed the same problem.

(2) I attached namelist.input file!

(it's independent of time_step, start time/end time, auxinput)

(3) I tried to simulate with GFS[soil moisture/temperature, land/sea flag] + ERA5[for others..] for input data,
and the result doesn't seem to show the characteristic above.

 

[kwerner]

Hi,
When using the ERA5 data, can you try setting:

surface_input_source                = 1,

in your namelist.input file, and then re-run real.exe, and let me know if that makes any difference? Thanks!

 

[Hyejin Lim]

Thank you for your attention..!

I tried to run with the option you mentioned, but it still shows the same problem..

 

[kwerner]

Okay, thanks for trying. If you haven't already, will you look through the met_em* files to see if they have anything similar at the times you are seeing the issue after running wrf? If not, can you attach your wrfinput_d0* files, along with your wrfbdy_d01 file so that I can try to repeat the problem with your files? If the files are too large to attach, take a look at the home page of this forum for information on sending large files. Thanks!

 

[Hyejin Lim]

Thank you for your help!
I couldn't find the problem at the met_em file.. It just happens when model start to simulate soil variables..!
I uploaded the wrfinput, wrfbdy, and namelist.input file using ERA5 and FNL GDAS data on the Nextcloud. (ERA5 shows the problem, and FNL GDAS doesn't)

(I turned off some of the options that additional files are necessary. Of course the issue is still reproduced when I tried to simulate.)

file name is hjlim_SMOIS.tar for ERA5 data and hjlim_SMOIS_fnl.tar for FNL GDAS data.

Just after 1 step passes, I can find that SMOIS, and SH2O shows the problem at domain 2 and 3.

 

[kwerner]

Thanks for sending that. It looks like maybe there is something going on with the masking around the coastlines with the ERA5 data - like the resolution is much more coarse, making it blocky. What is the resolution of the ERA5 input data you are using, vs. that of the GFS? Can you attach your namelist.wps file so that I can see that?

It also looks like there may be something wrong with the input data to begin with. For instance, in your look at the variable P in the wrfinput_d03 file, it has a range of -0.0017 to 1370.59 Pa, which doesn't make any sense. It may help if you also attach (or put on NextCloud) your met_em* files for the ERA data. Thanks!

 

[Hyejin Lim]

Thank you for your reply!

1. both resolution of the data is 0.25 degree. only time intervals are different(ERA5: 1h, FNL GDAS: 6h)
and When I checked the Landmask in met_em or wrf_input, they just seem to be same for me..

2. for variable P, Actually I didn't recognized that..! Thanks for finding out nonphysical features in my wrf_input file.
I uploaded met_em* files and namelist.wps on NextCloud. File name is metfile_hjlim.tar . I just used ERA5 pressure levels and ERA5 single levels data to make met_em files, and also used variables which were included in Vtable.ERA-interim.pl. But in here, I think Pressure variables doesn't seem to be nonphysical..

3. In namelist.wps, I used SRTM_126 and SRTM_127 in geog_data_res. This is just topography(height) data, and I use this because this has very high resolution.

 

[kwerner]

Hi,
I apologize for the delay. We have all been trying to figure out how to work from home during these crazy times!

I asked a colleague about this, who thinks it's likely that you are missing the NON-time-varying data files, such as landmask and likely surface geopotential or the terrain field. For ERA5, they will need to be downloaded separately. If you did not do that, then you'll need to download those, as well, and then see if that makes a difference.

 

[Hyejin Lim]

Thank you for taking the trouble to help me. I really appreciate it..

I checked intermediate files which came out from ungrib.exe with plotfmt.ncl, and variables contained are as follows:

<variables contained>
TT__200100
UU__200100
VV__200100
RH__200100
LANDSEA__200100 (Land/Sea Flag)
SOILHGT__200100 (Terrain field of source analysis)
PSFC__200100 (Surface Pressure)
PMSL__200100 (Sea Level Pressure)
SKINTEMP__200100 (Skin Temperature)
SEAICE__200100 (Sea Ice Fraction)
SST__200100 (Sea Surface Temperature)
SNOW__200100 (Water Equivalent of Accumulated Snow Depth)
SNOWH_200100 (Physical Snow Depth)
ST000007__200100
ST007028__200100
ST028100__200100
ST100289__200100
SM000007__200100
SM007028__200100
SM028100_200100
SM100289__200100
HGT_(100000...) (Height)
TT_(100000 ...)
UU_(100000 ...)
VV_(100000 ...)
RH_(100000 ...)

and When I compared these variables with Vtable.ERA-interim.pl, missing variables were

GEOPT_(100000, ...), DEWPT_200100, SOILGEO_200100, SNOW_DEN_200100, SNOW_EC_200100

Actually, I couldn't download these variables, because they don't have any descriptions on Vtable,
and also I didn't tried to find these because I thought that they can be replaced by other variables which I used.. Is it right?
(for example, DEWPT by RH, SOILGEO with by SOILHGT)

* I couldn't download all the variables in ERA5 because it will take too much time, and when I downloaded it with short time range to test ungrib, some of the variables in ERA5 were not in the same GRIB format.
(When I tried to ungrib it, error message came out. I think some of them are in GRIB1 and the others are in GRIB2 format.)

 

[kwerner]

It looks like you likely do have all the necessary variables. We did notice, however, that when we look at the SCT_DOM (dominant soil category) field in the met_em* files, it has the same blocky pattern. Take a look at the attached screenshot. The blocks in the soil moisture field are associated with the initial distribution of the soil field. Because the resolution of the soil data is coarse, if the soil data is treated as a discrete value, instead of a continuous field, then these angular looking shapes result in fields from the WRF model that use that soil data (such as soil moisture). The blocks are not necessarily "wrong", it is all that the model can do when it is given this coarse and blocky input data. As you mentioned in the initial post, the weirdness does disappear over time. Are you getting reasonable results after that? If so, then it may not be necessary to do anything different; however, there may be some things that can be modified with your GEOGRID.TBL. If you'd like to attach that, I can take a look. If you are content, then no worries!

 

[Hyejin Lim]

Oh my god.. thanks a lot!
Since I'm not that professional, It's a bit scary to fix the table on my own.. sorry for that.
Is there any materials that I can use as a reference..? I searched for it, but I couldn't find..
Here's my GEOGRID.TBL..!

 

[kwerner]

Thanks for sending that. I'm not sure if this will work, but in your GEOGRID.TBL, look for this section:

name=SOILCTOP
        priority=1
        dest_type=categorical
        z_dim_name=soil_cat
        dominant=SCT_DOM
        interp_option = bnu_soil_30s:nearest_neighbor
        interp_option =     30s:nearest_neighbor

and try setting that bottom line to:

interp_option =     30s:four_pt

and run through it all again, starting with geogrid. Let me know if that makes any difference. If not, I'll ask our WPS specialist for advice.

 

[francescomaicu]

Dear Kwerner and Hyejin Lim
I found interesting this post and I ask you to consider if my concern is correct or not.
I'running WRF on the Mediterranean Sea and a large part of Atlantic Ocean and Europe.
The nominal resolution (lat-lon projection) is 1/24°and the mapfactor ranges between 1.2 (at 28°N) and 1.8 (56°N), meaning that the geographical resolution ranges from 3.8 km to 2.4 km.
The static dataset for SOILC_TOP and SOILC_BOT is the same of Hyejin Lim at 30arc-sec, that is roughly 3-4 time finer than my grid resolution.
I changed the interp_option from nearest_neighbour (the default one) to four_pt.
Is it appropriate in you opinion or should I try with the average_gcell, since the model resolution is lower that the dataset one?
Thanks a lot.

 

[francescomaicu]

Dear all,
I guess I found the solution.
After several tries and reading carefully the UserManual, I understood that the nearest_neighbor is the only interpolation option that works with categorical field. The reason is quite clear at page 3-36

For categorical datasets (i.e., datasets that have
type=categorical in their index files), this option actually causes the geogrid program
to consider all source pixels that lie within each WRF grid cell, and to find the fraction of
the WRF grid cell that is comprised of each category in the source data.

Am I correct?

 

[Ming Chen]

Hi,
For category variables, various interpolation options can be used. It is not true that only the nearest_neighbor option can be used.
As a general rule, if the input data resolution is much coarser than WRF grid size, then four_pt could be an option, For very high resolution input data, average_gcell might be better. If the WRF grid size is similar to the resolution of the inept data, nearest_neighbor can be an option.

 

[francescomaicu]

Dear Ming,
thank you for your answer. Maybe I'm wrong somewhere that i can't find.
I made several tests changing the interpolation scheme for the landuse (and also with the soil texture), but I find always no difference.
Please could you take a look to my files? For simplicity I generated a domain with only the terrain and the landuse. I attached the 3 table files I changed and the differences of the second and the third domain with respect to the first one. The only field that changes is the HGT that is numerical.
Am I wrong somewhere?
Thank you

 

[chunchih]

Hi all,

I am seeing a similar blocky pattern in some of my WRF 2D fields (e.g., T2, TH2, Q2, HFX, etc). My 10-m wind variables look fine though since they are unrelated to soil type.

Ming had pointed out that this is due to the dominant soil category (ISLTYP) having a coarse resolution, so I tried to smooth the SOILCTOP and SOILCBOT fields by changing the interpolation method for these fields in my GEOGRID.TBL.ARW from nearest_neighbor to four_opt. However, like what Francesco had found, nothing seemed to change regarding these categorical fields. The fields still show some blocky features.

Another strange thing is, it seems like the 30s resolution soil type datasets, which are the ones I am using, are only truly 30s resolution over CONUS. The soil-type fields appear to have a much coarser resolution on the Canadian side of the border than that on the U.S. side (please see attached). However, I guess that is just how it is.

David