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

Question about isfflx and icloud


New member
Hi WRF folks,

I've noticed that the surface temperatures in WRF simulations I'm running for 8 June 2019 are unreasonably cold after ~22 UTC (in some places in the open warm sector away from storms they're ~10-20 F too cold by the end of a several-hour simulation). Furthermore, temperatures are also too cold under cloud cover and drop 3-6 F+ in the first 15 minutes of the simulation from reasonable initial conditions. I found that changing the icloud variable in the namelist from 1 to 0 made the temperatures under cloud cover much more reasonable, and changing the isfflx variable from 1 to 0 makes the surface temperatures away from convection more reasonable. From reading some of the WRF documentation, it sounds like I should have both of these parameters set to 1 for real-data cases, so I was wondering if having them set to 0 was ok and if there was anything else in the namelist which might be causing this issue. I've attached the namelist I've been using, and I've also listed the main physics settings I've been using below:

mp_physics = 17
ra_lw_physics = 1
ra_sw_physics = 1
radt = 3,
sf_sfclay_physics = 1,
sf_surface_physics = 3,
num_soil_layers = 6,
bl_pbl_physics = 1,
bldt = 0,
cu_physics = 0,
cudt = 0,
isfflx = 1,
ifsnow = 1,
icloud = 1,
surface_input_source = 3,
num_land_cat = 21,
sf_urban_physics = 0,
sf_ocean_physics = 0,
do_radar_ref = 1,


  • namelist.input
    3.9 KB · Views: 7
For reveal-data case, isfflx must be 1 because this option forces the model to use fluxes calculated in th surface scheme. isfflx = 0 only works for ideal case.
iCloud =1 will allow the radiation scheme to consider cloud radiation effects and thus is more physically reasonable.
Please set them to 1 and don't use the option 0.
Thanks! I'll plan on switching them back to 1. Are there any other settings in the namelist which you think might have been causing the unreasonably-cold surface temperatures when I had isfflx and icloud set to 1?
Would you please change the following options in your namelist.input:
(1) time_step = 15
(2) ra_lw_physics = 4 and ra_sw_physics = 4
(3) diff_opt = 2
(4) ysu_topdown_pblmix = 1
The above options are more physically reasonable and hopefully they can yield better results for you.
Thanks for those suggestions! I just made those changes and reran WRF, and unfortunately the unusual temperature drop is still present in the simulation. To give a better idea of what I'm seeing, I've attached some images from the model output. The first image is temperature from the initial conditions I'm using, and the second image is temperature and reflectivity from 15 minutes into the model forecast. In both images, the color-filled dots are temperature observations from the KS mesonet for verification. The third image shows the temperature change over the first 15 minutes of the run--there's widespread 5+ degree drops over much of the cloud-covered area, and most of the clear area drops from 1-4 degrees over the first 15 minutes. Let me know if you've got any other ideas of what might be going wrong, and thanks again for your help.


  • OUT_00min_example.png
    130.5 KB · Views: 7
  • OUT_15min_example.png
    159.8 KB · Views: 7
  • Change_15min_Example.png
    161.2 KB · Views: 8
Would you please run WRF over a longer time period, then look at the results after 12-hr integration?
Note that the values in the initial condition were purely derived from the large-scale forcing data, while the results at 15-minute is from WRF physics and dynamics. The large differences between them are somehow understandable. In addition, the model needs some spin-up time and 15 minutes might be sufficient.
Please run WRF a little bit longer, then look at the results and hopefully the simulation could be more reasonable.
So this particular WRF run went out to 4 hours, and the cold bias still existed, although most of it originated in that first 15 minutes. I'm using WRF for 15-minute free forecasts between data assimilation cycles with DART, so in order to cycle the DA system at 15-minute intervals I need to have reasonable 15-minute forecasts. Unfortunately, when cycling at 15-minute intervals the DA system is unable to fully correct for the biases and they end up compounding from cycle to cycle.