NextGen-Info
Description: This repo serves as the central location for information on the Next Generation Water Resources Modeling Framework (NextGen) and its related tools, software, and datasets.
NextGen Framework
NextGen is a language- and model-agnostic framework that takes a data-centric approach to hydrologic modeling. This enables various models to use the same spatial discretizations, forcing data, hydrofabric, and other standard features. NextGen development supports both operational National Water Model (NMW)improvements for the NOAA-NWS Office of Water Prediction (OWP) as well as a diverse set of applications created by the hydrologic modeling community, particularly the Cooperative Institute for Research to Operations in Hydrology (CIROH).
Like the other OWP products detailed on this page the NextGen codebase is freely available online via GitHub. For those just getting started with the framework, we recommend reading the NextGen Wiki.
Formulations
A NextGen formulation is any single model or combination of models and/or modules running in a basin to simulate that location's hydrology. A formulation may include one more hydrologic models and modules, plus a streamflow routing module, a coastal model, and other supporting routines. The final configuration depends on a given basin's dominant hydrologic processes and the model representations thereof.
It is important to highlight that NextGen is a framework and not a model. It can run a variety of hydrologic models and modules, plus other routines, but it does not perform any water or energy balance computations on its own.
To that end, OWP has prepared a large selection models and modules to run in NextGen, which we detail in the following subsections. We note here that these are a starting point. We encourage the community to develop new models and adapt existing ones for use in the framework. Currently NextGen supports models written in the following languages:
- C
- C++
- Fortran
- Python
NextGen's core functionalities leverage version 2.0 of the Basic Model Interface (BMI), developed by the Community Surface Dynamics Modeling System (CSDMS) at the University of Colorado Boulder. Therefore, each model must have its own complete implementation of BMI to run in the framework.
For more details on BMI, please see the CSDMS Wiki and documentation.
For more information on making a model NextGen compliant with BMI, please see the training materials here and here.
Hydrologic models and modules
The initial selection of hydrologic models and modules includes routines for many hydrologic processes and states, such as: interception of precipitation by vegetation, snow accumulation and melt, evapotranspiration, infiltration-runoff partitioning, overland flow, terrain routing, subsurface lateral flow, groundwater flux, and soil moisture.
The table below indicates the key processes and primary programming language for each of the models and modules OWP has implemented to date. Click on a model's name to go to its source code hosted on GitHub.
| Model | Key processes | Language |
|---|---|---|
| Noah-OWP-Modular | Interception, snow accumulation and melt, evapotranspiration | Fortran |
| Snow-17 | Snow accumulation and melt | Fortran |
| TopoFlow | Snow accumulation and melt, glacier melt | Python |
| PET | Potential evapotranspiration | C |
| CFE | Infiltration-runoff partitioning, soil moisture | C |
| TOPMODEL | Infiltration-runoff partitioning, soil moisture | C |
| LASAM | Infiltration-runoff partitioning, soil moisture | C |
| Sac-SMA | Infiltration-runoff partitioning, soil moisture | Fortran |
| SoilFreezeThaw | Soil temperature | C++ |
| SoilMoistureProfiles | Soil moisture | C++ |
| LSTM | Streamflow (machine learning) | Python |
Streamflow routing
The T-Route routing module converts water flux data (e.g., overland flow, later flow, groundwater flow) from the hydrologic models listed above into streamflow and routes it through the river network. T-Route features different routing options, including Muskingum-Cunge, diffusive wave, and dynamic wave. For more information and the source code, please visit the T-Route repo.
Coastal models
To produce total water level forecasts, OWP is adapting two coastal models to work with NextGen: the Semi-implicit Cross-scale Hydroscience Integrated System Model (SCHISM) and D-Flow Flexible Mesh (FM). The initial development stages for the coastal model BMIs have been completed and their respective GitHub repositories are stored in the following pathways: SCHISM - https://github.com/LynkerIntel/SCHISM_BMI ; DFlowFM - https://github.com/LynkerIntel/DFlowFM_BMI . Once the NextGen framework evaluation is complete with the SCHISM Total Water Level (TWL) capability, the SCHISM BMI repository will be merged with the SCHISM master repository (https://github.com/schism-dev/schism) in the near future. For the DFlowFM model, it's BMI development is an entire seperate branch of the BMI code that is incompatible with the Deltares DFlowFM master branch and that will remain the case until the DFlowFM EC-module is redeveloped entirely for BMI compatibility. For now, the NOAA DFlowFM BMI development is a frozen DFlowFM version for research and development initiatives under the NextGen project in the future with the TWL capability.
Other modules
There are several other modules that complement the formulations running in NextGen.
One is the Simple Logical Tautology Handler (SLoTH), which provides constant values and performs simple calculations outside of the hydrologic models.
Another module in development, jinjaBMI, performs variable transformations that cannot be calculated by unit conversion alone.
Finally, aorc_bmi provides forcing data to several models (e.g., CFE and PET) when running in standalone mode outside of the NextGen framework.
| Module | Key processes | Language |
|---|---|---|
| SLoTH | Constant values, simple calculations | C++ |
| jinjaBMI | Variable transformations | Python |
| aorc_bmi | Forcing data for standalone models | C |
Forcings Engine
The NextGen Forcings Engine is a set of Python utilities that builds NextGen-compatible forcing files from various meteorological reanalysis and forecast datasets that are utilized for NWM operational configurations (https://github.com/NCAR/WrfHydroForcing/tree/main/Config/WCOSS/v3.0). These include:
- AORC: Analysis of Record for Calibration
- GFS: Global Forecast System
- HRRR: High-Resolution Rapid Refresh
- RAP: Rapid Refresh
- CFS: Climate Forecast System
- NAM: North American Mesoscale Forecast System
- WRF-ARW: Weather Research and Foecast Model- Advanced Research
- MRMS: Multi-Radar/Multi-Sensor System
- Stage IV: Quantitative Precipitation Estimates
- NWM: NWM Retrospective Forcing Files
- NBM: National Blended Models
- NDFD: National Digital Forecast Database
- ERA5: ERA5-Interim Reanalysis Dataset
The NextGen Forcings Engine BMI can produce a single netcdf forcing file for a regular grid, catchment scale, or an unstructured mesh or act as a forcings provider BMI under the NextGen framework. The NextGen lumped forcings driver can soley produce NextGen eligble forcing netcdf/csv forcing files for a small range of forcing datasets (AORC, GFS, HRRR, CFS) as supplementary tool for the community using a fast regridding method called ExactExtract if desired. More tools in the Forcing Engine repository include pre-processing domain configurations (hydrofabric geopackages, coastal meshes) into ESMF-compliant netcdf files as well as a suite of Python scripts for downloading forcing datasets off the NOMADs operational server. For further information, please see the Forcings Engine repo.
Geospatial data
Hydrofabric
The hydrofabric is an essential component of every NextGen run. It serves several purposes, such as:
- Delineating the catchment(s) within the simulation domain
- Defining the topology of the catchments and nexuses to enable fast, accurate streamflow routing via T-Route
- Providing important basin attributes and parameter value estimates (e.g., land cover category, soil type, basin slope, etc.) that can populate model configuration files
Pre-generated hydrofabric data are publicly accessible online here.
https://github.com/NOAA-OWP/hydrofabric
HARBOR
Calibration and regionalization
https://github.com/NOAA-OWP/ngen-cal https://github.com/NOAA-OWP/NextGen_Regionalization https://github.com/NOAA-OWP/formulation-selector
Distributed Model on Demand
https://github.com/NOAA-OWP/DMOD
Put a meaningful, short, plain-language description of what this project is trying to accomplish and why it matters. Describe the problem(s) this project solves. Describe how this software can improve the lives of its audience.
Other things to include:
- Technology stack: Indicate the technological nature of the software, including primary programming language(s) and whether the software is intended as standalone or as a module in a framework or other ecosystem.
- Status: Alpha, Beta, 1.1, etc. It's OK to write a sentence, too. The goal is to let interested people know where this project is at. This is also a good place to link to the CHANGELOG.
- Links to production or demo instances
- Describe what sets this apart from related-projects. Linking to another doc or page is OK if this can't be expressed in a sentence or two.
Screenshot: If the software has visual components, place a screenshot after the description; e.g.,
Dependencies
Describe any dependencies that must be installed for this software to work. This includes programming languages, databases or other storage mechanisms, build tools, frameworks, and so forth. If specific versions of other software are required, or known not to work, call that out.
Installation
Detailed instructions on how to install, configure, and get the project running. This should be frequently tested to ensure reliability. Alternatively, link to a separate INSTALL document.
Configuration
If the software is configurable, describe it in detail, either here or in other documentation to which you link.
Usage
Show users how to use the software. Be specific. Use appropriate formatting when showing code snippets.
How to test the software
If the software includes automated tests, detail how to run those tests.
Known issues
Document any known significant shortcomings with the software.
Getting help
Instruct users how to get help with this software; this might include links to an issue tracker, wiki, mailing list, etc.
Example
If you have questions, concerns, bug reports, etc, please file an issue in this repository's Issue Tracker.
Getting involved
This section should detail why people should get involved and describe key areas you are currently focusing on; e.g., trying to get feedback on features, fixing certain bugs, building important pieces, etc.
General instructions on how to contribute should be stated with a link to CONTRIBUTING.
Open source licensing info
Credits and references
- Projects that inspired you
- Related projects
- Books, papers, talks, or other sources that have meaningful impact or influence on this project