Relative Humidity Bias Accumulates After First Day — Is FDDA Needed?

[ZHOU Wan]

Hi all,
I'm running WRF for a multi-day summer case (August 2022) over a subtropical urban area. The temperature simulation is fairly accurate, but I observed a consistent underestimation of relative humidity after the first day of simulation. On the first day, RH matches observations reasonably well, but from the second day onward, the daily maximum RH becomes increasingly underestimated, especially during the daytime and at night.



I’ve tested several physical scheme combinations to address this issue:

1. Changed land surface model from Noah (sf_surface_physics = 2) to Noah-MP (sf_surface_physics = 4)
2. Switched PBL scheme from bl_pbl_physics = 7 to MYNN (bl_pbl_physics = 5)
3. Updated radiation schemes to RRTMGto better match the new PBL:
   • ra_lw_physics = 4 (RRTMG longwave)
   • ra_sw_physics = 4 (RRTMG shortwave)

Despite these changes, the RH simulation still shows a similar bias pattern.

My question is:
1、Could this issue be caused by the lack of updated lateral boundary conditions?
2、Would using FDDA (Four-Dimensional Data Assimilation) or nudging with daily reanalysis (e.g., ERA5) help maintain water vapor consistency and reduce RH bias?

Any suggestions or related experiences would be greatly appreciated!

Thanks in advance！

PS: namelist.input

&physics
physics_suite = 'CONUS'
mp_physics = 5, 5, 5,
cu_physics = 1, 0, 0,
ra_lw_physics = 4, 4, 4,
ra_sw_physics = 4, 4, 4,
bl_pbl_physics = 5, 5, 5,
sf_sfclay_physics = 1, 1, 1,
sf_surface_physics = 4, 4, 4,
radt = 10, 10, 10,
bldt = 10, 10, 10,
cudt = 5, 0, 0,
icloud = 1,
num_land_cat = 61,
num_soil_layers = 4,
sf_urban_physics = 1, 1, 1,
sf_surface_mosaic = 1,
mosaic_cat = 3,
slucm_distributed_drag = .false.,
use_wudapt_lcz = 1,

 

[ZHOU Wan]

I'd like to add one more observation and question based on the analysis of specific humidity (Q2).

In our case (August 2022, subtropical urban area), we noticed that the underestimation of relative humidity (RH) is closely related to a systematic decrease in specific humidity (Q2) starting from the second day of simulation. This is clearly illustrated in the attached plots below for two stations (BB and BN), where WRF Q2 drops significantly after Day 1, while ERA5 and observations remain much higher.
This suggests that the RH bias is likely driven by a dry bias in Q2, not just temperature-related errors.

So we’re wondering: How is Q2 determined in WRF? And how can we improve its simulation? Appreciate any suggestions!​

 

[ZHOU Wan]

I’ve noticed that the first model level (z[0]) in our WRF simulations is consistently located several tens of meters above the actual terrain height (HGT) at our observation stations.
Since both T2 and Q2 are diagnostic variables in WRF, derived using Monin-Obukhov similarity theory and extrapolated from the lowest model level, I’m wondering:

Could this vertical offset between the terrain height and the first model level be a significant source of error in the diagnosed T2 and Q2, particularly under conditions with strong vertical gradients near the surface (e.g., during stable nights or sharp moisture transitions)?

 

[kwerner]

Hi, Apologies for the delay. You can try checking if this also happens outside urban areas, or map RH to see if it is a large-scale drying. It could possibly be some sort of urban effect.

 

[ZHOU Wan]

Hi, Apologies for the delay. You can try checking if this also happens outside urban areas, or map RH to see if it is a large-scale drying. It could possibly be some sort of urban effect.

Thank you for the suggestion regarding the urban effect and large-scale drying.

I have looked into the issue further and found that the sharp drop in RH and Q2 seems to be largely related to an insufficient spin-up period.

As shown in the attached figure, when I extended the spin-up period to 6 days (starting the simulation on July 26th instead of August 1st), the sudden drop in humidity on August 2nd was significantly alleviated.


However, this brings up a question regarding best practices: When I originally used August 1st as the start date, the drop occurred just one day later on August 2nd. Could you offer any general guidance on how to determine the appropriate length for the spin-up period to avoid these initial imbalances?

Thanks again for your help.

 

[kwerner]

Many apologies for the delay in response over the holidays. I'm glad to hear that you found a way to get past this issue. Regarding needing to spin-up for 6 days to overcome it, that is not normally the case. The recommended spin-up time is typically about 12 hours or so. Hopefully the issue with your case was just a rare situation and your future simulations don't require a 6-day spin-up time.