NPS: The NMMB Preprocessing System

Matthew PyleDusan Jovic

Outline

• Overview

• The four component executables and their functions

– Three of them are in common with WPS: ungrib, geogrid, and metgrid, but have some wrinkles in NPS.

– The one unique to NPS is nemsinterp, which replaces the real_nmm functionality of WRF

• NPS namelist settings – focusing on those that aren’t shared with WPS.

Overview

• NPS is based on the WPS software associated with WRF and fills the same model initialization functionality for NMMB

– Provides the NMMB model with initial and lateral boundary conditions interpolated from a source model (such as GFS).

– Allows for generation of model conditions over limited area domains anywhere on the globe, or initial conditions for global NMMB runs.

geogrid (“static” file)

ungrib metgrid nemsinterp

NMMB model

Overview

(if moving nest)

GFS, NAM, RAP, … forecast output

Components(1) - geogrid

• Defines static information for the target domain(s) (e.g., topography, land mask, vegetation type, ...)

• Only needs to be run once for a given domain.

• In NPS there are two pathways through the geogrid program, controlled by the logical namelist option ncep_processing.

Components(1) - geogrid

– ncep_processing=.false. WPS input static information and interpolation methodologies are utilized.

– ncep_processing=.true. Uses the “gridgen_sfc” package created here by George Gayno (used in several operational modeling systems at NCEP) and folded into NPS by Dusan Jovic.

• ncep_processing=.true. is the default option and is recommended:

– Only option for NMMB moving nests.– Properly generates gravity wave drag fields from the sub-

gridscale topography information

Components(1) - geogrid

• The ncep_processing=.true. option: – uses input static data in a different format than the WPS

static files (single large files rather than a directory of tiled inputs)

– writes intermediate GRIB files within geogrid. To generate the static files needed for moving nests in the model, it must be written as GRIB2:ncep_proc_grib2 = .true.movable_nests = .true.

Components(1) - geogrid

• Some details of the ncep_processing=.true. processing are controlled by a separate namelist (in NMMB_init/NPS/geogrid/testb.nml_input_zeus*)

– has paths to static file inputs

– controls for topography smoothing

* there are separate versions of this file for different machines, and for IGBP and USGS landuse categories

Components(1) - geogrid

• Treatment of nests:

– static nests: Static information generated for the actual nest domain (deviates from WRF-NMM WPS treatment of nesting “levels”)

– moving nests: Produces the static nest information for the starting location of the nest, + static information over the overall parent region at the finer nest resolution. The nest level information is written with a single field per file (e.g., SM_3.nc, SM_9.nc) in netCDF format.

3x the overall parent resolution

9x the overall parent resolution

Components(2) - ungrib

• Brings selected fields out of GRIB and/or GFS spectral files, writes an intermediate binary file for later processing.

• The GRIB processing is nearly identical to that of the WPS– Dusan coded an alternate ungrib that is parallelized over forecast time

to simultaneously process the GRIB files (ungribp.exe executable)

• Setting spectral=.true. utilizes spectral files for atmospheric fields, and the 0.5 degree GFS GRIB fields for soil/surface information.

Components(2) - ungrib

• Spectral processing details:

– Processing spectral files is far more time consuming than GRIB (particularly for current T1534 GFS, spectral transforms take time)

– Spectral processing in ungrib is parallelized in the vertical. Processor counts that divide evenly into the 64 levels of GFS are best (16 works well).

– Utilizes the Vtable.GFS_spectral file with ungrib to process minimal information from the GFS GRIB file, leaving the atmospheric fields to be filled from the spectral file.

– Currently is incompatible with netCDF format for metgrid output files

Components(3) - metgrid

• Horizontally interpolates the fields provided by ungrib onto the target domain defined by geogrid.

• Very similar to the WPS metgrid; one difference from user perspective may be the file output format:

– NPS not connected to the WRF I/O package like WPS

– But NPS now can write output in netCDF or a binary format (dio) from geogrid and metgrid. Choice controlled by a namelist switch.

Components(4) - nemsinterp

• Functionally the same as the WRF “real” program– Vertically interpolates data onto the NMMB model’s

hybrid vertical coordinate

– Generates model input and (if regional) lateral boundary condition files• The model input is written both as a flat binary file, and as a

nemsio-formatted file.

• Boundary information is written to multiple boco.#### files, where the “####” is number of hours into the forecast at which that file becomes valid (boco.0000, boco.0003, … ).

Components(4) – nemsinterp

• Nemsinterp also writes out two text files with information about the domains that are useful for the model configure file:– domain_details_## (## = domain number) places most

needed information about the domain in a single text file

