*output_diagnostics = 1* breeds weird minima/maxima

[stormchasegenie]

Greetings,

I am running WRF v4.1.3 using the output_diagnostics = 1 option. In short WRVF seems to be either 1. integrating minima and maxima in 2-m temperature that are unphysical (e.g. 0 K for 2-m temperature, 450 K for tmax) or 2. this is a problem with the diagnostics. Could this be the result of the physics suite that I am using? See below my namelist.

Thanks,
-Stefan

&time_control
run_days = 90,
run_hours = 0,
run_minutes = 0,
run_seconds = 0,
start_year = 1980, 1980, 1980, 1980
start_month = 08, 08, 08, 08,
start_day = 01, 01, 01, 01,
start_hour = 00, 00, 00, 00,
end_year = 1981, 1981, 1981, 1981
end_month = 09, 09, 09, 09,
end_day = 01, 01, 01, 01,
end_hour = 00, 00, 00, 00,
interval_seconds = 21600
input_from_file = .true.,.true.,.true.,.true.,
history_interval = 360, 360, 360, 360,
frames_per_outfile = 1, 1, 1, 1,
restart = .false.,
restart_interval = 14400,

write_hist_at_0h_rst = .true.
adjust_output_times = .true.,
override_restart_timers = .true.

io_form_history = 2
io_form_restart = 2
io_form_input = 2
io_form_boundary = 2

io_form_auxinput2 = 2

io_form_auxinput4 = 2
auxinput4_inname = "wrflowinp_d<domain>",
auxinput4_interval_m = 360, 360, 360, 360,

output_diagnostics = 1
auxhist3_outname = "minmax_d<domain>_<date>",
auxhist3_interval = 1440,
frames_per_auxhist3 = 1,
io_form_auxhist3 = 2

auxhist7_outname = "auxhist_d<domain>_<date>",
auxhist7_interval = 60,
frames_per_auxhist7 = 1, 1,
io_form_auxhist7 = 2

debug_level = 0,
/

&domains
time_step = 180,
use_adaptive_time_step = .true.
step_to_output_time = .true.
target_cfl = 1.2
max_step_increase_pct = 5, 51
starting_time_step = 54
max_time_step = 72
min_time_step = 36
time_step_fract_num = 0,
time_step_fract_den = 1,
max_dom = 1,
parent_id = 1, 2, 2,
parent_grid_ratio = 5, 3, 3,
i_parent_start = 36, 45, 168
j_parent_start = 19, 89, 131
s_we = 1, 1, 1,
s_sn = 1, 1, 1,
e_we = 271, 244, 193,
e_sn = 341, 493, 292,

e_vert = 40, 40, 40,
p_top_requested = 5000,
num_metgrid_levels = 38,
num_metgrid_soil_levels = 4,
dx = 9000, 3000, 3000,
dy = 9000, 3000, 3000,
grid_id = 2, 3, 4,
parent_time_step_ratio = 5, 3, 3,

feedback = 0,
smooth_option = 0
smooth_cg_topo = .true.,
/

&physics
mp_physics = 51, 51, 51,
cu_physics = 6, 0, 0,
ra_lw_physics = 4, 4, 4,
ra_sw_physics = 4, 4, 4,
bl_pbl_physics = 1, 1, 1,
sf_sfclay_physics = 1, 1, 1,
sf_surface_physics = 4, 4, 4,
radt = 9, 3, 3,
bldt = 0, 0, 0, 0,
cudt = 0, 0, 0, 0,
icloud = 1,
num_land_cat = 21,
sf_urban_physics = 0, 0, 0, 0,
sst_update = 1,
sst_skin = 1,

sf_lake_physics = 1, 1, 1, 1,
use_lakedepth = 1, 1, 1, 1,

co2_ppmv = 337.65585
ch4_ppbv = 1607.6135

/

&noah_mp
opt_run = 1,
opt_sfc = 1,
opt_rsf = 1,
opt_snf = 1,
opt_rad = 1
/

&fdda
grid_fdda = 0
gfdda_inname = "wrffdda_d<domain>"
gfdda_interval_m = 360,
gfdda_end_h = 4800000,
io_form_gfdda = 2
fgdt = 0,
if_no_pbl_nudging_uv = 1
if_no_pbl_nudging_t = 1
if_no_pbl_nudging_q = 1
if_no_pbl_nudging_ph = 1
if_zfac_uv = 0
if_zfac_t = 0
if_zfac_q = 0
guv = 0.0003
gt = 0.0003
gq = 0.0
gph = 0.0003
xwavenum = 3
ywavenum = 3

/

&dynamics
hybrid_opt = 0,
w_damping = 0,
diff_opt = 2, 1, 1, 1,
km_opt = 4, 4, 4, 4,
diff_6th_opt = 0, 0, 0, 0,
diff_6th_factor = 0.12, 0.12, 0.12, 0.12,
base_temp = 290.
damp_opt = 3,
zdamp = 10000., 10000., 10000.,
dampcoef = 0.2, 0.2, 0.2, 0.2,
khdif = 0, 0, 0, 0.,
kvdif = 0, 0, 0, 0.,
non_hydrostatic = .true., .true., .true., .true.,
moist_adv_opt = 1, 1, 1, 1,
scalar_adv_opt = 1, 1, 1, 1,
gwd_opt = 0,
/

&bdy_control
spec_bdy_width = 5,
specified = .true.
/

&grib2
/

&namelist_quilt
nio_tasks_per_group = 0,
nio_groups = 1,
/

 

[mgduda]

I've moved this topic from the MPAS-Atmosphere section of the forum to the WRF section of the forum.

 

[stormchasegenie]

I’m wondering if the adaptive time step could be the issue here. Presumably the model could integrate unphysical quantities that end up getting populated to the diagnostic arrays, while more physical values are used to actually integrate the model as the time step is shortened following a CFL error? Just a thought....

 

[stormchasegenie]

Update -- when I set to a constant time step, the output looks as it should, and there are not unphysical values in t2min and t2max.

Has there been any updates to output_diagnostics that allow it to function properly with adaptive time stepping? What is happening is that unphysical values that occur with CFL errors are making into the diagnostic arrays (e.g. 5 K in T2MIN). A CFL issue is registered, and the driver runs the diagnostic again, simulating a physical T2MIN of, for instance, 270 K. Since this value is not the minimum in a given time window, the 5 K value gets written to the array.

Any tips to get around this? The CPU savings with adaptive time stepping are awesome, and I am interested in the daily t2min and t2max.

All my best,
-Stefan

 

[kwerner]

Hi Stefan,
I am glad that you were able to track the problem down to the combination of output_diagnostics and adaptive time-stepping. Unfortunately at this time, those will not work together. I reached out to a couple of colleagues who agree that variables may not be accurate, if they work at all.
The diagnostics option doesn't account for variable steps. There may be ways to modify the code to allow you to use both, but at this time, we don't have a solution. Perhaps someone else will see this and have some suggestions.