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

Temperature at 2m is 2-4 degrees lower than observation with WRF & NoahMP

X

xiao.zh

New member
Hi all,
I'm working on a WRF case study for the Huang-Huai-Hai Plain (China) and found that the simulated T2 (2m temperature) consistently shows significant errors compared to observed monthly mean values, with RMSE ranging from 2 to 4°C.
Here are the cases that I have tested. Forced with ERA5.
case .png
The following are my results. B00 for 2010-2022, the rest only run for 2010.
Between the B04 and B06 schemes, one modified dveg (from 2 to 8), and the other switched from Noah-MP to Noah. While these adjustments improved the simulated temperature, it remains systematically lower than observations.
I also tested potential snow-related issues (B02, opt_snf=4) as suggested in forum discussions, but the impact was negligible.
Currently, I’m experimenting with FNL meteorological data (ds083.2).
Could anyone suggest additional avenues to address this persistent cold bias in my simulation?


B00:
B00.noahmpv1.3.b00_run1crop2irr2.HHH_T2_comparison.png
B01:
B01.noahmpv1.3.b01_run1crop2irr2.HHH_T2_comparison.png
B02:
B02.noahmpv1.3.b02_run1crop2irr2.HHH_T2_comparison.png
B04:
B04.noahmpv1.3.b04_run1crop2irr2.HHH_T2_comparison.png
B05:
B05New.noahmpv1.3c2020.b05_run1crop2irr2.HHH_T2_comparison.png
B06:
B06.noahmpv1.3.b06_run1crop2irr2.HHH_T2_comparison.png
B07:
B07.noahmpv1.3.b07_run1crop2irr2.HHH_T2_comparison.png
B08:
B08.noahmpv1.3.b08_run1crop2irr2.HHH_T2_comparison.png
B05NEW:
B05New.noahmpv1.3c2020.b05_run1crop2irr2.HHH_T2_comparison.png
 

Attachments

  • B05.noahmpv1.3.b05_run1crop2irr2.HHH_T2_comparison.png
    B05.noahmpv1.3.b05_run1crop2irr2.HHH_T2_comparison.png
    307.6 KB · Views: 6
xiao.zh said:
Hi all,
I'm working on a WRF case study for the Huang-Huai-Hai Plain (China) and found that the simulated T2 (2m temperature) consistently shows significant errors compared to observed monthly mean values, with RMSE ranging from 2 to 4°C.
Here are the cases that I have tested. Forced with ERA5.
View attachment 18098
The following are my results. B00 for 2010-2022, the rest only run for 2010.
Between the B04 and B06 schemes, one modified dveg (from 2 to 8), and the other switched from Noah-MP to Noah. While these adjustments improved the simulated temperature, it remains systematically lower than observations.
I also tested potential snow-related issues (B02, opt_snf=4) as suggested in forum discussions, but the impact was negligible.
Currently, I’m experimenting with FNL meteorological data (ds083.2).
Could anyone suggest additional avenues to address this persistent cold bias in my simulation?


B00:
View attachment 18089
B01:
View attachment 18090
B02:
View attachment 18091
B04:
View attachment 18092
B05:
View attachment 18094
B06:
View attachment 18095
B07:
View attachment 18096
B08:
View attachment 18097
B05NEW:
View attachment 18094
Click to expand...
Modify your LSM to RUC，have a try.
 
haiqingsong said:
Modify your LSM to RUC，have a try.
Click to expand...
Thanks for your reply. I tried to use RUC, but I got an error while running real.exe.
d01 2010-01-01_00:00:00 No average surface temperature for use with inland lakes
Assume non-RUC LSM input
from Noah to RUC - compute Noah bucket
d01 2010-01-01_00:00:00 forcing artificial silty clay loam at 401 points, out of 25281
error in the grid%tsk
i,j= 67 1
grid%landmask= 0.0000000E+00
grid%tsk, grid%sst, grid%tmn= 0.0000000E+00 0.0000000E+00 0.0000000E+00
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 3185
grid%tsk unreasonable
Click to expand...

Here is my namelist.input
&physics
mp_physics = 4,
cu_physics = 93,
ra_lw_physics = 1,
ra_sw_physics = 1,
bl_pbl_physics = 1,
sf_sfclay_physics = 1,
sf_surface_physics = 3,
radt = 15,
bldt = 0,,
cudt = 0,
icloud = 1,
num_land_cat = 21,
sf_urban_physics = 0,
fractional_seaice = 1,
rdlai2d = .true.,
num_soil_layers = 9
usemonalb=.true.
mosaic_lu=1
mosaic_soil=1

Have you met this error before?
 
xiao.zh said:
Thanks for your reply. I tried to use RUC, but I got an error while running real.exe.


Here is my namelist.input
&physics
mp_physics = 4,
cu_physics = 93,
ra_lw_physics = 1,
ra_sw_physics = 1,
bl_pbl_physics = 1,
sf_sfclay_physics = 1,
sf_surface_physics = 3,
radt = 15,
bldt = 0,,
cudt = 0,
icloud = 1,
num_land_cat = 21,
sf_urban_physics = 0,
fractional_seaice = 1,
rdlai2d = .true.,
num_soil_layers = 9
usemonalb=.true.
mosaic_lu=1
mosaic_soil=1

Have you met this error before?
Click to expand...
FNL forcing runs ok
 
