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

Strange T2 bias in newer WRF versions

Hi All,

I am testing the performances of the lastest release (v.4.4.1) compared to v4.2.2. Both the simulations are forced by ERA5 and use the same namelists (.wps and .input); for the validation, I extract T2 from wrfout and compare, over different seasons, the temperature with t2m from ERA5.
Looking at the v.4.4.1 bias there are some patchy areas where the model gets crazy, especially during summer, while the same does not happen into the older V4.2.2. I was wondering why this happens and how can I solve this issue? I also tried to test several different configurations, changing the physical parameterizations but it did not solve the problem. Any suggestion is welcome!
 

Attachments

  • WRF4.2.2_t2m_Bias.png
    WRF4.2.2_t2m_Bias.png
    453.1 KB · Views: 53
  • WRF4.4.1_t2m.png
    WRF4.4.1_t2m.png
    700 KB · Views: 48
  • WRF4.4.1_t2m_Bias.png
    WRF4.4.1_t2m_Bias.png
    470 KB · Views: 59
Hi,
Can you do a test to see if you see the same issue with V4.4 and V4.3, so we can narrow down which version this started in? Then please attach your namelist.input file. Thanks!
 
Hi,
Can you do a test to see if you see the same issue with V4.4 and V4.3, so we can narrow down which version this started in? Then please attach your namelist.input file. Thanks!
Hi kwerner,
thanks for the reply and your help.
I am facing this trouble in any version since V4.3, while V4.2.2 (with updated MFSNO values in MPTABLE.TBL) works fine.
I tested different physical parameterizations and more or less this issue pops up in any of them; it disappears only when I move from NOAH-MP to NOAH. Anyhow, I attach a sample namelist where the odd pattern is well defined.

Besides, I was looking in more details at T2 over a single point where the model gets crazy (please see attached figure). I realized that T2 is wrong because heat fluxes become unrealistic at the beginning of May and, in turns, they are wrong because soil moisture has wrong values. I have uploaded a sample file on Nextcloud named WRF_V4.4.1_vars.zip; you can easily cross check what is going on at point x=175, y=112.
As most of the Noah-MP related updates from WRFv4.2.2 to WRFv4.3 (and newer version) involve the snow part, I suspect the issue comes from one of these snow updates which affect soil moisture; however, looking at the snow cover I do not find anything particularly wrong (please look at file WRF_V4.4.1_vars.zip).
I will keep investigating this issue, but any insight would be very appreciated.
Alessandro
 

Attachments

  • T2_Seasonal_Cycle.gif
    T2_Seasonal_Cycle.gif
    13 KB · Views: 51
  • namelist.input
    5.4 KB · Views: 17
Well, I didn't solve it really, because I rolled back to 4.3.3. Then at least it doesn't screw up by heavy rainfalls conditions.
I didn't test in snow conditions on the ground yet.
 
Hi,
Can you do a test to see if you see the same issue with V4.4 and V4.3, so we can narrow down which version this started in? Then please attach your namelist.input file. Thanks!
Hi kwerner,
just to let you know that the same issue also occurs in the newly released version v4.4.2. Any update on your side? Were you able to look at the files I uploaded on Nextcloud?
 
Hi,
Apologies for the delay. Before taking time off for the holidays, I requested the review of a colleague, but they had already gone on holiday leave. I believe I've tracked down the actual code commit that causes the change. However, I'm not sure it's actually incorrect. It looks like in JJA, in V4.2.2, you had a warm bias of ~4 degrees, and then in V4.4.1 (same as V4.3), you have a cold bias of ~4 degrees. I'm going to reach out to another colleague and see if they have any thoughts. I'll keep you posted. Thank you for your patience.
 
Hi kwerner,
thanks again for the time spent to help me.
I would just point out that the problem here is not the magnitude of the bias and how it changes between the different WRF versions, but the patchy points where the model gets crazy during summer (please look at the T2_Seasonal_cycle.gif I posted before) since v4.3.

Anyhow, I have had a chat with Noah-MP expert and it seems the problem is caused by the canopy heat capacity. Reducing the value of "0.02" in the following code in the VEGE_FLUX subroutine inside phys/module_sf_noahmplsm.F apparently solves the problem.

! canopy heat capacity HCV = 0.02*VAIE*CWAT + CANLIQ*CWAT/DENH2O + CANICE*CICE/DENICE !j/m2/k

It would be nice investigating further after the holiday to understand why this happens and why some Noah-MP schemes are more sensitive to this issue than others.

Enjoy your holidays,
Alessandro
 
Hi Alessandro
I have a similar problem with a strange T2 bias in WRF 4.4.1. I was very interested in your solution to decrease the value of the constant "0.02". You wrote that the value "0.02" should be reduced. What value do you recommend or use to eliminate this effect?
Mariusz
 
Hi Alessandro
I have a similar problem with a strange T2 bias in WRF 4.4.1. I was very interested in your solution to decrease the value of the constant "0.02". You wrote that the value "0.02" should be reduced. What value do you recommend or use to eliminate this effect?
Mariusz
Hi Mariusz,
I still don't have an answer to this question as I am still testing different values, but reducing the coefficient from 0.02 to 0.002 solves the problem in a test run I did. However, the smaller this coefficient is, the stronger the summer warm bias and the winter cold bias are.
Hope it helps,
Alessandro
 
@wrf_alessandro
I've spoken to the development group for NoahMP and they let me know they have been communicating with you and are the ones who recommended the coefficient change. They have submitted a code change request for this. I'm glad you were able to find a workaround and thank you for bringing this to our attention!
 
Mariusz,
Please update any information you get from the NoahMP group. We are also curious about this issue and would like to know for sure what is going on. Thanks in advance.
 
Dear all,
In WRFv4.5 the patch is applied to solve the issue reported here. However, the parameter CBIOM in the MPTABLE is set to the same value it was in the former 4.4.2 version (i.e. 0.02). As we are planning to start longterm simuations, would you suggest to change this to a smaller value, e.g. 0.002, or we keep the value as it is?
Thank you in advance
Josipa
 
Hi Josipa,
as far as I understood the optimal solution would be to change the CBIOM for the only landcover types of the patchy areas.
Cheers,
Alessandro
 
Top