5. Model inputs and preprocessing
This chapter describes WRF-Hydro input and parameter file requirements and the preprocessing tools used to generate them.
5.1 Overview of model inputs
Figure 5.1 WRF-Hydro input and parameter files organized by model physics component. See the Key for files specific to a certain land model or channel configuration.
WRF-Hydro requires a number of input files describing the model domain, parameters, initial conditions, and when run in a standalone configuration meteorological forcing files. A full list of these files broken up by model physics component is shown in Figure 5.1. Note that the set of files required to run WRF-Hydro varies depending upon model configuration. For example, different land surface models and model physics components may require different parameter and input files.
While some parameter files and templates are included with the model source code, most must be generated by the user. We provide a number of scripts and preprocessing utilities on the WRF-Hydro website (https://ral.ucar.edu/projects/wrf_hydro/pre-processing-tools) in order to aid in this process. These include NCAR Command Language (NCL) scripts to regrid forcing data from commonly used data sources, R scripts to generate parameter and model initialization files, and a set of Python based ArcGIS pre-processing tools. The specific utilities used to generate different files are listed in Table 5.1. Users should be aware that these tools do not support all potential datasets and use cases and that the use of default parameters will often result in suboptimal model performance. More details regarding the pre-processing utilities, file requirements, and descriptions follow.
In addition to the ArcGIS pre-processing tools, the WRF-Hydro group has also developed a set of open-source, Python-based preprocessing tools. These tools replicate existing capabilities and operate within the same software environments as WRF-Hydro. Built with Python 3 and libraries such as Whitebox Tools, NumPy, and GDAL, users can configure their environments using Anaconda, Miniconda, or custom setups. This initiative responds to user demand for an open-source option, ensuring portability and multi-platform support while offering efficient, parallelized geoprocessing. All underlying libraries are open-source, eliminating proprietary licensing restrictions. For more information, please visit: https://ral.ucar.edu/dataset/open-source-wrf-hydro-gis-pre-processing-tools-beta.
5.2 Domain processing and description of surface physiographic input files
This subsection describes the process of defining the WRF-Hydro model domain, generating model initial conditions, and deriving geospatial input and parameter files via the WRF-Hydro GIS pre-processing tools. As noted in the previous section a number of scripts and utilities have been developed to facilitate the creation of these files. Additionally, we rely on a utility within the Weather Research and Forecasting (WRF) model preprocessing system (WPS) called GEOGRID to define the land surface model grid and relevant geospatial data and produce the resulting geo_em.d0{x}.nc file hereafter referred to as a “geogrid” file. This geogrid file is then used as input to the ArcGIS preprocessing tools, along with external datasets such as high resolution topographic data, which generate the high resolution routing grid and all surface physiographic input data files required by the model. The geogrid file is also passed to utilities in order to generate land surface model initial condition files.
5.2.1 Defining the model domain
The data required to define the domain and geospatial attributes of a spatially-distributed, or gridded, 1-dimensional (vertical) land surface model (LSM) are specified in a geogrid (geo_em.d0{x}.nc) netCDF file. This file is generated by the GEOGRID utility in the WRF preprocessing system (WPS). WPS is a preprocessing system that prepares both land surface and atmospheric data for use in the model. The GEOGRID component of WPS automates the procedure of defining in space, georeferencing and attributing most of the land surface parameter data required to execute both the Noah and Noah-MP land surface models. GEOGRID interpolates land surface terrain, soils and vegetation data from standard, readily available data products. These data are distributed as a geographical input data package via the WRF website. Complete documentation and user instructions for use of the WPS system are provided online by NCAR and are updated regularly and, thus, are not discussed in great detail here. This geo_em.d0{x}.nc file is also required as input to other WRF-Hydro preprocessing utilities.
5.2.2 Initial land surface conditions
Initial conditions for the land surface, such as soil moisture, soil temperature, and snow states, are prescribed via the wrfinput_d0x.nc file. This netCDF file can be generated one of two ways, through the real.exe program within WRF or via an R script (create_wrfinput.R) distributed on the WRF-Hydro website. When created using the real.exe program in WRF, initial conditions are pulled from existing reanalysis or realtime products (see WRF documentation for data and system requirements). This will typically result in more realistic initial model states. However, the process is somewhat involved and requires the user to obtain additional external datasets.
The R script will create a simplified version of the wrfinput_d0x.nc file including all necessary fields for the Noah-MP land surface model, but with spatially uniform initial conditions that are prescribed within the script and requires only the geogrid file geo_em.d0{x}.nc as input. Step-wise instructions and detailed requirements are included in the documentation distributed with the script. Users should be aware that the model will likely require additional spin-up time when initialized from this file.
5.2.3 Generating hydrologic routing input files via the WRF-Hydro GIS pre-processing tools
A suite of Python based utilities, the WRF-Hydro GIS Pre-processing Toolkit, have been developed to facilitate the process of deriving WRF-Hydro input and parameter files from commonly available geospatial data products, such as hydrologically processed digital elevation models. A large number of the hydro input and parameter files described in Table 5.1 can be generated by these tools as well as a geospatial metadata file to support georeferencing of WRF-Hydro model output files and relevant shapefiles to aid in visualizing the model components. The WRF-Hydro GIS pre-processing tools are developed to function as an additional ArcToolbox within the Esri ArcGIS software. Specific operating system and software requirements are addressed in the full WRF-Hydro GIS Pre-processing Toolkit documentation.
The minimum input data requirements for the pre-processing tools are the geogrid file geo_em.d0x.nc and a hydrologically conditioned digital elevation model covering the full extent of the domain of interest. From these datasets the terrain routing files (e.g. Fulldom_hires.nc, hydro2dtbl.nc) and channel routing files (e.g. Route_Link.nc) can be created (see Appendices A7, A10, and A11).
A .txt or .csv file with stream gage locations can optionally
be supplied, allowing the user to demarcate these locations in the model input files
and optionally produce time series outputs (e.g. *CHANOBS_DOMAIN{x}) for only these locations.
This text file denoting the location of stream gages or “forecast points”
can also be used to generate groundwater input files. Effectively
groundwater basins are delineated above each of these locations and
default parameters will be assigned to a parameter file that can also be
generated using this tool. More details are available in the WRF-Hydro GIS Pre-processing Toolkit documentation.
Lake and reservoir component input files also require a supplementary input file. A shapefile containing polygons defining the extent of each lake must be provided as input. From this file and the processed digital elevation model a number of parameters are derived for each lake (however, note that other parameters are only assigned a global default value). More details about this process and the contents of the input and parameter files can be found in Appendix A14 and the full WRF-Hydro GIS Pre-processing Toolkit documentation.
The WRF-Hydro GIS Pre-processing Toolkit will also produce a geospatial metadata file (e.g. GEOGRID_LDASOUT_Spatial_Metadata.nc) for the land surface model grid (as defined by the geogrid file geo_em.d0{x}.nc). This file contains projection and coordinate information for the land surface model grid. While this file is an optional input to WRF-Hydro, in combination with the new file output routines in version 5.0 of WRF-Hydro this file will allow for the creation of CF (Climate and Forecast metadata convention) compliant output files. This allows for files to be more easily viewed in GIS systems (e.g. ArcGIS and QGIS) as well as other visualization software. Additional documentation for this toolkit including step by step instructions and detailed requirements is provided on the WRF-Hydro website.
Requirements for the hydro components of the model (i.e. those not directly associated with the land surface model or data assimilation) are described in the model physics Section 3 and in Table 5.1.
Filename |
Description |
Source |
Required |
|---|---|---|---|
Fulldom_hires.nc |
High resolution full domain file. Includes all fields specified on the routing grid. |
WRF-Hydro GIS pre-processing toolkit |
Yes |
Route_Link.nc |
Channel reach parameters (ComID, gage ID, bottom width, slope, roughness, order, etc.) |
WRF-Hydro GIS pre-processing toolkit |
When reach based routing is used (including user defined mapping) |
GWBASINS.nc |
2D file defining the locations of groundwater basins on a grid |
WRF-Hydro GIS pre-processing toolkit |
When the baseflow bucket model is turned on and user defined mapping is off |
GWBUCKPARM.nc |
Groundwater parameter table containing bucket model parameters for each basin |
WRF-Hydro GIS pre-processing toolkit |
When the baseflow bucket model is turned on |
LAKEPARM.nc |
Lake parameter table containing lake model parameters for each catchment |
WRF-Hydro GIS pre-processing toolkit |
When lake and reservoir routing is turned on |
hydro2dtbl.nc |
Spatially distributed netCDF version of HYDRO.TBL |
create_SoilProperties.R script (will also be automatically generated by WRF-Hydro) |
When using spatially distributed terrain routing parameters |
HYDRO.TBL |
Parameter table for lateral flow routing within WRF-Hydro. In the HYDRO.TBL file parameters are specified by land cover type or soil category |
template/HYDRO directory in the model code |
Yes |
HYDRO_MODIS.TBL |
Version of HYDRO.TBL using MODIS land use categories rather than USGS. (Change name to HYDRO.TBL for use.) |
template/HYDRO directory in the model code |
Replacement for HYDRO.TBL when using MODIS land use categories |
CHANPARM.TBL |
Parameters for gridded channel routing scheme. Parameters are specified by Strahler stream order |
template/HYDRO directory in the model code |
When gridded routing is used |
spatialweights.nc |
Spatial weight file used to map fluxes to catchment objects |
distributed with NWM domain files |
When using user defined mapping |
5.3 Description of land surface model and lateral routing parameter files
Parameters for the Noah and Noah-MP land surface models as well as for
the lateral routing component are specified via a collection of text
files (i.e. parameter tables) denoted by the file suffix .TBL.
Default parameter tables for the Noah and Noah-MP models are included in
the WRF-Hydro source code within the directory structure for their
respective land model and the appropriate files are automatically moved
to the Run directory upon building the model.
The Noah land surface model requires three parameter table files, outlined in Table 5.2. The first of these is the general parameter table or GENPARM.TBL. This file contains a number of global parameters for the Noah land surface model. The next is the vegetation parameter table or VEGPARM.TBL. This file contains parameters that are a function of land cover type. The final table is the soil parameter table or SOILPARM.TBL. This parameter table contains parameters that are assigned based upon the soil classification. The variables contained within these files are described in the Appendix A8.
Filename |
Description |
Required |
|---|---|---|
GENPARM.TBL |
Miscellaneous model parameters that are applied globally |
Yes |
VEGPARM.TBL |
Vegetation parameters indexed by land use / land cover categories |
Yes |
SOILPARM.TBL |
Soil parameters indexed by soil texture classes |
Yes |
The Noah-MP land surface model also requires three parameter table files, outlined in Table 5.3. The first of these is the general parameter table or GENPARM.TBL. This file contains a number of global parameters for the Noah-MP land surface model. The next table is the MPTABLE.TBL. This file contains parameters that are a function of land cover type. The last one is the soil parameter table or SOILPARM.TBL. This parameter table contains parameters that are assigned based upon the soil classification. The variables contained within these files are described in Appendix A9.
As part of work conducted for the National Water Model implementation,
the ability to specify a number of these land surface model parameters
spatially on a two or three dimensional grid was introduced. This is
done through the use of the compile time option SPATIAL_SOIL and the
specification of a netCDF format parameter file with the default
filename soil_properties.nc. A list of the variables contained in
this file is included in Appendix A9.
Filename |
Description |
Required |
|---|---|---|
GENPARM.TBL |
Miscellaneous model parameters that are applied globally |
Yes |
MPTABLE.TBL |
Vegetation parameters indexed by land use / land cover categories |
Yes |
SOILPARM.TBL |
Soil parameters indexed by soil texture classes |
Yes |
soil_properties.nc |
NetCDF file with spatially distributed land surface model parameters used when WRF-Hydro is compiled with SPATIAL_SOIL=1. This allows the user to specify parameters on the model grid rather than as a single value or function of soil or land cover type. This file is created by the create_SoilProperties.R script |
No |
Parameters for the lateral routing component of WRF-Hydro are specified in a similar way via the HYDRO.TBL file or the hydro2dtbl.nc file. This file is also distributed with the WRF-Hydro source code in the templates/HYDRO directory and is copied over to the Run directory upon building the model. There is also an additional HYDRO_MODIS.TBL file for those using the MODIS land cover classification scheme.
The HYDRO.TBL parameter table file contains 2 parts. The first part
contains the Manning’s roughness coefficients for overland flow as a
function of the USGS vegetation types as that data is used in the Noah
land surface model. The roughness values are strictly indexed to the
USGS vegetation classes so that if one wanted to use a different
vegetation index dataset (e.g. the MODIS/IGBP option in the Noah land
surface model) a user would need to remap these roughness values to
those new vegetation indices. Users can alter the values of overland
flow roughness here for a given vegetation type. However, users may also
‘scale’ these initial values of roughness by changing the gridded values
of the overland flow roughness scaling factor (OVROUGHRTFAC) that are
contained within the high resolution routing data netCDF file (e.g., Fulldom_hires{x}.nc).
Because hydrological models are often calibrated over a particular region or
watershed as opposed to a specific vegetation type it is recommended
that users modify the OVROUGHRTFAC scaling factor as opposed to altering
the roughness values in HYDRO.TBL.
The second part of the HYDRO.TBL parameter table contains several soil hydraulic parameters that are classified as functions of soil type. These soil parameters are copied from the SOILPARM.TBL parameter table from the Noah land surface model. They are provided in HYDRO.TBL to allow the user to modify those parameters as needed during model calibration activities without modifying the SOILPARM.TBL file and thus is just done for convenience. In effect, when routing options in WRF-Hydro are activated the code will read the soil hydraulic parameters from HYDRO.TBL. If the Noah land surface model is executed within WRF-Hydro without any of the routing options activated, the code will simply use the parameter values specified in HYDRO.TBL.
The file hydro2dtbl.nc is a spatially distributed netCDF file version of the HYDRO.TBL parameter table. This netCDF file can be created via the create_SoilProperties.R script distributed on the WRF-Hydro website (https://ral.ucar.edu/projects/wrf_hydro) or will automatically be generated by the model from the HYDRO.TBL if the filename specified in the hydro.namelist does not already exist. See Appendix A10 for further explanation of the variables in the HYDRO.TBL and hydro2dtbl.nc files.
5.3.1 Spatially distributed parameter files
As of version 5.0 of WRF-Hydro we now allow for the specification of a
number of spatially distributed land surface model and / or lateral
routing parameters in netCDF input files soil_properties.nc and
hydro2dtbl.nc. This option was implemented as part of work conducted
for the National Water Model and allows the user to specify parameters on
the model grid rather than as a single value or function of soil or land
cover type. The files can be generated via an R script provided on our
website (create_SoilProperties.R) and are described in more detail in
Appendices A9 and A10. In order for the
model to read in the soil_properties.nc file the SPATIAL_SOIL environment
variable must be set to 1 at compile time. This option gives users more
flexibility in the specification of land surface model parameters and is
particularly useful in the context of calibration and parameter
regionalization.
5.4 Description of channel routing parameter files
Channel parameters for WRF-Hydro are specified in one of two files. If the model is configured using gridded channel routing these parameters will be stored in CHANPARM.TBL. If the model is configured using reach-based routing (including the NWM configuration) the parameters and channel geometry are specified within the Route_Link.nc file generated by the WRF-Hydro GIS Pre-processing Toolkit. Variables of the CHANPARM.TBL and Route_Link.nc files are described in Appendix A11.
It is important to keep in mind that there is large uncertainty
associated with these parameters. Therefore, model calibration is almost
always warranted. Also, because fully-distributed estimates of flow
depth (HLINK in CHANPARM.TBL) are not available for model initialization,
it is almost always necessary to use a small initial value of HLINK and let the model
come to its own equilibrium (i.e. “spin-up”) after several hours of
integration. The necessary time required to spin up the channel network
is a direct function of how dense and long your channel network is.
Larger, more dense networks will take substantially longer to spin up.
Estimates of total travel time from the furthest channel element to the
basin outline are a reasonable initial approximation of the time it will
take to spin up the channel elements.
5.5 Description of groundwater input and parameter files
Depending upon the choice of channel configuration, groundwater input and parameter files are specified in slightly different ways. For the National Water Model (NWM) implementation of the model - where user defined mapping is active - the spatialweights.nc file is used to map gridded fluxes to the appropriate catchments, the spatial unit of the NWM groundwater bucket model. In other configurations of the model where user defined mapping is not used, grid-based groundwater basins are defined in a GWBASINS.nc netCDF file. The contents of these files are described in Appendix A12.
Groundwater bucket model parameters are assigned via the GWBUCKPARM.nc file for all configurations. The contents of these files are also summarized in Appendix A12 and like the groundwater basins files these files are produced by the WRF-Hydro GIS Pre-processing Toolkit. Note that global default parameters are prescribed when these files are generated so user adjustments and/or calibration are recommended.
5.6 Description of lake and reservoir parameter tables
Lake parameter values are specified for each one of the lake objects.
Typically, baseline parameters are derived within the high-resolution
terrain preprocessing stages described above using tools such as ArcGIS
(e.g. LkArea, LkMxE in the file LAKEPARM.nc).
Values for the weir and orifice coefficients and
sizes can be drawn from standard engineering hydraulics textbooks (e.g.
Chow et al., 1957) and calibrated based on lake level performance. Weir
parameters are specified for reservoir “overflow” or “spill” and orifice
parameters are specified for design operations. The behavior of the
reservoir to store and release water is highly dependent on these
parameters and therefore it is highly recommended that the user modify
this file with their own set of parameters beyond the default given in
the WRF-Hydro GIS Pre-processing Toolkit. See Appendix
A14 for descriptions of the variables within the
LAKEPARM.nc file.
5.7 Specification of meteorological forcing data
Modern land surface hydrology models, including WRF-Hydro, require meteorological forcing data to simulate land-atmosphere exchanges and terrestrial hydrologic processes when uncoupled to atmospheric modeling systems. Most land models require a similar set of input variables with some variation in terms of the units, spectral bandwidths of radiation, handling of precipitation phase, etc. Most commonly these variables include: incoming short and longwave radiation, humidity, temperature, pressure, wind speed and precipitation rate and type. The required variables for the Noah and Noah-MP land surface models supported in version 5.x of WRF-Hydro are listed in Table 5.4. These variables’ names, units, and several of the forcing data file format options described below are borrowed from the High-Resolution Land Data Assimilation System (HRLDAS), an offline driver for Noah land surface models. When WRF-Hydro is coupled into other modeling architectures such as the NASA Land Information System (LIS), these systems will set the requirements for the forcing data.
Variable name |
Description |
Units |
|---|---|---|
|
Incoming shortwave radiation |
W/m^2 |
|
Incoming longwave radiation |
W/m^2 |
|
Specific humidity |
kg/kg |
|
Air temperature |
K |
|
Surface pressure |
Pa |
|
Near surface wind in the u-component |
m/s |
|
Near surface wind in the v-component |
m/s |
|
Precipitation rate |
mm/s or kg/m^2 |
|
Precipitation type i.e., liquid water fraction (0-1) |
unitless |
Here we simply describe the requirements and options that are available in the standalone version of WRF-Hydro. Presently, there are 9 forcing data input types in WRF-Hydro. Because it is untenable to support a large variety of input file formats and data types within the model, WRF-Hydro requires that most processing of forcing data be handled external to the model (i.e. as a “pre-process”) and that users put their forcing data into one of the required formats. This includes performing tasks like, gridding of station observations, making sure forcing data is gridded to match the domain grid and has the correct variable names and units (see Table 5.4), reformatting data into the prescribed netCDF format, etc. Note that The WRF-Hydro code will not remap or spatially-subset the forcing data in any way. To facilitate these pre-processing activities we have developed WRF-Hydro Forcing Engine and numerous scripts which can be executed to help in the forcing data preparation process. These scripts along with sample data files are distributed on the WRF-Hydro website.
The input forcing data type is specified in the land surface model
namelist file namelist.hrldas by modifying the FORC_TYP namelist
option. Model forcing type namelist options are specified and described as follows,
See Appendices A4 and A5
for more details.
:
# 1 = HRLDAS-hr format # 2 = HRLDAS-min format # 3 = WRF output # 4 = Idealized # 5 = Idealized with specified precipitation # 6 = HRLDAS-hr format with specified precipitation # 7 = WRF output with specified precipitation FORC_TYP = 1
1 - HRLDAS hourly format input files:
This option requires meteorological forcing data to be provided in the HRLDAS hourly forcing data format. Scripts provided on the WRF-Hydro website will generate files in this format. Forcing files in this format can also be found in the example cases. In this format, gridded forcing data for all meteorological forcing variables with the names and units shown in Table 5.4 are included in a single netCDF file for each time step. The forcing data grids must match the model grid specified in the geo_em.d0{x}.nc “geogrid” file. Filenames must conform to the following convention: YYYYMMDDHH.LDASIN_DOMAIN{X}
2 - HRLDAS minute format input files:
This option requires meteorological forcing data to be provided in the HRLDAS minute forcing data format. Like the HRLDAS hourly format, this standard is borrowed from the HRLDAS modeling system. However, this format allows for the specification of forcing data at more frequent time intervals (up to every minute as specified by the forcing time step in the namelist.hrldas file). In this format, gridded forcing data for all meteorological forcing variables with the names and units shown in Table 5.4 are included in a single netCDF file for each time step. The forcing data grids must match the model grid specified in the geo_em.d0{x}.nc file. Filenames must conform to the following convention: YYYYMMDDHHmm.LDASIN_DOMAIN{X}
3 - WRF output files as input to WRF-Hydro:
This option allows for meteorological forcing data to be read directly from a WRF model output file “wrfout” file so long as the WRF model grid is the same as that for WRF-Hydro. The WRF-Hydro code will not remap or spatially-subset the data in any way. All necessary fields are available in a default WRF output file but users should verify their existence if modifications have been made. These files must be written with only a single time step per file and retain the default filenames. The file naming convention for the wrfout file is wrfout_d0{x}_YYYY-MM-DD_HH:MM:SS.
4 - Idealized forcing:
This option requires no input files. Instead a simple rainfall event is
prescribed (i.e. “hardcoded”) in the model. This event is a spatially uniform
25.4 mm/hr (1 in/hr) for 1 hour duration over the first hour of the model
simulation. The remainder of the forcing variables are set to have either
constant values (in space and time) or, in the case of temperature and
radiation variables, a fixed diurnal cycle (see Table 5.5).
This option is primarily used for simple testing of the model and is convenient
for checking whether or not components besides the forcing data are properly
being read into the model and working. Future versions of WRF-Hydro will allow
the user to specify values for the precipitation event and the other meteorological
variables. Note that this forcing type requires the user-specified
FORCING_TIMESTEP namelist parameter to be set to 3600 (1 hr) in the
namelist.hrldas file.
Variable name |
Prescribed value or range of values |
Timing |
|---|---|---|
|
0 - 900 [W/m^2] |
Diurnal cycle |
|
375 - 425 [W/m^2] |
Diurnal cycle |
|
0.01 [kg/kg] |
Constant |
|
287 - 293 [K] |
Diurnal cycle |
|
100,000 [Pa] |
Constant |
|
1.0 [m/s] |
Constant |
|
1.0 [m/s] |
Constant |
|
25.4 [mm/s or kg/m^2] |
For first hourly time step and zero thereafter |
5 - Idealized forcing with specified precipitation:
This option is identical to forcing type 4 with the exception that the
WRF-Hydro system will look for user provided supplementary precipitation
files. These supplementary precipitation files are netCDF files containing a
single gridded field with either the name precip and units of mm or
precip_rate with unit a unit of mm/s. When using this forcing type,
the WRF-Hydro system will look for a new precipitation input file based
on the user-specified FORCING_TIMESTEP namelist option set in the
namelist.hrldas file. Scripts provided on the WRF-Hydro website will
generate files in this format (specifically the MRMS regridding
scripts). Forcing files in this format can also be found in the example
test cases. Filenames for supplemental precipitation files must conform
to this convention: {YYYYMMDDHHMM}.PRECIP_FORCING.nc.
6 - HRLDAS hourly format input files with specified precipitation:
This option is identical to forcing type 1 with the exception that the
WRF-Hydro system will also look for user provided supplementary precipitation
files. These supplementary precipitation files are netCDF files containing a
single gridded field with either the name precip and units of mm or
precip_rate with unit a unit of mm/s. When using this forcing type, the
WRF-Hydro system will look for a new precipitation input file based on the
user-specified FORCING_TIMESTEP namelist option set in the
namelist.hrldas file. Scripts provided on the WRF-Hydro website will
generate files in this format (specifically the MRMS regridding scripts).
Forcing files in this format can also be found in the example test cases.
Filenames for supplemental precipitation files must conform to this
convention: {YYYYMMDDHHMM}.PRECIP_FORCING.nc.
This option is useful when combining atmospheric analyses from
reanalysis products or other models with a separate analysis of
precipitation (e.g. a gridded gauge product, radar QPE, nowcasts,
satellite QPE, etc). The model reads in the meteorological forcing data
fields on each hour and then holds those values constant for the entire
hour. Precipitation can be read in more frequently based on the
user-specified FORCING_TIMESTEP namelist parameter in the
namelist.hrldas file. For example, the user can have ‘hourly’
meteorology with ‘5-minute’ precipitation analyses.
7 - WRF output files as input to WRF-Hydro with specified precipitation:
This option is identical to forcing type 3 with the exception that the
WRF-Hydro system will also look for user provided supplementary precipitation
files. These supplementary precipitation files are netCDF files containing a
single gridded field with either the name precip and units of mm or
precip_rate with unit a unit of mm/s. When using this forcing type, the
WRF-Hydro system will look for a new precipitation input file based on the
user-specified FORCING_TIMESTEP namelist option set in the
namelist.hrldas file. Scripts provided on the WRF-Hydro website will
generate files in this format (e.g., MRMS regridding scripts).
Forcing files in this format can also be found in the example test cases.
Filenames for supplemental precipitation files must conform to this
convention: {YYYYMMDDHHMM}.PRECIP_FORCING.nc.
This option is useful when combining forcing data from WRF with a
separate analysis of precipitation (e.g. a gridded gauge product, radar
QPE, nowcasts, satellite QPE, etc). The model reads in the
meteorological forcing data fields from the WRF output file and then
holds those values constant until the next file is available.
Precipitation can be read in more frequently based on the user-specified
FORCING_TIMESTEP namelist parameter in the namelist.hrldas file. For
example, the user can have ‘hourly’ meteorology with ‘5-minute’
precipitation analyses.