Unrealistic T2 when using time varying aerosols and NoahMP

[scapps]

Greetings,

I am seeing very unrealistic T2 (>315K in the winter) values primarily over LU_INDEX=16 grid cells mostly during the nighttime hours when using WRF version 4.3.0 with the following namelist.input settings:

&time_control
auxinput15_inname = 'wrfgeos_d<domain>',
auxinput15_outname = 'auxinput15_d<domain>_<date>',
auxinput15_interval = 60, 60, 60,
io_form_auxinput15 = 2,

&physics
aer_opt = 2,
aer_aod550_opt = 2, 2, 2,
aer_angexp_opt = 2, 2, 2,

I am using time-varying aerosols from GEOS5 forecasts (wrfgeos_d<domain> files attached). I see no extreme aerosol AOD and ANG values in those files. T2 increases throughout the nighttime (see attached image) when it should be decreasing.

This does not happen when I use constant aerosols with the following namelist.input settings:
aer_opt = 2,
aer_aod550_opt = 1, 1, 1,
aer_aod550_val = 0.12,
aer_angexp_opt = 1, 1, 1,
aer_angexp_val = 1.3,

All other output appears to be fine (TSK, etc.), so the problem could be with how the diagnostic T2 is calculated within the NoahMP LSM.

I can provide the wrfgeos, wrfinput, wrfbdy, and other files upon request.

Thank you.

 

[scapps]

I have confirmed that this issue only appears when using NoahMP.

 

[juliaandrys]

Hi there,

I am having a similar issue when using aer_opt = 2 and NoahMP. I noticed some unreasonable T2 values in the D02 data (particularly over water) and have tracked this down to an issue with the Q2 variable. At certain timesteps (the second to the seventh timesteps in all the d02 hourly data files), Q2 is zero over water.

This issue only occurs in the nested domain while the outer domain values are fine.

How does your Q2 data look? Also, is the issue present in your outer domain or just in the two nested domains?

I’m attaching my namelist and a screen dump of the problematic Q2 output.

 

[scapps]

We found a way around our issue by adding the following to the global NetCDF attributes of our wrfgeos_<domain> files:

ncatted -O -h -a ISWATER,global,o,i,17 wrfgeos_d01

The problem was in module_surface_driver.F. After the first time the GEOS aerosols were read in, ISWATER was redefined from 17 to 16, which in MODIS is barren land but was the water class in USGS. This is a bug in the WRF code which should be addressed. For now, we have a workaround.