nx: 361 (e_we value from namelist.nps)ny: 181 (e_sn value from namelist.nps)dlmd: 0.120000 (dx value from namelist.nps)dphd: 0.120000 (dy value from namelist.nps)tph0d: 0.000 (center latitude of uppermost parent)tlm0d: 0.000 (center longitude of uppermost parent)

Components(4) – nemsinterp

- domain_details_## (cont.)

wbd: -21.600 (distance in degrees from tlm0d to west boundary)sbd: -10.800 (distance in degrees from tph0d so south boundary)SW lat,lon: -10.800 -21.600 (native grid SW corner point)NE lat,lon: 10.800 21.600 (native grid NE corner point)

** wbd and sbd are the most critical items here, as the model configure file wants that information. These items also can be computed from:

wbd = -(nx-1)/2*dlmdsbd = -(ny-1)/2*dphd

Components(4) – nemsinterp– configure_nest_details_## file has information that can be

dropped directly into the model configure file

my_domain_id: 02my_parent_id: 01n_children: 00

i_parent_start: 152j_parent_start: 64parent_child_space_ratio: 3input_ready: .TRUE.

these three lines produced for all domains, including overall parent

these four additional lines are produced for nested domains, including the critical i_parent_start and j_parent_start values**.

** geogrid also writes these nest starting points to a nest_start_## text file

Namelist options

• Like the WPS namelist, utilizes multiple columns for multiple domains, and uses the same nesting association items:

&share wrf_core = 'NMB', max_dom = 3,

&geogridparent_id = 0, 1, 2parent_grid_ratio = 1, 3, 3

As in WPS, these settings define a parent-child-grandchild nesting arrangement (like 27:9:3 km HWRF)

Namelist options - geogrid

&geogrid also includes new items, some of which we’ve already discussed:ncep_processing = .true.

do_gwd = .true.

just_last = .false.

use_igbp = .true.

ncep_proc_grib2 = .true.

movable_nests = .true.

io_form_geogrid = 2

If true, uses GRIB2 for intermediate files when ncep_processing=.true. Must be true for movable_nests to work properly.

Uses the geogrid option with enhanced capabilities

Adds 14 additional fields related to gravity wave drag (GWD) to the static file coming out of geogrid. Needed for GWD in model

If true, will use IGBP rather than USGS landuse categories

Only used by the NAM, leave it .false.

Will generate the various *_3.nc & *_9.nc type fields used by the model when running moving nests.

=2 is netCDF; =5 is .dio format

Namelist options - nemsinterp

&nemsinterppt = 1000.ptsgm = 30000. nz = 60

direct_temp = .true.

global = .false.

do_clouds = .true.

grib_src = 'GFS'

The model top (pt) and hybrid coordinate interface pressure (ptsgm) in Pa. Number of vertical layers (nz)

If .true., temperature is vertically interpolated like other fields. If false, temperatures are derived from layer thicknesses.

Generate an initial cloud condensate field? Fairly crude – but possibly better than no clouds at the initial call to radiation

Source of GRIB information; GFS and NAM are the main ones that nemsinterp recognizes, and it controls which cloud-related fields are ingested if do_clouds=.true.

Global run?

Namelist options - nemsinterp

boundary_flux = .true.

lnsh = 5lnsv = 5

vcoord = 1

coord_levs =/

If .true. will slightly modify the winds along the boundary after vertical interpolation so the mass flux across the boundary matches that of the source model.

Specifies the number of rows for which boundary information is generated. Specified separately for mass field (lnsh) and wind field (lnsv) variables.

Can specify nz+1 non-dimensional interface values from 0 to 1, or if left blank the code will generate a reasonable set of layers based on the pt,ptsgm, and nz values.

There are three styles of the pressure-sigma hybrid coordinate: 1=vc (default) ; 2=gfs ; 3=sal (Sangster/Arakawa/Lamb)

Setting up and running

• conf / configure / compile build

• build_namelists.scr script in the main NMMB_init directory provides an “easy” path to setting up and running the NPS, particularly on Zeus/WCOSS.– Defines options to populate the proper namelist.nps (and testb.nml) files used

by NPS, and submits job to queue.– Deals with nuances about spectral processing (using proper ungrib Vtable) and

other subtle complications about using certain options.

• On Zeus, run_nps.ll_input_combined_zeus is utilized by build_namelists.scr, and likely will need editing to point at your “NMMB_init” package and desired temporary working directory:

ZBASE=/scratch2/portfolios/NCEPDEVPACKDIR=$ZBASE/meso/save/${USER}/NMMB_initWORKDIR=$ZBASE/stmp/${USER}/nmmb_init

• We couldn’t go too deeply into certain topics due to time constraints, but feel free to send e-mail with NPS-related questions / concerns / complaints:

Matthew.Pyle@noaa.gov