Precipitation disappears inside nested domains

[reshma_m]

Hi everyone,
I am running WRF with 3 two-way nested domains and I am experiencing an issue with precipitation fields. When plotting accumulated precipitation over the parent domain (d01), I clearly see square-shaped discontinuities corresponding exactly to the nested domains (d02 and d03). Inside the nested areas, precipitation from the parent domain is almost completely suppressed. The same effect occurs between d02 and d03. It looks like precipitation is being “overwritten” within each child domain area, creating sharp artificial boundaries.

Here is my configuration:
WRF configuration:

• max_dom = 3
• Two-way nesting (feedback = 1)
• smooth_option = 0

Horizontal resolution:

• d01: 15 km
• d02: 5 km
• d03: 1.67 km
• parent_grid_ratio = 1, 3, 3
• parent_time_step_ratio = 1, 3, 3

Microphysics:

• mp_physics = 8

Cumulus scheme:

• cu_physics = 1 (Kain-Fritsch) for d01
• cu_physics = 0 for d02 and d03

Boundary configuration:

• specified = .true., .false., .false.
• nested = .false., .true., .true.

So d02 and d03 should be receiving their lateral boundary conditions from their respective parent domains. The simulation runs without any runtime error.

My questions:

1. Is this behavior expected with two-way nesting (feedback = 1)?
2. Could feedback be suppressing parent-domain precipitation inside child-domain areas?
3. Should smooth_option be enabled? Could this be related to differences in convective parameterization between d01 (KF on) and d02/d03 (explicit convection)?

Has anyone experienced a similar issue?


Thank you very much for your help !

 

[Ming Chen]

Please see my answers below:

Hi everyone,
I am running WRF with 3 two-way nested domains and I am experiencing an issue with precipitation fields. When plotting accumulated precipitation over the parent domain (d01), I clearly see square-shaped discontinuities corresponding exactly to the nested domains (d02 and d03). Inside the nested areas, precipitation from the parent domain is almost completely suppressed. The same effect occurs between d02 and d03. It looks like precipitation is being “overwritten” within each child domain area, creating sharp artificial boundaries.

Here is my configuration:
WRF configuration:

• max_dom = 3
• Two-way nesting (feedback = 1)
• smooth_option = 0

Horizontal resolution:

• d01: 15 km
• d02: 5 km
• d03: 1.67 km
• parent_grid_ratio = 1, 3, 3
• parent_time_step_ratio = 1, 3, 3

Microphysics:

• mp_physics = 8

Cumulus scheme:

• cu_physics = 1 (Kain-Fritsch) for d01
• cu_physics = 0 for d02 and d03

Boundary configuration:

• specified = .true., .false., .false.
• nested = .false., .true., .true.

So d02 and d03 should be receiving their lateral boundary conditions from their respective parent domains. The simulation runs without any runtime error.

My questions:

1. Is this behavior expected with two-way nesting (feedback = 1)?

Yes this what is expected. With two-way nesting and feedback on, the results of child domain will feedback to its parent domain. The 'square' feature you have seen demonstrates grid-dependent precipitation feature.

1. Could feedback be suppressing parent-domain precipitation inside child-domain areas?

Precipitation in child domain is derived from pjhysics/dynamics in that domain. The feedback will make precipitation in parent-domain consistent with that in child-domain.

1. Should smooth_option be enabled? Could this be related to differences in convective parameterization between d01 (KF on) and d02/d03 (explicit convection)?

It is recommended to turn on

• smooth_option = 2

This option works to make smooth transition of all fields between parent and child domains. It is not relevant to convective parameterization.

Has anyone experienced a similar issue?

We have seen similar features. However, we usually discard results from parent domain and only focus on child domain.

Thank you very much for your help !

 

[reshma_m]

Thank you very much for your helpful explanation and recommendations.

I tested the simulation with smooth_option = 2, and the transitions between the domains are now much smoother. Your explanation about two-way nesting and feedback really helped me understand that this behavior is expected. Following your advice, I will mainly focus my analysis on the innermost domain (d03).

Thanks again for your guidance!

Best regards,

reshma

 

