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

Strange ndown problem

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

Greetings,

I am using WRF4.1.3 to dynamically downscale a GCM. I am using 45-km wrfout files to drive a 9-km simulation using one-way nesting. Ndown is used to generate the wrfbdy and wrfinput files for the 9-km experiment using the 45-km wrfout files.

I have successfully completed the above procedure on dozens of occasions, however this time something strange is happening. Granted, my current grid configuration is different compared to my previous projects. Specifically, the new wrfinput_d02 file that is created contains a zone approximately 10 gridpoints thick where it appears that the terrain height from the d01 grid is being mapped (see attached screen grab of the difference plot). This band is circumnavigating most of but not all of the lateral boundary. Additionally, the old wrfinput_d01 and old wrfinput_d02 files are both created for the same date. However, there are differences in variables such as T2 between the wrfndi_d02 and new wrfinput_d02 files (see attached screen grab). This has never been the case for my previous downscaling ventures that made use of ndown. When initializing on the same date, the T2 map for instance was identical in the met_em*, wrfinput_d01, new wrfinput_d02, and wrfndi_d02 files. The met_em files look as they should. Attached also is my defined grids. In the postscript, I have added potentially useful namelist.input variables and compilation/configuration options.

Any thoughts are appreciated.

Thanks so much,

Interesting namelist.input variables:
&domains
i_parent_start = 1, 46,
j_parent_start = 1, 24,
s_we = 1, 1,
s_sn = 1, 1,
e_we = 110, 256,
e_sn = 95, 261,
smooth_cg_topo = .true.,


&bdy_control
spec_bdy_width = 5,
specified = .true.
&namelist_quilt
nio_tasks_per_group = 0,
nio_groups = 1,
 

Attachments

  • naomi3.pdf
    410.7 KB · Views: 51
  • Screen Shot 2020-04-08 at 1.52.56 PM.png
    Screen Shot 2020-04-08 at 1.52.56 PM.png
    129.6 KB · Views: 1,090
  • Screen Shot 2020-04-08 at 1.54.52 PM.png
    Screen Shot 2020-04-08 at 1.54.52 PM.png
    460.2 KB · Views: 1,090
Hi,
Can you attach the different namelists that you use for this (namelist to run real and d01, namelist to run ndown, and namelist used to run d02) so that I can take a look? Thanks!
 
Thanks for the reply,

See attached namelists for real, wrf, and ndown. Also attached is my namelist.wps file. I have also tried the following since; each yield the same issue:

1. In attempt to reproduce my previous results, which I know to be correct, I get the same issue. I returned my Cheyenne environment back to its state in early January, and the d01 files are numerically identical. The problem still persists in the creation of the new wrfinput_d02 file. I used option 24 in the configuration (SGI MPT - dmpar).

2. Tried 1 but with a serial compilation.

3. Enlarged the parent domain dramatically relative to the inner grid.

Thanks,
-Stefan
 

Attachments

  • namelist.wrf.txt
    5.5 KB · Views: 66
  • namelist.real.txt
    5.5 KB · Views: 56
  • namelist.ndown.txt
    5.5 KB · Views: 68
  • namelist.wps
    1.5 KB · Views: 59
Stefan,
The difference in the topography along the lateral boundaries of d02 is a default behavior for ndown. That modification changes all of the fields that are then involved with the base state: such as pressure and geopotential. The impact of this change on the diagnostic fields (such as T2) are not all that important.

Why we do it:
To reduce the noise along the lateral boundaries of d02 (the output from ndown, the domain to be run in the next model run), there is a realization that the terrain-following coordinate is a problem. There is no vertical interpolation of the d01 data to an intermediate coordinate surface, which is then re-interpolated back to the d02 surfaces. For each k-level on d01, the data is simply horizontally interpolated to that k-th level on d02 (assuming no vertical refinement).

What we do:
We take the topography from d01 and horizontally interpolate that to d02 for the first grouping of rows and columns (for your case, that might be 10 rows and columns). The next set of rows and columns are a weighted, linear combination of the native d02 topography and the coarser d01 topography that is interpolated to the d02 domain. For example, row 10 would be 100% interpolated d01 resolution, which smoothly transitions to row 20, which would be 100% d02 fine-grid resolution topography.

What to notice:
If you diff the topography of the output from ndown (the wrfinput_d02) with the input to ndown (the wrfndi_d02), you should see changes along the lateral boundaries in the topography (and other base state sensitive fields). In areas of complex topo, the changes are dramatic. In areas of relatively smooth topography (elevation is not important, a large-scale gentle slope is not too important, spatial standard deviation is important), the differences are small. In areas where the lateral boundary is over an ocean, the differences will be within round-off of zero.

Does this seem like what you are seeing?
 
This makes perfect sense. Thanks for the reply.

Since for my previous results I had identical wrfinput_d02 and wrfndi_d02 files, I must assume I had some type of copying inconsistency, as these files cannot be identical in the default configuration of ndown.exe. It is definitely speedier to horizontally interpolate rather than interpolate to an intermediate vertical coordinate!

Is this covered in the WRF User's Guide somewhere?

Thanks so much,
-Stefan
 
Stefan,
No, this "feature" is not documented. This smoothing of the lateral boundaries for ndown is similar to what happens with standard nesting within the WRF model.
 
Top