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

Unexpected d01 Output in d03-Only Restart Run Despite history_outname Setting

ZHOU Wan

New member
Dear WRF Support Team,
I am running a WRF v4.6 simulation using the restart functionality. My goal is to only output data for domain 3 (d03), and I have set the history_outname option accordingly to:
history_outname = "/data/WRF_Results/wrfout_d03_<date>"
This is intended to restrict output to d03 only. However, during the simulation, I found that some of the output files appear to be from domain 1 (d01) instead, showing a much larger spatial coverage and a coarser resolution (e.g., DX = 9000m), even though the filename still follows the wrfout_d03_... pattern.

I confirmed this by inspecting the spatial domain, resolution, and temperature fields (see attached figure). Some outputs clearly resemble d01 results, even though they are named as d03.

Key Settings from My namelist.input:
&time_control
restart = .true.
restart_interval = 1440
input_from_file = .false., .false., .false.
history_outname = "/data/WRF_Results/wrfout_d03_<date>"
frames_per_outfile = 1, 1, 1
history_interval = 60, 60, 60
/

&domains
max_dom = 3
dx = 9000, 3000, 1000
dy = 9000, 3000, 1000
parent_id = 1, 1, 2
parent_grid_ratio = 1, 3, 3
feedback = 1
/
I am only running real.exe once, and then restarting wrf.exe using previously generated restart files. The wrfrst_d03* files are present and used correctly, and no wrfout_d01 or wrfout_d02 files are supposed to be written.

❓ My Questions Are:​

  1. Why am I getting d01-like outputs (with 9 km resolution) even though I only write d03 outputs via history_outname?
  2. Is there any reason WRF would internally substitute d01 data into a file named for d03, especially in restart mode?
  3. Could the issue be related to input_from_file = .false. or something else in the restart configuration?
I would greatly appreciate any clarification or suggestions for ensuring that only true d03 results are written under the wrfout_d03_* naming scheme.

1743340038046.png
 
Please see my answers below:
Dear WRF Support Team,
I am running a WRF v4.6 simulation using the restart functionality. My goal is to only output data for domain 3 (d03), and I have set the history_outname option accordingly to:

This is intended to restrict output to d03 only. However, during the simulation, I found that some of the output files appear to be from domain 1 (d01) instead, showing a much larger spatial coverage and a coarser resolution (e.g., DX = 9000m), even though the filename still follows the wrfout_d03_... pattern.

I confirmed this by inspecting the spatial domain, resolution, and temperature fields (see attached figure). Some outputs clearly resemble d01 results, even though they are named as d03.

Key Settings from My namelist.input:

I am only running real.exe once, and then restarting wrf.exe using previously generated restart files. The wrfrst_d03* files are present and used correctly, and no wrfout_d01 or wrfout_d02 files are supposed to be written.

❓ My Questions Are:​

  1. Why am I getting d01-like outputs (with 9 km resolution) even though I only write d03 outputs via history_outname?
The option history_outname = "/data/WRF_Results/wrfout_d03_<date>" is not correct.
If you only need wrfout_d03, you can set large values of history_interval for D01 and D02, for example,

history_interval = 6000000, 6000000, 60

  1. Is there any reason WRF would internally substitute d01 data into a file named for d03, especially in restart mode?
WRF has internal rules to generate output names for specific domains. It is better not to mess up it.
  1. Could the issue be related to input_from_file = .false. or something else in the restart configuration?
I would greatly appreciate any clarification or suggestions for ensuring that only true d03 results are written under the wrfout_d03_* naming scheme.

View attachment 17651
 
Top