[reshma_m]

Hi, thank you again for your previous explanation and suggestions.

I will follow your recommendation and focus my analysis on the innermost domain (d03). However, I still have a concern regarding the precipitation fields.

Even after applying smooth_option = 2, the square-shaped pattern is still present. What worries me most is that precipitation seems to be significantly reduced (almost disappearing) inside the nested domain areas compared to d01, where precipitation is much higher outside these regions.

Is it normal that precipitation decreases so much when moving from the parent domain (d01) into the nested domains? Or could this indicate an issue with my configuration or physical parameterizations?

Thank you again for your help!

Best regards,
Reshma

 

[Ming Chen]

Hi Reshma,

We did see precipitation differences between parent and child domains, especially when different physics schemes are involved.

Can you upload your namelist.input and plots of precipitation in both domains for me to take a look?

Have you ever verifies which domain has more realistic precipitation?

 

[reshma_m]

Hi, thanks for your response!


Here’s the namelist I’m using:
&time_control
run_days = 0,
run_hours = 275,
run_minutes = 0,
run_seconds = 0,
start_year = 1974, 1974, 1974, 2018,
start_month = 07, 07, 07, 10,
start_day = 17, 17, 17, 31,
start_hour = 00, 00, 00, 12,
start_minute = 00, 00, 00, 00,
start_second = 00, 00, 00, 00,
end_year = 1974, 1974, 1974, 2018,
end_month = 07, 07, 07, 11,
end_day = 21, 21, 21, 06,
end_hour = 23, 23, 23, 00,
end_minute = 00, 00, 00, 00,
end_second = 00, 00, 00, 00,
interval_seconds = 3600,
input_from_file = .true., .true., .true., .false.,
history_interval = 60, 60, 60, 60,
frames_per_outfile = 1, 1, 1, 24,
restart = .false.,
restart_interval = 11520,
override_restart_timers = .true.
auxinput4_inname = "wrflowinp_d<domain>",
auxinput4_interval = 60, 60, 60, 60,
io_form_auxinput4 = 2,
io_form_history = 2,
io_form_restart = 2,
io_form_input = 2,
io_form_boundary = 2,
debug_level = 0,
/

&domains
time_step = 30,
time_step_fract_num = 0,
time_step_fract_den = 1,
max_dom = 3,
s_we = 1, 1, 1,
e_we = 181, 181, 301,
s_sn = 1, 1, 1,
e_sn = 181, 181, 301,
s_vert = 1, 1, 1,
e_vert = 42, 42, 42,
dx = 15000, 5000, 1000,
dy = 15000, 5000, 1000,
grid_id = 1, 2, 3,
parent_id = 1, 1, 2,
i_parent_start = 1, 61, 61,
j_parent_start = 1, 61, 61,
parent_grid_ratio = 1, 3, 5,
parent_time_step_ratio = 1, 3, 5,
feedback = 1,
smooth_option = 2,
num_metgrid_levels = 38,
num_metgrid_soil_levels = 4,
p_top_requested = 5000.0,
eta_levels = 1.000,0.996,0.992,0.988,0.984,
0.980,0.975,0.969,0.962,0.954,
0.945,0.935,0.923,0.909,0.893,
0.875,0.855,0.833,0.808,0.780,
0.749,0.715,0.678,0.638,0.598,
0.558,0.518,0.478,0.438,0.398,
0.358,0.318,0.279,0.241,0.204,
0.169,0.136,0.105,0.076,0.049,
0.024,0.000,
/

&physics
mp_physics = 8, 8, 8,
cu_physics = 1, 0, 0,
ra_lw_physics = 4, 4, 4,
ra_sw_physics = 4, 4, 4,
radt = 15, 15, 15,
sf_sfclay_physics = 1, 1, 1,
sf_surface_physics = 2, 2, 2,
bl_pbl_physics = 1, 1, 1,
sf_urban_physics = 1, 1, 1,
bldt = 0, 0, 0,
cudt = 0, 0, 0,
icloud = 1,
num_soil_layers = 4,
sst_update = 1,
sf_surface_mosaic = 1,
mosaic_cat = 3,
usemonalb = .true.,
rdlai2d = .true.,
/

