.. vim: syntax=rst .. include:: meta.rest 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: .. figure:: media/physics-inputs.png :align: center :figwidth: 90% **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 :ref:`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 :ref:`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 :file:`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 (:file:`geo_em.d0{x}.nc`) netCDF file. This file is generated by the :program:`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 :file:`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 :file:`wrfinput_d0x.nc` file. This netCDF file can be generated one of two ways, through the :program:`real.exe` program within WRF or via an R script (:file:`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 :file:`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 :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 :ref:`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 :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. :file:`Fulldom_hires.nc`, :file:`hydro2dtbl.nc`) and channel routing files (e.g. :file:`Route_Link.nc`) can be created (see Appendices :ref:`A7 `, :ref:`A10 `, and :ref:`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. :file:`*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 :ref:`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. :file:`GEOGRID_LDASOUT_Spatial_Metadata.nc`) for the land surface model grid (as defined by the geogrid file :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 :ref:`Section 3 ` and in :ref:`Table 5.1 `. .. table:: **Table 5.1** Input and parameter files for hydro components of WRF-Hydro. :width: 90% :align: center :name: table-5.1 +---------------------------+---------------------+----------------------------------+--------------+ | **Filename** | **Description** | **Source** | **Required** | +===========================+=====================+==================================+==============+ | :file:`Fulldom_hires.nc` | High resolution | WRF-Hydro GIS | Yes | | | full domain file. | pre-processing | | | | Includes all fields | toolkit | | | | specified on the | | | | | routing grid. | | | +---------------------------+---------------------+----------------------------------+--------------+ | :file:`Route_Link.nc` | Channel reach | WRF-Hydro GIS | When reach | | | parameters (ComID, | pre-processing | based | | | gage ID, bottom | toolkit | routing is | | | width, slope, | | used | | | roughness, order, | | (including | | | etc.) | | user defined | | | | | mapping) | +---------------------------+---------------------+----------------------------------+--------------+ | :file:`GWBASINS.nc` | 2D file defining | WRF-Hydro GIS | When the | | | the locations of | pre-processing | baseflow | | | groundwater basins | toolkit | bucket model | | | on a grid | | is turned on | | | | | and user | | | | | defined | | | | | mapping is | | | | | off | +---------------------------+---------------------+----------------------------------+--------------+ | :file:`GWBUCKPARM.nc` | Groundwater | WRF-Hydro GIS | When the | | | parameter table | pre-processing | baseflow | | | containing bucket | toolkit | bucket model | | | model parameters | | is turned on | | | for each basin | | | +---------------------------+---------------------+----------------------------------+--------------+ | :file:`LAKEPARM.nc` | Lake parameter | WRF-Hydro GIS | When lake | | | table containing | pre-processing | and | | | lake model | toolkit | reservoir | | | parameters for each | | routing is | | | catchment | | turned on | +---------------------------+---------------------+----------------------------------+--------------+ | :file:`hydro2dtbl.nc` | Spatially | :file:`create_SoilProperties.R` | When using | | | distributed netCDF | script | spatially | | | version of | | distributed | | | :file:`HYDRO.TBL` | (will also be automatically | terrain | | | | generated by WRF-Hydro) | routing | | | | | parameters | +---------------------------+---------------------+----------------------------------+--------------+ | :file:`HYDRO.TBL` | Parameter table for | :file:`template/HYDRO` | Yes | | | lateral flow | directory in the | | | | routing within | model code | | | | WRF-Hydro. In the | | | | | :file:`HYDRO.TBL` | | | | | file parameters are | | | | | specified by land | | | | | cover type or soil | | | | | category | | | +---------------------------+---------------------+----------------------------------+--------------+ | :file:`HYDRO_MODIS.TBL` | Version of | :file:`template/HYDRO` | Replacement | | | :file:`HYDRO.TBL` | directory in the | for | | | using MODIS land | model code | |HYDRO.TBL| | | | use categories | | when using | | | rather than USGS. | | MODIS land | | | (Change name to | | use | | | :file:`HYDRO.TBL` | | categories | | | for use.) | | | +---------------------------+---------------------+----------------------------------+--------------+ | :file:`CHANPARM.TBL` | Parameters for | :file:`template/HYDRO` | When gridded | | | gridded channel | directory in the | routing is | | | routing scheme. | model code | used | | | Parameters are | | | | | specified by | | | | | Strahler stream | | | | | order | | | +---------------------------+---------------------+----------------------------------+--------------+ | :file:`spatialweights.nc` | Spatial weight file | distributed with NWM domain | When using | | | used to map fluxes | files | user defined | | | to catchment | | mapping | | | objects | | | +---------------------------+---------------------+----------------------------------+--------------+ .. |HYDRO.TBL| replace:: :file:`HYDRO.TBL` .. _section-5.3: 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 :ref:`Table 5.2 `. The first of these is the general parameter table or :file:`GENPARM.TBL`. This file contains a number of global parameters for the Noah land surface model. The next is the vegetation parameter table or :file:`VEGPARM.TBL`. This file contains parameters that are a function of land cover type. The final table is the soil parameter table or :file:`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 :ref:`A8 `. .. table:: **Table 5.2** Parameter tables for the Noah land surface model. These parameter tables can be found within the land surface model source code :file:`Run/` directory and will be copied over the the WRF-Hydro Run directory when the compile script for this LSM is run. :align: center :width: 90% :name: table-5.2 .. default-role:: file +---------------+-------------------------------------------+----------------+ | **Filename** | **Description** | **Required** | +===============+===========================================+================+ | GENPARM.TBL | Miscellaneous model parameters that are | Yes | | | applied globally | | +---------------+-------------------------------------------+----------------+ | VEGPARM.TBL | Vegetation parameters indexed by land use | Yes | | | / land cover categories | | +---------------+-------------------------------------------+----------------+ | SOILPARM.TBL | Soil parameters indexed by soil texture | Yes | | | classes | | +---------------+-------------------------------------------+----------------+ .. default-role:: The Noah-MP land surface model also requires three parameter table files, outlined in :ref:`Table 5.3 `. The first of these is the general parameter table or :file:`GENPARM.TBL`. This file contains a number of global parameters for the Noah-MP land surface model. The next table is the :file:`MPTABLE.TBL`. This file contains parameters that are a function of land cover type. The last one is the soil parameter table or :file:`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 :ref:`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 :file:`soil_properties.nc`. A list of the variables contained in this file is included in Appendix :ref:`A9 `. .. table:: **Table 5.3** Parameter tables for the Noah-MP land surface model. These parameter tables can be found within the land surface model source code Run directory and will be copied over to the WRF-Hydro Run directory when the compile script for this LSM is run. :name: table-5.3 :align: center :width: 90% .. default-role:: file +----------------------+---------------------------------------------+----------------+ | **Filename** | **Description** | **Required** | +======================+=============================================+================+ | `GENPARM.TBL` | Miscellaneous model parameters that are | Yes | | | applied globally | | +----------------------+---------------------------------------------+----------------+ | `MPTABLE.TBL` | Vegetation parameters indexed by land use / | Yes | | | land cover categories | | +----------------------+---------------------------------------------+----------------+ | `SOILPARM.TBL` | Soil parameters indexed by soil texture | Yes | | | classes | | +----------------------+---------------------------------------------+----------------+ | `soil_properties.nc` | NetCDF file with spatially distributed land | No | | | 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 | | | | :file:`create_SoilProperties.R` script | | +----------------------+---------------------------------------------+----------------+ .. default-role:: file Parameters for the lateral routing component of WRF-Hydro are specified in a similar way via the :file:`HYDRO.TBL` file or the :file:`hydro2dtbl.nc` file. This file is also distributed with the WRF-Hydro source code in the :file:`templates/HYDRO` directory and is copied over to the :file:`Run` directory upon building the model. There is also an additional :file:`HYDRO_MODIS.TBL` file for those using the MODIS land cover classification scheme. The :file:`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., :file:`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 :file:`HYDRO.TBL`. The second part of the :file:`HYDRO.TBL` parameter table contains several soil hydraulic parameters that are classified as functions of soil type. These soil parameters are copied from the :file:`SOILPARM.TBL` parameter table from the Noah land surface model. They are provided in :file:`HYDRO.TBL` to allow the user to modify those parameters as needed during model calibration activities without modifying the :file:`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 :file:`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 :file:`HYDRO.TBL`. The file :file:`hydro2dtbl.nc` is a spatially distributed netCDF file version of the :file:`HYDRO.TBL` parameter table. This netCDF file can be created via the :file:`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 :file:`HYDRO.TBL` if the filename specified in the :file:`hydro.namelist` does not already exist. See Appendix :ref:`A10 ` for further explanation of the variables in the :file:`HYDRO.TBL` and :file:`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 :file:`soil_properties.nc` and :file:`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 (:file:`create_SoilProperties.R`) and are described in more detail in Appendices :ref:`A9 ` and :ref:`A10 `. In order for the model to read in the :file:`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. .. _section-5.4: 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 :file:`CHANPARM.TBL`. If the model is configured using reach-based routing (including the NWM configuration) the parameters and channel geometry are specified within the :file:`Route_Link.nc` file generated by the *WRF-Hydro GIS Pre-processing Toolkit*. Variables of the :file:`CHANPARM.TBL` and :file:`Route_Link.nc` files are described in Appendix :ref:`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 :file:`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. .. _section-5.5: 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 :file:`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 :file:`GWBASINS.nc` netCDF file. The contents of these files are described in Appendix :ref:`A12 `. Groundwater bucket model parameters are assigned via the :file:`GWBUCKPARM.nc` file for all configurations. The contents of these files are also summarized in Appendix :ref:`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. .. _section-5.6: 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 :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 :ref:`A14 ` for descriptions of the variables within the :file:`LAKEPARM.nc` file. .. _section-5.7: 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 :ref:`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. .. table:: **Table 5.4** Input forcing data for the Noah and Noah-MP land surface models :width: 90% :align: center :name: table-5.4 +-----------------+------------------------------------+---------------+ | **Variable | **Description** | **Units** | | name** | | | +=================+====================================+===============+ | ``SWDOWN`` | Incoming shortwave radiation | `W/m^2` | +-----------------+------------------------------------+---------------+ | ``LWDOWN`` | Incoming longwave radiation | `W/m^2` | +-----------------+------------------------------------+---------------+ | ``Q2D`` | Specific humidity | `kg/kg` | +-----------------+------------------------------------+---------------+ | ``T2D`` | Air temperature | `K` | +-----------------+------------------------------------+---------------+ | ``PSFC`` | Surface pressure | `Pa` | +-----------------+------------------------------------+---------------+ | ``U2D`` | Near surface wind in the | `m/s` | | | `u`-component | | +-----------------+------------------------------------+---------------+ | ``V2D`` | Near surface wind in the | `m/s` | | | `v`-component | | +-----------------+------------------------------------+---------------+ | ``RAINRATE`` | Precipitation rate | `mm/s` *or* | | | | `kg/m^2` | +-----------------+------------------------------------+---------------+ | ``LQFRAC`` | Precipitation type | `unitless` | | (optional) | i.e., liquid water fraction (0-1) | | +-----------------+------------------------------------+---------------+ 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 :ref:`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 :file:`namelist.hrldas` by modifying the ``FORC_TYP`` namelist option. Model forcing type namelist options are specified and described as follows, See Appendices :ref:`A4 ` and :ref:`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 .. rubric:: 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 :ref:`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 :file:`geo_em.d0{x}.nc` “geogrid” file. Filenames must conform to the following convention: :file:`YYYYMMDDHH.LDASIN_DOMAIN{X}` .. rubric:: 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 :file:`namelist.hrldas` file). In this format, gridded forcing data for all meteorological forcing variables with the names and units shown in :ref:`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 :file:`geo_em.d0{x}.nc` file. Filenames must conform to the following convention: :file:`YYYYMMDDHHmm.LDASIN_DOMAIN{X}` .. rubric:: 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 :file:`wrfout_d0{x}_YYYY-MM-DD_HH:MM:SS`. .. rubric:: 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 :ref:`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 :file:`namelist.hrldas` file. .. table:: **Table 5.5.** Description of idealized forcing :align: center :width: 90% :name: table-5.5 +--------------+--------------------------+------------------------------+ | **Variable | **Prescribed value or | **Timing** | | name** | range of values** | | +==============+==========================+==============================+ | ``SWDOWN`` | 0 - 900 [`W/m^2`] | Diurnal cycle | +--------------+--------------------------+------------------------------+ | ``LWDOWN`` | 375 - 425 | Diurnal cycle | | | [`W/m^2`] | | +--------------+--------------------------+------------------------------+ | ``Q2D`` | 0.01 [`kg/kg`] | Constant | +--------------+--------------------------+------------------------------+ | ``T2D`` | 287 - 293 [`K`] | Diurnal cycle | +--------------+--------------------------+------------------------------+ | ``PSFC`` | 100,000 [`Pa`] | Constant | +--------------+--------------------------+------------------------------+ | ``U2D`` | 1.0 [`m/s`] | Constant | +--------------+--------------------------+------------------------------+ | ``V2D`` | 1.0 [`m/s`] | Constant | +--------------+--------------------------+------------------------------+ | ``RAINRATE`` | 25.4 [`mm/s` or | For first hourly time step | | | `kg/m^2`] | and zero thereafter | +--------------+--------------------------+------------------------------+ .. rubric:: 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 :file:`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: :file:`{YYYYMMDDHHMM}.PRECIP_FORCING.nc`. .. rubric:: 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 :file:`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: :file:`{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 :file:`namelist.hrldas` file. For example, the user can have 'hourly' meteorology with '5-minute' precipitation analyses. .. rubric:: 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 :file:`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: :file:`{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 :file:`namelist.hrldas` file. For example, the user can have 'hourly' meteorology with '5-minute' precipitation analyses.