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

Thank you Alessandro a lot for your response. I am not sure how to find out the patchy areas. Does it mean to follow your steps and run a test run for cca 1 year, then check if the temperature pattern has any patchy areas. If yes, then check the corresponding land-use category and change the CBIOM values accordingly before the start of the new run. And if no patchy pattern appears, no changes should be applied. Would this be the procedure, or something different?
Thank you and cheers,
Josipa
 
Hi Josipa, yes the procedure is correct. If I am not wrong, I already tested your namelist and one year is enough to pop up the patchy areas (I did test 1980 or 1981).
In case no patchy pattern appears you could try to run the model over a different year; in any case I would stay on the safe side reducing CBIOM as the issue could arise during the simulation.
Alessandro
 
This sounds promising as the issue is more apparent in the summer season. I will test it with the default values for CBIOM.
Thank you all very much for the suggestions,
Josipa
 
Hello @Josipa @Ming Chen did you ever manage to diagnose this problem? I am having similar issues I think and I am using WRF V4.6. I have attached a plot.

I am running over Siberia in the summer. The plot shows the average of May-August T2. The patches gradually develop a couple of weeks after the start of the run, then persist throughout the rest of the run. I am using NOAH-MP. I have attached my namelist. I noticed that the cold patches exist in the TSK in the same locations, as well as TSLB.

Please let me know if there is any solution. Many thanks
 

Attachments

  • patchy_T2.png
    patchy_T2.png
    131.2 KB · Views: 15
  • namelist.input
    3.7 KB · Views: 4
Hi,
I tested WRF 4.6 few days ago and I confirm this issue still develops during warm season.

To avoid this happens, change in MPTABLE.TBL all the CBIOM values from the default (i.e. 0.02) to:

CBIOM = 0.002, 0.002, 0.002, 0.002, 0.002, 0.002, 0.002, 0.002, 0.002, 0.002, 0.002, 0.002, 0.002, 0.002, 0.002, 0.002, 0.002, 0.002, 0.002, 0.002,

Hope it helps,
Alessandro
 
Josipa,
I talked to our expert and he suggested that you stay with the original value of 0.02. CBIOM is canopy biomass heat capacity parameter, and a very small value is physically unreasonable.
 
Thank you, Ming, for your suggestion. We started running the model with the original value of 0.02, but we encountered patchy temperature fields and stationary low-level clouds. Cold pools began to appear during cold events. Multiple groups conducted long-term simulations (6 months to 1 year), and we all experienced the same issue. Based on the suggestion given here in this discussion, we decided to set CBIOM to a lower value. Since then, the cold pools have disappeared, and the output seems realistic. Therefore, we decided to continue our runs. Please check the issue: T2 patchy biases · Issue #2 · CORDEX-WRF-community/euro-cordex-cmip6. What would you say that we can expected as a consequence of setting CBIOM to 10x lower value?
 
Hi all,
Just to give some more impetus to this conversation: We have also encountered the patchy T2 problem in long-term simulations targeting Europe (using ERA5 as ICBC and the Noah-MP as LSM, example namelist.input attached).
The issue occurs in both WRFV4.4.1 (left side of the figure) and WRFV4.5.2 (right side); however, its magnitude and extent are mitigated in the latter.

wrf_v441_v452_t2_problem.png

The cold patches occur during spring and persist into the summer. They are consistently located above the same geographical areas for tens of days, even months. Temperatures around 275-280 K over Western Europe (at 12 UTC) in summer for weeks are totally unreasonable!

wrf_t2_problem.png

Hope this issue gets resolved soon.

Best regards,
Akos
 

Attachments

  • namelist.input
    8.6 KB · Views: 4
@vaakos
Akos,
Would you please try the solution proposed by Josipa and see whether the cold patches can go away? Please keep me updated about the results. Thanks in advance.
 
Hello Ming,

Thank you for reaching out. When I change CBIOM values in MPTABLE.TBL from 0.02 to 0.002 for all categories, the patches indeed disappear. See the figure below.

wrf_t2_problem_fix.png
 
Hello,

I just would like to post an update on this topic.
Earlier, following the solution proposed by Josipa, I changed CBIOM values in MPTABLE.TBL from 0.02 to 0.002 for all categories (WRFV4.5.2).
As I reported back then, the patches disappeared.
However, I recently noticed that when shifting the microphysics scheme (mp_physics from option 8 to 10, so from Thompson to Morrison), the steady and persistent patches reappear.

The figure below shows T2 with the Thompson scheme (left) and the Morrison scheme (right).
wrf_patches.png
Therefore, there also seems to be a microphysics scheme dependence.
I hope we can get further insights into this issue soon.

Best regards,
Akos
 
Last edited:
I confirm that the problem is not completely solved by setting CBIOM=0.002. It is better but still ongoing. I use mp = 28 and NOAH-MP
 
Last edited:
Dear all,

I'm writing a follow-up on this topic because the issue still persists in the latest model version, WRFV4.7.0.

The problem remains the formation of persistent, steady cold patches that appear near the surface in association with extensive cloud cover. These patches emerge after a few days of simulation.

I understand that WRF is primarily designed for short-term numerical weather prediction. However, this is not simply a case of the model developing biases over long-term integration. Rather, the phenomenon appears completely unphysical and may indicate a potential code error. Given the widespread use of WRF as a regional climate model, I believe this issue warrants thorough investigation.

To support this, I’ve uploaded output from the first few days of my simulation. In the hourly_output_d02_* files, the variables T2 and TSK clearly show unphysical values (e.g., over the western parts of the domain) as early as the second day of integration.

I’ve also included the namelist.input and met_em* files to facilitate reproducibility. The initial and boundary conditions are from ERA5.

Please follow this link to access the files.

I hope we can eventually find a solution to this.

Best regards,
Akos
 
vaakos said:
Dear all,

I'm writing a follow-up on this topic because the issue still persists in the latest model version, WRFV4.7.0.

The problem remains the formation of persistent, steady cold patches that appear near the surface in association with extensive cloud cover. These patches emerge after a few days of simulation.

I understand that WRF is primarily designed for short-term numerical weather prediction. However, this is not simply a case of the model developing biases over long-term integration. Rather, the phenomenon appears completely unphysical and may indicate a potential code error. Given the widespread use of WRF as a regional climate model, I believe this issue warrants thorough investigation.

To support this, I’ve uploaded output from the first few days of my simulation. In the hourly_output_d02_* files, the variables T2 and TSK clearly show unphysical values (e.g., over the western parts of the domain) as early as the second day of integration.

I’ve also included the namelist.input and met_em* files to facilitate reproducibility. The initial and boundary conditions are from ERA5.

Please follow this link to access the files.

I hope we can eventually find a solution to this.

Best regards,
Akos
Click to expand...
Your dveg option is 7.
The default is 4.
Could the problem be caused by the vegetation option?
I checked the changes from v4.2.2 to v4.3.1：Comparing release-v4.2.2...release-v4.3.1 · wrf-model/WRF
A snow related scheme and a irrigation scheme were improved.
 
Last edited:
I think that it is a persistent problem.
The only workaround that is working for me is to set CBIOM = 0.002 in MPTABLE.TBL, as explained above one year ago.
I use mp=28.
 
You must log in or register to reply here.
Top