It is not unexpected that long-term WRF simulations often yield relatively large bias. The namelist options below may help reduce the bias:

ysu_topdown_pblmix = 1
topo_shading = 1

You may also try the RRTMG radiation scheme, which may perform better than rrtm.

Note that interpolation from model grids to stations may also introduce some bias.
 
Ming Chen said:
It is not unexpected that long-term WRF simulations often yield relatively large bias. The namelist options below may help reduce the bias:

ysu_topdown_pblmix = 1
topo_shading = 1

You may also try the RRTMG radiation scheme, which may perform better than rrtm.

Note that interpolation from model grids to stations may also introduce some bias.
Click to expand...
Hi Ming,
Thanks for you reply.
RRTMG radiation scheme indeed performs better.
I also found that "dveg" may introduce unexpected LAI bias, I think this may related to T2 bias in some region. I tried 2,4,5,8. The default 4 performs better.
1747964451353.png
I also got strange "SNOWH" in my simulation, which is unreasonable in june 15. Opt_snf=4 or 5 was not helpful in my case.
1747965513422.png
By change default "opt_rad" 3 to 2 helps reduce the unusual "SNOWH".
I am runing cases with the namelist options you suggest. I will update here once I get result.

Xiao
 
xiao.zh said:
Hi Ming,
Thanks for you reply.
RRTMG radiation scheme indeed performs better.
I also found that "dveg" may introduce unexpected LAI bias, I think this may related to T2 bias in some region. I tried 2,4,5,8. The default 4 performs better.
View attachment 18148
I also got strange "SNOWH" in my simulation, which is unreasonable in june 15. Opt_snf=4 or 5 was not helpful in my case.
View attachment 18149
By change default "opt_rad" 3 to 2 helps reduce the unusual "SNOWH".
I am runing cases with the namelist options you suggest. I will update here once I get result.

Xiao
Click to expand...
When dveg=2,5，6 ，dynamic vegetation option was on. LAI was predicted.
 
haiqingsong said:
When dveg=2,5，6 ，dynamic vegetation option was on. LAI was predicted.
Click to expand...
Thanks for your reply. When dynamic LAI was off, the cold bias related to LAI was gone in my case, the RMSE was about 1.7 ℃ now. I think there are still cold bias related to SNOWH.
 
Ming Chen said:
It is not unexpected that long-term WRF simulations often yield relatively large bias. The namelist options below may help reduce the bias:

ysu_topdown_pblmix = 1
topo_shading = 1

You may also try the RRTMG radiation scheme, which may perform better than rrtm.

Note that interpolation from model grids to stations may also introduce some bias.
Click to expand...
Hi Ming,
I run a case with the options you suggest, the cold bias still exists.
1747982689889.png
Do you have other suggestions for me?
By the way, I checked my test cases with different mp_physics schemes(4,10,11,6). The SNOWH exists in all these cases on 15, June.

Xiao
 
Thank you for the update and I am glad the model performance is improved.

Several changes have been made in the snow package since wrfv4.2, and I am suspicious that these changes may introduce new issues you have seen.

Just wonder what data did you us to force WRF run? Can you check wrfinput and let me know what are the initial value of snowh and snow?

Thanks.
 
Ming Chen said:
Thank you for the update and I am glad the model performance is improved.

Several changes have been made in the snow package since wrfv4.2, and I am suspicious that these changes may introduce new issues you have seen.

Just wonder what data did you us to force WRF run? Can you check wrfinput and let me know what are the initial value of snowh and snow?

Thanks.
Click to expand...
There are 2 issues:
github.com

Noah mp snow by cenlinhe · Pull Request #1403 · wrf-model/WRF

TYPE: enhancement, new feature KEYWORDS: Noah-MP, snow, MPTABLE, parameter SOURCE: Cenlin He (NCAR/RAL) DESCRIPTION OF CHANGES: Several Noah-MP snow-related aspects have been updated to improve sno...
github.com github.com
github.com

Noah mp snow update by cenlinhe · Pull Request #1345 · wrf-model/WRF

TYPE: enhancement, new feature KEYWORDS: Noah-MP, snow, MPTABLE, parameter SOURCE: Cenlin He (NCAR/RAL) DESCRIPTION OF CHANGES: Several Noah-MP snow-related aspects have been updated to improve sno...
github.com github.com
 
Ming Chen said:
Thank you for the update and I am glad the model performance is improved.

Several changes have been made in the snow package since wrfv4.2, and I am suspicious that these changes may introduce new issues you have seen.

Just wonder what data did you us to force WRF run? Can you check wrfinput and let me know what are the initial value of snowh and snow?

Thanks.
Click to expand...
Hi Ming,
I used ERA5 to force the wrf run. The snowh and snow are as follows:
1748221078650.png
1748221095188.png
I have also run a test case with FNL forces in 2020. Snow still exists in June.
1748221322488.png
wrfinput:
1748221388317.png
 
The WRF cold bias over snow covered region is a long-standing known issue. We usually see this issue during cold snow season. However, it seems that your cold bias peaks during summer, which is weird. Since you are using Noah-MP, you could try the following two things:
1. reduce snow cover by increasing MFSNO and/or SCFFAC values for specific vegetations types over your domain in MPTABLE.TBL;
2. reduce canopy heat storage term by changing the CBIOM value in MPTABLE.TBL to a very small number (e.g., 0.0001).
 
You must log in or register to reply here.
Top