NPS : The N MMB P reprocessing S ystem

1. NPS: The NMMB Preprocessing System Matthew Pyle DusanJovic

2. 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.

3. 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.

4. Overview GFS, NAM, … forecast output geogrid (“static” file) (if moving nest) ungrib metgrid nemsinterp NMMB model

5. 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.

6. 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 DusanJovic. • 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

7. 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 files needed for moving nests, it must be written as GRIB2: ncep_proc_grib2 = .true. movable_nests= .true.

8. 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

9. 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_ij_3, SM_ij_9) 9x the overall parent resolution 3x the overall parent resolution

10. 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 • [breaking news] Dusan recently coded an alternate ungrib that is parallelized over forecast time to simultaneously process the GRIB files • Setting spectral=.true. utilizes spectral files for atmospheric fields, and the 0.5 degree GFS GRIB fields for soil/surface information.

11. Components(2) - ungrib • Spectral processing details: • Processing spectral files is more time consuming than GRIB; issue will get worse with future T1534 GFS. • 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.

12. Components(3) - metgrid • Horizontally interpolates the fields provided by ungrib onto the target domain defined by geogrid. • Very similar to the WPS metgrid; largest difference from user perspective may be the file output format • NPS not connected to WRF I/O package • Both geogrid and metgrid currently write a “.dio” binary file

13. Components(4) - nemsinterp • Functionally the same as the WRF-NMM “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 in multiple boco.#### files, where the “####” is number of hours into the forecast at which that file becomes valid (boco.0000, boco.0003, … ).

14. Components(4) – nemsinterp (bonus slide) • 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 (dyvalue from namelist.nps) tph0d: 0.000 (center latitude of uppermost parent domain) tlm0d: 0.000 (center longitude of uppermost parent domain) 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. Also can be computed from: wbd = -(nx-1)/2*dlmd sbd = -(ny-1)/2*dphd

15. Components(4) – nemsinterp (bonus slide) • configure_nest_details_## file has information that can be dropped directly into the model configure file (recall Dusan’s script where he would cat this file to the end of his model configure file my_domain_id: 02 my_parent_id: 01 n_children: 00 i_parent_start: 152 j_parent_start: 64 parent_child_space_ratio: 3 input_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

16. 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, &geogrid parent_id= 0, 1, 2 parent_grid_ratio= 1, 3, 3 As in WPS, these settings define a parent-child-grandchild nesting arrangement (like 27:9:3 km HWRF)

17. 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. 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 Only used by the NAM, leave it .false. If true, will use IGBP rather than USGS landuse categories If true, uses GRIB2 for intermediate files when ncep_processing=.true. Must be true for movable_nests to work properly. Will generate the various *_IJ_3 and *_IJ_9 type surface fields used by the model when running moving nests.

18. Namelist options - nemsinterp &nemsinterp pt= 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. Global run? 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.

19. Namelist options - nemsinterp boundary_flux= .true. lnsh= 5 lnsv= 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. There are three styles of the pressure-sigma hybrid coordinate: 1=vc (default) ; 2=gfs ; 3=sal (Sangster/Arakawa/Lamb) 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.

20. 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 ungribVtable) 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/NCEPDEV PACKDIR=$ZBASE/meso/save/${USER}/NMMB_init WORKDIR=$ZBASE/stmp/${USER}/nmmb_init

21. 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