&fdda
/

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

&bdy_control
spec_bdy_width = 5,
spec_zone = 1,
relax_zone = 4,
specified = .true., .false., .false.,
periodic_x = .false., .false., .false.,
symmetric_xs = .false., .false., .false.,
symmetric_xe = .false., .false., .false.,
open_xs = .false., .false., .false.,
open_xe = .false., .false., .false.,
periodic_y = .false., .false., .false.,
symmetric_ys = .false., .false., .false.,
symmetric_ye = .false., .false., .false.,
open_ys = .false., .false., .false.,
open_ye = .false., .false., .false.,
nested = .false., .true., .true.,
/

&grib2
/
&namelist_quilt
nio_tasks_per_group = 0,
nio_groups = 1,
/

&ideal
ideal_case = 7
/

Additionally, I’ve attached precipitation plots for each domain. Actually, the larger domain produces higher precipitation amounts, which align better with the observations I have, unlike Domains 2 and 3. So, I don’t quite understand the concept of nested domains if, in the end, the coarser domain is the most realistic one.

Let me know if you need anything else!

Thank you very much for your help and your time !

Reshma

 

[Ming Chen]

These domain average time series are over the entire domain, is this correct?

Do you have the time series of averages over D03 for all 3 domains, and averages over D02 for the D01 and D02?

It is also helpful to show me maps of precipitation over the 3 domains .

 

[reshma_m]

Hi !

Thanks for your reply.

Just to clarify, the graph I showed earlier represents rainfall at a single point. For nested domains, I believe we take the rainfall value from the grid cell that contains the point for each domain. Essentially, each grid cell has its own RAINNC value, and this is what is displayed on the map.

If I understand correctly, what you are asking now is to compute a spatial average of the grid cells from D01 over the D03 area, and similarly for the other domains. Could you clarify why this specific averaging is needed? Since my domains are nested with resolutions of 15 km, 5 km, and 1 km, I’m not sure why we would want to average the coarser domain’s values over the smaller domain.

Meanwhile, I’ve attached rainfall maps for all three domains for your reference.

Thanks!

 

[Ming Chen]

Precipitation at a single point cannot represent the model results.

We check spatial distribution and domain-average time series, verify against observations, and then determine how the model performance.

The spatial distributions for the 3 domains clearly indicate that more precipitation occurs in child domains. Please compare them with observations.

 

[reshma_m]

Hi,

Thank you for your explanation. I understand now that looking at precipitation at a single grid point is not sufficient to represent the model behavior, and that a spatially averaged analysis over each domain is more appropriate for evaluation.

Following your suggestion, I computed the domain-averaged rainfall time series for the three nested domains (D01: 15 km, D02: 5 km, D03: 1 km) and plotted them together. The results show that the coarsest domain (D01) produces higher rainfall amounts than the finer domains. This is actually my main concern, as I do not understand why the largest domain gives higher precipitation than the highest-resolution one. This behavior is also consistent with what can be seen in the spatial maps I shared earlier.

In addition, I included the available observations on the same plot. All three domains show a significant underestimation of rainfall compared to observations, which is currently the second main issue I am trying to understand.

Thanks !

 

[Ming Chen]

D01 has the largest precipitation because the large-precipitation area is located outside your child domain.

How did you calculate domain-average observations? This can be tricky...

 

[meteoadriatic]

Sorry to interrupt, but my suggestions:

1) Disable nesting feedback, I don't see any advantage of such configuration, it just produces issues in parent domain, which in turn mess around with boundary conditions of nests. It is against some advices, but that is my experience; I never had any positive success with domain feedbacks.

2) Turn on convective scheme for nests, too; use scale aware MSKF (11) or better, Grell-Freitas (3). They smoothly relax on hi-resolution grids toward no-effect, being safe to run on any grid distance. Yes, I know, again against many advices out there, but trust me, just try and let me know how it verifies against measurements, vs your current setup. I'm sure you will be surprised.

cu_physics = 3, 3, 3,
or at least
cu_physics = 3, 3, 0,

Best luck with experiments!