[ { "path": ".github/CODESTYLE.md", "content": "# WRF-Hydro Fortran Conventions Guide\n\n# Fortran standard\nNew code contributions should be written to at least\n[Fortran 2003 standard](https://gcc.gnu.org/wiki/GFortranStandards#Fortran_2003).\n\n# Source Code Formatting\n* Max line length 100 characters. All wrapped code statements shall at least be indented one\n additional level beyond the previous level.\n* Do NOT use tab characters.\n* Indentation: 3 spaces (no tabs) for all control below the subroutine/function level (indenting\n less often saves a lot of space). Tightly nested do loops can be exceptions. Put comments at same\n indentation level as the code which it is commenting.\n\n\n```fortran\nmodule my_module\ninteger :: local_var\n!==================================================================================================\nsubroutine foo\nimplicit none\n!no indent until control units, line breaks between units\n\ndo i=1,2 ! white space in-line not crucial for readability as in long subroutine calls\n count=i\nend do ! i=1,2\n\ndo i=1,2\n do j=i,(i*2)\n count = i + j\n end do ! j=i,(i*2)\nend do ! i=1,2\n\ndo i=1,2\ndo j=i,(i*2) ! control structure is compact, easy to perceive without indentations\n count = i + j\nend do ! j=i,(i*2)\nend do ! i=1,2\n\nend subroutine foo\n\nend module my_module\n```\n\n* Generally use lower case except for where emphasis is needed.\n* Camel case, vs underscores\n * firstLowerCamelCase: use most generally\n * FirstUpperCamelCase: Classes\n * lowecase_underscore_separated: use for mouldes, subroutines, functions\n * UPPERCASE_UNDERSCORE_SEPARATED: constants\n\n* Line up related pieces of syntax (readability when there are repeated elements, ability to count\n the position of arguments), including end-of-line characters.\n\n```fortran\n# WRONG\nfoo=function(apple, banana, corn, &\n durian, eggplant, fig)\n\n# CORRECT\nfoo=function(apple, banana, corn, &\n durian, eggplant, fig )\n```\n\n* Place the same number of arguments on each line except the last for countability/position\n matching.\n\n```fortran\n# WRONG\nfoo=function(a,b,c = 1)\n# CORRECT\nfoo = function(a, b, c=1)\n```\n\n* Horizontal white space: enhances readability, esp w respect to function/subroutine arguments.\n Whitespace helps identify separate things.\n* Vertical white space:\n * No vertical white space: Used to group closely-related lines of code.\n * Single vertical white space: Separate less-related lines of code. After control structures.\n * Two vertical white spaces: only used to emphasize separation between functions, subroutines and\n occasionally large code blocks.\n* Control structures identified against their opening statement.\n * #ifdef: When nested.\n * If, do, while, case: Best practice: All the time. Required: when spanning more than one page of\n vertical space.\n\n```fortran\n#ifdef HYDRO_D\n#ifdef OBSCURE_THING\n…\n#endif /* HYDRO_D */\n#endif /* OBSCURE_THING */\n\n\nif(a .eq. 100) then\n…..\nendif ! if(a .eq. 100)\n\nor\n\nif(a .eq. 100) then !! a .eq. 100 block\n…\nendif !! a .eq. 100 block\n```\n\n* Comment blocks above every unit (module, subtroutine, function), with the following form. This\n should be the NCO standard template.\n\n```fortran\n!===================================================================================================\n! Subroutine Name:\n! subroutine read_nudging_last_obs\n! Author(s)/Contact(s):\n! James L McCreight \n! Abstract:\n! does some fancy thing\n! History Log:\n! 02/03/16 -Created, JLM.\n! Usage:\n! Parameters:\n! Input Files:\n! Output Files:\n! Condition codes:\n! User controllable options: None.\n! Notes: Needs better error handling...\n```\n\n\n* Allocate/deallocate statements do NOT span multiple lines. This is so grep can reveal all\n allocation/deallocation pairs.\n\n```fortran\n# WRONG\nallocate(foo, &\n bar)\n# CORRECT\nallocate(foo)\nallocate(bar)\nallocate(foo, bar)\n```\n\n# Naming\n## Source file names\n* The name of the source file or script shall represent its purpose. All of the functions in a file\n shall have a common purpose.\n* Source file names SHALL NOT include spaces nor colons (‘:’) nor any other special\n characters.\n* End in the `.Fxx` extension, with `xx` corresponding to the fortran standard, e.g. `.F90`\n* Filenames shall use the `lowercase_underscore_separated.Fxx` convention.\n\n## Output file names\n* Source file names SHALL NOT include spaces nor colons (`:`) nor any other special\n characters.\n\n## Variable names\n* Variable names shall convey their intended use to other developers who did not author the code.\n This eliminates need for inline comments that describe variables.\n * DO NOT strive to much for shortening of variable names, prefer meaningful name: local\n shortening is often possible with the associate construct.\n* Comments/descriptions on variables:\n * All variables in argument lists will be described in the definition using FORD syntax.\n * Derived type arguments only need documented in bulk, their individual components only need\n defined where the derived type is defined.\n * Variable descriptions will not be redundant with the variable name\n * Descriptions will describe the physical quantity\n * Descriptions will include units.\n* Variable names shall contain a noun.\n* Exception: when widely accepted equations have simple variable names. (e.g. `F=m*a`)\n* Loop counters should typically have names.\n* Loop counters should NOT be single letters. Simply doubling the letter makes it easier to search\n for the use (and possibly replace).\n* Conventions for special kinds of variables:\n * Accumulation variables: “acc” prefix, e.g.\n * MPI global variables\n * prognostic vs diagnostic variables\n * logical variables must be named to reflect the state they are used to convey, most with the\n verb to be, e.g. :\n * `lib_is_initialized` vs `lib_init`\n * `obj_has_parent` vs `obj_parent`\n\n## Function/Subroutine Names\n* Function names shall contain at least one verb, e.g. `get_name`, `parse_control_string`.\n* Function names shall convey their intended use to other developers who did not author the code.\n* Follow the `lowercase_underscore_separated` convention.\n\n## Constant names\n* Name all constants: Numbers should not be used in the code except in variable definitions.\n* All constants are defined as parameters.\n* Exceptions: should be rare and clearly typed (float, double, etc).\n* Constants follow the `UPPERCASE_UNDERSCORE SEPARATED` convention for naming.\n* Constant names shall describe what the contained value represents within context, e.g.\n `NO_DATA_VALUE`, `PLANCK_LENGTH`, `HIGH_TEMPERATURE_THRESHOLD`, etc.\n\n# Documenting in the source\n* Code documentation should be a primary source of overall documentation. By following simple\n practices, such documentation can be extracted to live separately if needed. But keeping it close\n as possible to the source maintains consistency and improves communication among developers: all\n you need is the source to understand the code (not other random documents)\n* Write code that documents itself. Try to make code as clear as possible (“self-documenting”) to\n avoid use of comments and redundancy between the two which needs synchronized or is confusingly\n out of sync. Writing self-documenting code includes using variable names with obvious meaning and\n documenting ambiguities in variable names when they exist. Minimize commenting “what” (repeating\n the code with comments) but do it when it is necessary for interpretation.\n* Document why (not what). Algorithmic choices are often the hardest thing to perceive, not\n function calls on variables.\n* Indent comments to the indentation level of the code which is being commented.\n* Comments shall be written in English with good spelling, punctuation, and grammar.\n* Documentation shall be placed in the code and [FORD](https://github.com/cmacmackin/ford) will be\n used to generate documentation.\n* TODO: Comments used to remind developers of future or unfinished actions in source code shall\n begin with “TODO FML” (first middle last initials, as available), and describe the action to be\n taken. TODO comments shall also list a specific date or event by which the TODO action will be\n completed.\n\n```fortran\n! TODO JLM : Rename the variable foo to discharge. Target Date: 12/25/20\n\n! TODO JLM : Rename the variable foo to discharge.\n! TODO JLM : Target Date: 12/25/20\n```\n\n* DEPRECATED: Flagging deprecated code sections shall be done in the following way for automated\n removal at end-of-version code release.\n\n```fortran\n!DEPRECATED >>>\n!code\n!code\n!<<< DEPRECATED\n```\n\n# File header comments\n* Each source file shall contain one file header comment.\n* File header comments shall contain the following:\n * A concise description of the collective purpose of file contents.\n * Exception: When a file contains only one class or function definition, this description\n shall simply state the file is an implementation or definition file for class/function\n ``. The class or function description will be written into the class or function\n header comment.\n* Organization name: National Center for Atmospheric Research\n* Current maintainer\n* Author names. Multiple authors should be listed when more than one developer has worked on a\n source file over time.\n\n```fortran\n! module_super_foo.F\n! Purpose: This module file contains the derived type and\n! methods for the super_foo class.\n! National Center for Atmospheric Research\n! Responsible: James L McCreight ucar\n! Authors: James McCreight, Logan Karsten, Wei Yu\n```\n\n# Module/Subroutines/Function Usage\n* Always use modules.\n* Intent: all arguments should be given an intent (in,out, inout),\n* Each argument is defined on its own line. Document details in- or below- line using\n [FORD](https://github.com/cmacmackin/ford/wiki/Writing-Documentation) conventions.\n * FORD will ignore a normal comments preceded with a single exclamation mark (!) However,\n comments with two exclamation marks (!!) are interpreted as documentation and will be captured\n for inclusion in the FORD output. By default, FORD documentation comes after whatever it is\n that you are documenting, either at the end of the line or on a subsequent line.\n * For longer blocks of documentation, it can be inconvenient to continually type the \"docmark\" =\n ‘!!’. For such situations, the docmark_alt (set to * by default) may be used in the first line\n of the documentation comment. Any immediately following lines containing only a comment will\n then be included in the block of documentation, without needing the \"docmark\".\n\n Example:\n```fortran\nsubroutine feed_pets(cats, dogs, food, angry)\n !! Feeds your cats and dogs, if enough food is available. If not enough\n !! food is available, some of your pets will get angry.\n\n ! Arguments\n integer, intent(in) :: cats\n !! The number of cats to keep track of.\n integer, intent(in) :: dogs\n !! The number of dogs to keep track of.\n real, intent(inout) :: food\n !! The amount of pet food (in kilograms) which you have on hand.\n integer, intent(out) :: angry\n !! The number of pets angry because they weren't fed.\n\n !...\n return\nend subroutine feed_pets\n```\n\n* Avoid “side effects” (return values are the only thing modified: files are not created,\n module/global variables are not changed, etc). Use pure functions?\n* `implicit none` for all program units\n* Use `use, only:` as much as possible.\n* Restrict number of passed variables per line in the function/subroutine definition/call to 4 max.\n Line up variables vertically for ease of reading and counting. Match the call layout to the\n definition layout.\n* Have a local variables section separate from passed variables\n\n```fortran\n# WRONG\nsome_function(a,b,c,d,e,f,g,h &\n,i,j,k,l)\nreal :: a,b,c,d,e,f\nIngeter :: localVar\nReal, intent(in) :: h,i,j,k,l\n\ncall some_function(a,b,c,d &\n,e,f &\ng,h,i,j,k,l)\n\n# CORRECT\nsome_function(a, b, c, d &\n ,e, f, g, h &\n ,i, j, k, l )\nUse module_great_stuff: only, shiny_object, rad_tool\nImplicit none\nreal, intent(in) :: a !! acceleration (m/s2)\nreal, intent(in) :: b !! brownian coeff (-)\nreal, intent(out) :: c !! celerity (m/s)\n… (etc) …\nreal, intent(in) :: l !! lousy variable (kgmsK)\n\n!! Local variables\ninteger :: localVar\n\ncall some_function(a, b, c, d &\n ,e, f, g, h &\n ,i, j, k, l )\n```\n\n# Variable Scoping and Definition\n* Minimize global data.\n* Global data should be limited to constants as much as possible.\n* Define and use global type parameters.\n* Make all derived type components private.\n\n# Run-time error messages\n* Must indicate the function/routine in which they occur.\n* Should be informative.\n\n\n# Compiler warning messages\n* Compilers generally issue two types of messages: warnings and errors. Extent of compiler warning\n messages can typically be tuned with a compiler option. Compiler warnings normally do not stop\n the compile process, but can still result in run-time problems. Compiler errors do stop the\n compile process, forcing the developer to fix the problem and recompile. STANDARD:\n* When available, compiler options should be set to produce the maximum number of warning messages.\n* Compiler and linker warnings shall be treated as errors and fixed.\n\n# Other general guidelines\n* Code should always be written with cleanliness and clarity in mind. Algorithm implementations\n should not be unnecessarily complicated without significant performance gains over simpler\n alternatives.\n* Structured programming - do NOT use GOTO\n* Related resources\n * http://research.metoffice.gov.uk/research/nwp/numerical/fortran90/f90_standards.html\n * https://github.com/szaghi/zen-of-fortran#standard\n * http://www.fortran.com/Fortran_Style.pdf\n" }, { "path": ".github/CONTRIBUTING.md", "content": "# Contributing to WRF-Hydro®\nAll bug reports, bug fixes, code, and documentation contributions are welcome and encouraged.\nHowever, guidelines need to be established and followed to ensure that community contributions can\nbe effectively incorporated.\n\nPlease read the following guidelines carefully before contributing.\n\n# Guidelines\n\n**Failure to adhere to the following guidelines may result in your contributions being permanently\nrejected if they are unable to be merged.**\n\nAll contributions must be made through the\n[NCAR/wrf_hydro_nwm_public](https://github.com/NCAR/wrf_hydro_nwm_public) GitHub page.\nContributions submitted via email or help desk will not be processed.\n\n## Bug reports, feature requests, and documentation suggestions\nAll bug reports, feature requests, and documentation suggestions should be submitted via [GitHub\nissues](https://github.com/NCAR/wrf_hydro_nwm_public/issues). Before submitting your issue, please\nsearch for a few keywords related to your issue in the open and closed issues to discover if your\nissue has already been logged and/or resolved. An issue template has been provided to assist with\nsubmitting bug reports. For more information on using GitHub issues, please see\nhttps://help.github.com/articles/about-issues/.\n\n### Bug reports\nPlease use the supplied issue template when submitting bug reports. This will help ensure that your\nbug is described in sufficient detail. You can read more on how to construct an\nappropriate bug report here: https://stackoverflow.com/help/mcve\n\n### Feature requests\nPlease follow similar guidelines when suggesting new features as you would for reporting bugs. Be\nspecific and detail the added value of your suggested feature.\n\n### Documentation suggestions\nAll technical documentation for the WRF-Hydro model will eventually be formatted as markdown, which\nwill greatly simplify updates and changes in the future. In the meantime, please reference the\ndocument title, page number and quote the line or section for suggesting changes to the\ndocumentation.\n\n## Code contributions\nAll code development contributions will be made via [forks](https://help.github.com/articles/about-forks/)\nand [pull requests](https://help.github.com/articles/about-pull-requests/). If you are\nunfamiliar with GitHub, forks, or pull requests, see [collaborating with issues and pull\nrequests](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/) for guidance.\n\n### WRF-Hydro Fortran code style standards\nPlease see our Fortran [code style guidelines](CODESTYLE.md)\n\n### Universal guidelines\n\n* All code contributions must be made through GitHub following specific guidelines listed below.\n* All contributions must be made in an open, and public way via the GitHub repository. There will\n be no embargo period for code contributions.\n* All contributions must be able to be merged without conflict. It is the responsibility of the\n contributor to resolve any merge conflicts **prior** to submitting a pull request.\n* All contributions must pass relevant automated testing procedures. These tests are executed\n automatically when you submit your pull request.\n* Be respectful when giving and receiving feedback on contributions or issues (see our community [code of conduct](../CODE_OF_CONDUCT.md).\n\n### Pull requests\n\n#### Contributor responsibility\nPull requests will only be accepted if they follow the best practices described below. Not\nfollowing best practices described below is grounds for rejection of pull requests and may result\nin excessive manual work for contributors. It is the contributors’ responsibility to know and\nfollow best git practices.\n\n#### Commits: practices & messages\nLearning to use commits wisely and “atomically” is the foundation for success. As users gain\nfamiliarity with basics of how git works and the merging practices we are using. The next level of\nsophistication is interaction with the git log. Reading logs is greatly facilitated by writing good\nlogs, or “commit messages”. The following webpage gives a crash course on how to write good commit\nmessages: https://chris.beams.io/posts/git-commit/\n\n#### Frequency\nPull requests should happen with high enough frequency to minimize the scope of the code review.\nCommits which do not changes answers (pass regression testing) MUST be kept separate from commits\nwhich do change answers even when the work is on the same feature or bug. The portion of the code\nwhich changes the answer must be isolated as much as possible into its own pull request.\n\n### Types of code contributions\n#### Bug fixes\nAll bug fixes must address a specific [GitHub\nissue](https://github.com/NCAR/wrf_hydro_nwm_public/issues). Only issues labeled with [\"community\ndev\"](https://github.com/NCAR/wrf_hydro_nwm_public/labels/community%20dev) are open to community\ncontributions. The majority of issues will be open to community contributions, but some cases may\nrequire more careful handling. Issues without the \"community dev\" label are either still being\ninvestigated, are of broad scope, or involve changes to code that is actively being developed internally.\n\nAll code changes to address issues must be submitted using a pull request, and the corresponding\nissue number must be referenced in the pull request. For more information on referencing issues,\nsee [issues and keywords](https://help.github.com/articles/closing-issues-using-keywords/).\n\n#### New features\nCode contributions for minor model enhancements or new features follow a similar pattern to bug\nfixes. The proposed feature must be submitted as a GitHub issue and all discussions regarding the\nnew feature should reside in the issue thread. Additionally, work should not begin on the new\nfeature until the issue has been tagged with \"community dev\".\n\nDepending on the scope of the new feature, a WRF-Hydro core contributor may suggest you create a\n[branch](https://help.github.com/articles/about-branches/) to hold all development for the new\nfeature.\n\n#### Research development\nLarger-scale research development, e.g. model coupling, must be coordinated with a WRF-Hydro team\nmember prior to beginning work. This type of development may impact other community projects and\nrequires more careful governance to help steer the direction of model development and maximize\nharmony among the various NCAR, NOAA, and WRF-Hydro community research efforts.\n\n### Checklist for new feature contributions\n#### You should have the following to submit a new feature contribution to the WRF-Hydro code base:\n1. A WRF-Hydro team point of contact (POC). Early in your development process, it is always a good idea\nto reach out to the WRF-Hydro team and find a good POC for your new feature. This person will help\nkeep you informed of new developments as they may relate to your feature, advise you on which branches\nto keep current with (if other than main), and provide pointers on requirements.\n2. New feature code integrated in with the latest WRF-Hydro main branch (or other as advised by your\nWRF-Hydro POC). This merged code should exist in your own fork, but can be in your own main branch or\na separate feature branch.\n * *TIP #1*: It is always a good strategy to pull the latest WRF-Hydro main code into your branch\nfairly often throughout your development cycle. Leaving months of code changes to merge at the end of\nyour development cycle can result in lots of merge conflicts, time-consuming manual edits, and higher\npotential for making errors.\n * *TIP #2*: New code should follow the\n[WRF-Hydro code contribution guidelines](https://github.com/NCAR/wrf_hydro_nwm_public/blob/main/.github/CONTRIBUTING.md).\n3. Documentation for your new feature. This should include (1) a simple summary in the release notes\n(added to [NEWS.md](https://github.com/NCAR/wrf_hydro_nwm_public/blob/main/NEWS.md)), and (2) a\ndetailed description of the new feature suitable to be included within the\n[WRF-Hydro Technical Description](https://ral.ucar.edu/sites/default/files/public/projects/wrf_hydro/technical-description-user-guide/wrf-hydro-v5.1.1-technical-description.pdf),\nincluded as a new markdown document in the\n[Doc](https://github.com/NCAR/wrf_hydro_nwm_public/tree/main/trunk/NDHMS/Doc)\nfolder.\n4. An updated\n[standalone test case](https://ral.ucar.edu/projects/wrf_hydro/testcases) demonstrating how\nyour new feature works, based on one of the existing WRF-Hydro test cases (e.g., Croton). If you cannot\nadapt an existing test case and need to create something new, please consult with your POC. The test\ncase should include:\n * Domain and parameter files\n * Namelists\n * Example forcings if needed (idealized forcing use is OK)\n * Test case documentation\n5. Testing - you must clearly demonstrate that your new feature:\n * Does no harm to the existing code (e.g., produces identical solutions EXCEPT when the new feature is\nactivated by a namelist or parameter setting).\n * Fixes a documented issue (reference existing issue in the\n[WRF-Hydro GitHub issue tracking](https://github.com/NCAR/wrf_hydro_nwm_public/issues) - this could also be a feature request).\n * If model performance is improved, for example through more efficient IO, memory utilization, or other\nsoftware-specific improvements, it must be demonstrable and measurable.\n * *TIP*: All pull requests go through automated CI testing, but for a new feature it is important to do\nthorough testing ahead of time so you have a good sense of the model impacts and can explain/justify them.\nDo not wait until automated CI testing to test your new feature.\n6. A pull request from a branch on your fork to the WRF-Hydro main branch (or other as advised by your\nWRF-Hydro POC). Make sure to also follow the specific\n[WRF-Hydro pull request guidelines](https://github.com/NCAR/wrf_hydro_nwm_public/blob/main/.github/PULL_REQUEST_TEMPLATE.md).\n" }, { "path": ".github/ISSUE_TEMPLATE/bug_report.md", "content": "---\nname: Bug report\nabout: Create a report to help us improve\ntitle: ''\nlabels: ''\nassignees: ''\n\n---\n\n**Describe the bug**\nA clear and concise description of what the bug is.\n\n**To Reproduce**\nSteps to reproduce the behavior:\n1. Go to '...'\n2. Configure '....'\n3. Run '....'\n4. See error\n\n**Expected behavior**\nA clear and concise description of what you expected to happen.\n\n**Screenshots**\nIf applicable, add screenshots to help explain your problem.\n\n**Additional context**\nAdd any other context about the problem here.\n" }, { "path": ".github/PULL_REQUEST_TEMPLATE.md", "content": "TYPE: choose one of [bug fix, enhancement, new feature, feature removed, no impact, text only]\n\nKEYWORDS: approximately 3 to 6 words (more is always better) related to your commit, separated by commas\n\nSOURCE: Developer's name and affiliation\n\nDESCRIPTION OF CHANGES: One or more paragraphs describing problem, solution, and required changes.\n\nISSUE: The GitHub Issue that this PR addresses. For issue number 123, it would be `Fixes #123`\n\nTESTS CONDUCTED: Explicitly state if regression, integration, or unit tests were run before submitting.\n\nNOTES: Optional, as appropriate. Delete if not used.\n\n\n" }, { "path": ".github/workflows/test-pr.yml", "content": "name: build\n\non:\n push:\n branches: [ main ]\n pull_request:\n branches: [ main ]\n\n # Allows you to run this workflow manually from the Actions tab\n workflow_dispatch:\n inputs:\n pr:\n description: \"PR to test\"\n required: true\n\njobs:\n Model_Testing:\n if: github.repository == 'NCAR/wrf_hydro_nwm_public'\n strategy:\n fail-fast: false\n max-parallel: 4\n matrix:\n configuration: [nwm_ana, nwm_long_range, gridded, reach, reach_lakes]\n runs-on: ubuntu-latest\n\n env:\n MPI_HOME: /usr/share/miniconda\n NETCDF: /usr/share/miniconda\n NETCDF_INCLUDES: /usr/share/miniconda/include\n NETCDF_LIBRARIES: /usr/share/miniconda/lib\n\n\n steps:\n - uses: actions/checkout@v4\n - uses: actions/setup-python@v5\n with:\n python-version: '3.11'\n\n - name: Checkout candidate (pull request / push)\n if: ${{ github.event_name == 'pull_request' || github.event_name == 'push' }}\n uses: actions/checkout@v4\n with:\n path: candidate\n\n - name: Checkout candidate (manual)\n if: ${{ github.event_name == 'workflow_dispatch' }}\n env:\n GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}\n run: gh repo clone ${{ github.repository }} candidate && cd candidate && gh pr checkout -R ${{ github.repository }} ${{ github.event.inputs.pr }}\n\n - name: Checkout reference (pull request)\n if: ${{ github.event_name == 'pull_request' }}\n uses: actions/checkout@v4\n with:\n ref: ${{ github.event.pull_request.base.ref }}\n path: reference\n\n - name: Checkout reference (push)\n if: ${{ github.event_name == 'push' }}\n uses: actions/checkout@v4\n with:\n ref: ${{ github.event.before }}\n path: reference\n\n - name: Checkout reference (manual)\n if: ${{ github.event_name == 'workflow_dispatch' }}\n env:\n GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}\n run: gh repo clone ${{ github.repository }} reference && cd reference && git checkout origin/$(gh pr view ${{ github.event.inputs.pr }} --json baseRefName --jq '.baseRefName')\n\n - name: Install dependencies with apt-get\n run: |\n sudo apt-get update \\\n && sudo apt-get install -yq --no-install-recommends \\\n wget \\\n curl \\\n bzip2 \\\n ca-certificates \\\n libhdf5-dev \\\n gfortran \\\n g++ \\\n m4 \\\n make \\\n libswitch-perl \\\n git \\\n bc \\\n openmpi-bin openmpi-common libopenmpi-dev \\\n libxml2-dev \\\n libnetcdf-dev \\\n libnetcdff-dev\n\n - name: Install dependencies with pip\n run: |\n python3 -m pip install matplotlib numpy xarray dask netCDF4 pygithub\n\n - name: Compile reference\n run: |\n cd $GITHUB_WORKSPACE/reference\n cmake -B build\n make -C build -j\n\n - name: Compile candidate\n run: |\n cd $GITHUB_WORKSPACE/candidate\n cmake -B build\n make -C build -j\n\n - name: Run reference model\n run: |\n cd $GITHUB_WORKSPACE/reference/build/Run\n make run-croton-${{ matrix.configuration }}\n\n - name: Run candidate model\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n make run-croton-${{ matrix.configuration }}\n\n - name: generic - Compare HYDRO_RST.* output with xrcmp\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n for file in output_${{ matrix.configuration }}/HYDRO_RST.*; do\\\n python ${GITHUB_WORKSPACE}/candidate/tests/utils/xrcmp.py \\\n --candidate $file \\\n --reference $GITHUB_WORKSPACE/reference/build/Run/$file \\\n --log_file $file_diff.txt \\\n --n_cores 1; \\\n done\n - name: generic - Compare RESTART.* output with xrcmp\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n for file in output_${{ matrix.configuration }}/RESTART.*; do\\\n python ${GITHUB_WORKSPACE}/candidate/tests/utils/xrcmp.py \\\n --candidate $file \\\n --reference $GITHUB_WORKSPACE/reference/build/Run/$file \\\n --log_file $file_diff.txt \\\n --n_cores 1; \\\n done\n - name: generic - Compare last *.CHANOBS_DOMAIN1 output with xrcmp\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n file=$(ls -t output_${{ matrix.configuration }}/*.CHANOBS_DOMAIN1 | head -n 1)\n python ${GITHUB_WORKSPACE}/candidate/tests/utils/xrcmp.py \\\n --candidate $file \\\n --reference $GITHUB_WORKSPACE/reference/build/Run/$file \\\n --log_file $file_diff.txt \\\n --n_cores 1; \\\n - name: generic - Compare last *.CHRTOUT_DOMAIN1 output with xrcmp\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n file=$(ls -t output_${{ matrix.configuration }}/*.CHRTOUT_DOMAIN1 | head -n 1)\n python ${GITHUB_WORKSPACE}/candidate/tests/utils/xrcmp.py \\\n --candidate $file \\\n --reference $GITHUB_WORKSPACE/reference/build/Run/$file \\\n --log_file $file_diff.txt \\\n --n_cores 1; \\\n - name: generic - Compare last *.LSMOUT_DOMAIN1 output with xrcmp\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n file=$(ls -t output_${{ matrix.configuration }}/*.LSMOUT_DOMAIN1 | head -n 1)\n python ${GITHUB_WORKSPACE}/candidate/tests/utils/xrcmp.py \\\n --candidate $file \\\n --reference $GITHUB_WORKSPACE/reference/build/Run/$file \\\n --log_file $file_diff.txt \\\n --n_cores 1; \\\n\n - name: generic - Compare last *.RTOUT_DOMAIN1 output with xrcmp\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n file=$(ls -t output_${{ matrix.configuration }}/*.RTOUT_DOMAIN1 | head -n 1)\n python ${GITHUB_WORKSPACE}/candidate/tests/utils/xrcmp.py \\\n --candidate $file \\\n --reference $GITHUB_WORKSPACE/reference/build/Run/$file \\\n --log_file $file_diff.txt \\\n --n_cores 1; \\\n\n - name: generic - Compare output with compare_output\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n mkdir output_diff\n python -c \\\n \"import sys; \\\n sys.path.append('${GITHUB_WORKSPACE}/candidate/tests/utils'); \\\n import compare_output; \\\n from pathlib import Path; \\\n compare_output.plot_diffs('${GITHUB_WORKSPACE}/candidate/build/Run/output_diff', \\\n '${GITHUB_WORKSPACE}/candidate/build/Run/output_${{ matrix.configuration }}/', \\\n '${GITHUB_WORKSPACE}/reference/build/Run/output_${{ matrix.configuration }}/', \\\n '${{ matrix.configuration }}')\"\n\n - name: generic - Copy test results from container\n if: ${{ always() }}\n run: |\n mkdir -p $GITHUB_WORKSPACE/test_report\n cp -r $GITHUB_WORKSPACE/candidate/build/Run/output_diff/diff_plots/* $GITHUB_WORKSPACE/test_report/\n\n - name: generic - Attach diff plots to PR\n if: ${{ failure() }}\n shell: bash\n run: |\n cd $GITHUB_WORKSPACE/candidate/tests/local/utils\n bash attach_all_plots.bash $(jq --raw-output .pull_request.number \"$GITHUB_EVENT_PATH\") ${{ matrix.configuration }} generic\n\n - name: generic - Archive test results to GitHub\n if: ${{ failure() }}\n uses: actions/upload-artifact@v4\n with:\n name: test-reports\n path: |\n ${{ github.workspace }}/test_report/*\n\n\n # n-cores test\n - name: Run parallel candidate model\n run: |\n rm -r $GITHUB_WORKSPACE/test_report/\n cd $GITHUB_WORKSPACE/candidate/build/Run\n make clean\n make run-croton-${{ matrix.configuration }}-parallel\n\n - name: n-cores - Compare HYDRO_RST.* output with xrcmp\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n for file in output_${{ matrix.configuration }}/HYDRO_RST.*; do\\\n python ${GITHUB_WORKSPACE}/candidate/tests/utils/xrcmp.py \\\n --candidate $file \\\n --reference $GITHUB_WORKSPACE/reference/build/Run/$file \\\n --log_file $file_diff.txt \\\n --n_cores 1; \\\n done\n - name: n-cores - Compare RESTART.* output with xrcmp\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n for file in output_${{ matrix.configuration }}/RESTART.*; do\\\n python ${GITHUB_WORKSPACE}/candidate/tests/utils/xrcmp.py \\\n --candidate $file \\\n --reference $GITHUB_WORKSPACE/reference/build/Run/$file \\\n --log_file $file_diff.txt \\\n --n_cores 1; \\\n done\n - name: n-cores - Compare last *.CHANOBS_DOMAIN1 output with xrcmp\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n file=$(ls -t output_${{ matrix.configuration }}/*.CHANOBS_DOMAIN1 | head -n 1)\n python ${GITHUB_WORKSPACE}/candidate/tests/utils/xrcmp.py \\\n --candidate $file \\\n --reference $GITHUB_WORKSPACE/reference/build/Run/$file \\\n --log_file $file_diff.txt \\\n --n_cores 1; \\\n - name: n-cores - Compare last *.CHRTOUT_DOMAIN1 output with xrcmp\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n file=$(ls -t output_${{ matrix.configuration }}/*.CHRTOUT_DOMAIN1 | head -n 1)\n python ${GITHUB_WORKSPACE}/candidate/tests/utils/xrcmp.py \\\n --candidate $file \\\n --reference $GITHUB_WORKSPACE/reference/build/Run/$file \\\n --log_file $file_diff.txt \\\n --n_cores 1; \\\n - name: n-cores - Compare last *.LSMOUT_DOMAIN1 output with xrcmp\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n file=$(ls -t output_${{ matrix.configuration }}/*.LSMOUT_DOMAIN1 | head -n 1)\n python ${GITHUB_WORKSPACE}/candidate/tests/utils/xrcmp.py \\\n --candidate $file \\\n --reference $GITHUB_WORKSPACE/reference/build/Run/$file \\\n --log_file $file_diff.txt \\\n --n_cores 1; \\\n\n - name: n-cores - Compare last *.RTOUT_DOMAIN1 output with xrcmp\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n file=$(ls -t output_${{ matrix.configuration }}/*.RTOUT_DOMAIN1 | head -n 1)\n python ${GITHUB_WORKSPACE}/candidate/tests/utils/xrcmp.py \\\n --candidate $file \\\n --reference $GITHUB_WORKSPACE/reference/build/Run/$file \\\n --log_file $file_diff.txt \\\n --n_cores 1; \\\n\n - name: n-cores - Compare output with compare_output\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n rm -rf output_diff\n mkdir output_diff\n python -c \\\n \"import sys; \\\n sys.path.append('${GITHUB_WORKSPACE}/candidate/tests/utils'); \\\n import compare_output; \\\n from pathlib import Path; \\\n compare_output.plot_diffs('${GITHUB_WORKSPACE}/candidate/build/Run/output_diff', \\\n '${GITHUB_WORKSPACE}/candidate/build/Run/output_${{ matrix.configuration }}/', \\\n '${GITHUB_WORKSPACE}/reference/build/Run/output_${{ matrix.configuration }}/', \\\n '${{ matrix.configuration }}')\"\n\n - name: n-cores - Copy test results from container\n if: ${{ always() }}\n run: |\n mkdir -p $GITHUB_WORKSPACE/test_report\n cp -r $GITHUB_WORKSPACE/candidate/build/Run/output_diff/diff_plots/* $GITHUB_WORKSPACE/test_report/\n\n - name: n-cores - Attach diff plots to PR\n if: ${{ failure() }}\n shell: bash\n run: |\n cd $GITHUB_WORKSPACE/candidate/tests/local/utils\n bash attach_all_plots.bash $(jq --raw-output .pull_request.number \"$GITHUB_EVENT_PATH\") ${{ matrix.configuration }} n-cores\n\n - name: n-cores - Archive test results to GitHub\n if: ${{ failure() }}\n uses: actions/upload-artifact@v4\n with:\n name: test-reports\n path: |\n ${{ github.workspace }}/test_report/*\n\n\n # Testing perfect restart, not cleaning candidate model output\n - name: Setup and run candidate model perfect restart startup\n run: |\n rm -r $GITHUB_WORKSPACE/test_report/\n cd $GITHUB_WORKSPACE/candidate/build/Run\n sed -i 's|RESTART_FILENAME_REQUESTED = \"RESTART/RESTART.2011082600_DOMAIN1\"|RESTART_FILENAME_REQUESTED = \"./RESTART.2011090100_DOMAIN1\"|' namelist.hrldas\n sed -i 's/KDAY = 7/KDAY = 1/' namelist.hrldas\n rm output_${{ matrix.configuration }}/RESTART.2011090200_DOMAIN1\n rm output_${{ matrix.configuration }}/HYDRO_RST.2011-09-02_00:00_DOMAIN1\n make run-croton-${{ matrix.configuration }}-parallel\n\n - name: restart - Compare HYDRO_RST.* output with xrcmp\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n for file in output_${{ matrix.configuration }}/HYDRO_RST.2011-09-02_00:00_DOMAIN1; do\\\n python ${GITHUB_WORKSPACE}/candidate/tests/utils/xrcmp.py \\\n --candidate $file \\\n --reference $GITHUB_WORKSPACE/reference/build/Run/$file \\\n --log_file $file_diff.txt \\\n --n_cores 1; \\\n done\n - name: restart - Compare RESTART.* output with xrcmp\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n for file in output_${{ matrix.configuration }}/RESTART.2011090200_DOMAIN1; do\\\n python ${GITHUB_WORKSPACE}/candidate/tests/utils/xrcmp.py \\\n --candidate $file \\\n --reference $GITHUB_WORKSPACE/reference/build/Run/$file \\\n --log_file $file_diff.txt \\\n --n_cores 1; \\\n done\n - name: restart - Compare last *.CHANOBS_DOMAIN1 output with xrcmp\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n file=$(ls -t output_${{ matrix.configuration }}/*.CHANOBS_DOMAIN1 | head -n 1)\n python ${GITHUB_WORKSPACE}/candidate/tests/utils/xrcmp.py \\\n --candidate $file \\\n --reference $GITHUB_WORKSPACE/reference/build/Run/$file \\\n --log_file $file_diff.txt \\\n --n_cores 1; \\\n - name: restart - Compare last *.CHRTOUT_DOMAIN1 output with xrcmp\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n file=$(ls -t output_${{ matrix.configuration }}/*.CHRTOUT_DOMAIN1 | head -n 1)\n python ${GITHUB_WORKSPACE}/candidate/tests/utils/xrcmp.py \\\n --candidate $file \\\n --reference $GITHUB_WORKSPACE/reference/build/Run/$file \\\n --log_file $file_diff.txt \\\n --n_cores 1; \\\n - name: restart - Compare last *.LSMOUT_DOMAIN1 output with xrcmp\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n file=$(ls -t output_${{ matrix.configuration }}/*.LSMOUT_DOMAIN1 | head -n 1)\n python ${GITHUB_WORKSPACE}/candidate/tests/utils/xrcmp.py \\\n --candidate $file \\\n --reference $GITHUB_WORKSPACE/reference/build/Run/$file \\\n --log_file $file_diff.txt \\\n --n_cores 1; \\\n\n - name: restart - Compare last *.RTOUT_DOMAIN1 output with xrcmp\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n file=$(ls -t output_${{ matrix.configuration }}/*.RTOUT_DOMAIN1 | head -n 1)\n python ${GITHUB_WORKSPACE}/candidate/tests/utils/xrcmp.py \\\n --candidate $file \\\n --reference $GITHUB_WORKSPACE/reference/build/Run/$file \\\n --log_file $file_diff.txt \\\n --n_cores 1; \\\n\n - name: restart - Compare output with compare_output\n if: ${{ always() }}\n run: |\n cd $GITHUB_WORKSPACE/candidate/build/Run\n rm -rf output_diff\n mkdir output_diff\n python -c \\\n \"import sys; \\\n sys.path.append('${GITHUB_WORKSPACE}/candidate/tests/utils'); \\\n import compare_output; \\\n from pathlib import Path; \\\n compare_output.plot_diffs('${GITHUB_WORKSPACE}/candidate/build/Run/output_diff', \\\n '${GITHUB_WORKSPACE}/candidate/build/Run/output_${{ matrix.configuration }}/', \\\n '${GITHUB_WORKSPACE}/reference/build/Run/output_${{ matrix.configuration }}/', \\\n '${{ matrix.configuration }}')\"\n\n - name: restart - Copy test results from container\n if: ${{ always() }}\n run: |\n mkdir -p $GITHUB_WORKSPACE/test_report\n cp -r $GITHUB_WORKSPACE/candidate/build/Run/output_diff/diff_plots/* $GITHUB_WORKSPACE/test_report/\n\n - name: restart - Attach diff plots to PR\n if: ${{ failure() }}\n shell: bash\n run: |\n cd $GITHUB_WORKSPACE/candidate/tests/local/utils\n bash attach_all_plots.bash $(jq --raw-output .pull_request.number \"$GITHUB_EVENT_PATH\") ${{ matrix.configuration }} perfect-restart\n\n - name: restart - Archive test results to GitHub\n if: ${{ failure() }}\n uses: actions/upload-artifact@v4\n with:\n name: test-reports\n path: |\n ${{ github.workspace }}/test_report/*\n" }, { "path": ".gitignore", "content": "*.o\n*.so\n*.so.*\n*.mod\n*.lst\n*~\nMakefile.comm\ndocs/_build/\nsrc/lib/*\nsrc/macros\nsrc/HRLDAS/user_build_options\n*exe\n/.project\nsrc/Run\nsrc/Run/\nsrc/setEnvar.sh\nsrc/Makefile.comm\nsrc/Land_models/NoahMP/user_build_options\nsrc/Land_models/Noah/user_build_options\nsrc/LandModel\nsrc/LandModel_cpl\nsrc/Land_models/NoahMP/MPP\nbuild/\nREADME.md\n/.idea\n*__pycache__*\n*pytest_cache*\n*.log\ncompile_options.sh\n.DS_Store\n.venv\n.vscode\n" }, { "path": ".readthedocs.yaml", "content": "# Read the Docs configuration file for Sphinx projects\n# See https://docs.readthedocs.io/en/stable/config-file/v2.html for details\n\n# Required\nversion: 2\n\n# Set the OS, Python version and other tools you might need\nbuild:\n os: ubuntu-22.04\n tools:\n python: \"3.11\"\n # You can also specify other tool versions:\n # nodejs: \"20\"\n # rust: \"1.70\"\n # golang: \"1.20\"\n\n# Build documentation in the \"docs/\" directory with Sphinx\nsphinx:\n configuration: docs/userguide/conf.py\n # You can configure Sphinx to use a different builder, for instance use the dirhtml builder for simpler URLs\n # builder: \"dirhtml\"\n # Fail on all warnings to avoid broken references\n # fail_on_warning: true\n\n# Optionally build your docs in additional formats such as PDF and ePub\nformats:\n - pdf\n# - epub\n\n# Optional but recommended, declare the Python requirements required\n# to build your documentation\n# See https://docs.readthedocs.io/en/stable/guides/reproducible-builds.html\npython:\n install:\n - requirements: docs/requirements.txt\n" }, { "path": "CITATION.cff", "content": "authors:\n - family-names: Gochis\n given-names: David\n orcid: 0000-0001-8668-4850\n # origin: technical doc\n - family-names: Barlage\n given-names: Michael\n # orcid:\n # origin: technical doc\n - family-names: Cabell\n given-names: Ryan\n orcid: 0000-0002-3623-5130\n # origin: technical doc\n - family-names: Casali\n given-names: Matthew\n # orcid: 0000-0001-6939-0332\n # origin: technical doc\n # - family-names:\n # given-names: champham\n # orcid:\n # origin: github\n - family-names: Dugger\n given-names: Aubrey\n orcid: 0000-0001-8250-4218\n # origin: technical doc\n - family-names: Eidhammer\n given-names: Trude\n orcid: 0000-0003-2281-9351\n # origin: github\n - family-names: Enzminger\n given-names: Tom\n orcid: 0000-0001-5072-3854\n # origin: technical doc\n - family-names: FitzGerald\n given-names: Katelyn\n orcid: 0000-0003-4184-1917\n # origin: technical doc\n - family-names: Felfelani\n given-names: Farshid\n orcid: 0000-0003-1360-5095\n # origin: technical doc\n - family-names: Gaydos\n given-names: Andy\n # origin: technical doc\n - family-names: Mazrooei\n given-names: Amir\n orcid: 0000-0001-9171-9595\n # origin: technical doc\n - family-names: McAllister\n given-names: Molly\n # orcid:\n # origin: technical doc\n - family-names: McCreight\n given-names: James\n orcid: 0000-0001-6018-425X\n # origin: technical doc\n - family-names: McCluskey\n given-names: Alyssa\n # orcid:\n # origin: technical doc\n - family-names: Omani\n given-names: Nina\n # orcid:\n # origin: technical doc\n - family-names: RafieeiNasab\n given-names: Arezoo\n # github-names: arezoorn\n orcid: 0000-0001-8557-107X\n # origin: technical doc\n - family-names: Rasmussen\n given-names: Soren\n #github-names: scrasmussen\n orcid: 0000-0003-3899-1463\n # origin: github\n - family-names: Read\n given-names: Laura\n orcid: 0000-0003-3476-1249\n # origin: technical doc\n - family-names: Sampson\n given-names: Kevin\n orcid: 0000-0002-5537-7775\n # origin: technical doc\n - family-names: Srivastava\n given-names: Ishita\n orcid: 0009-0002-4060-6659\n # origin: technical doc\n - family-names: Yates\n given-names: David\n orcid: 0000-0002-0688-3460\n # origin: technical doc\n - family-names: Zhang\n given-names: Yongxin\n orcid: 0000-0001-6321-1276\n # origin: technical doc\n - family-names: Yu\n given-names: Wei\n # github-names:\n # orcid:\n # origin:\n - family-names: Karsten\n given-names: Logan\n # github-names: logankarsten\n # orcid:\n # origin: github\n - family-names: Dunlap\n given-names: Rocky\n # orcid:\n # origin: github\n - family-names: Fanfarillo\n given-names: Alessandro\n orcid: 0000-0003-3487-7452\n # origin: github\n - family-names: Fersch\n given-names: Benjamin\n # orcid:\n # origin: github\n - family-names: Heldmyer\n given-names: Aaron\n # github: aheldmyer\n orcid: 0000-0001-8608-4927\n # origin: github\n - family-names: Johnson\n given-names: Donald\n # github-names: donaldwj\n # orcid:\n # origin: github\n - family-names: Lahmers\n given-names: Tim\n # orcid:\n # origin: github\n - family-names: Mattern\n given-names: David\n # orcid:\n # origin: github\n # - family-names:\n # given-names: Nels\n # orcid:\n # origin: github\n - family-names: Rosen\n given-names: Dan\n # orcid:\n # origin: github\n - family-names: Valayamkunnath\n given-names: Prasanth\n orcid: 0000-0003-2270-0780\n # origin: github\n\ncff-version: 1.2.0\ndate-released: \"2025-03-14\"\ntitle: \"WRF-Hydro\"\nrepository-code: \"https://github.com/NCAR/wrf_hydro_nwm_public\"\nversion: 5.4.0\nurl: \"https://ral.ucar.edu/projects/wrf_hydro\"\nkeywords:\n - \"hydrologic model\"\n - \"hydrology\"\n - \"hydrometeorology\"\nlicense-url: \"https://github.com/NCAR/wrf_hydro_nwm_public/blob/main/LICENSE.txt\"\nidentifiers:\n - description: \"This is the archived snapshot of all versions of WRF-Hydro\"\n type: doi\n value: 10.5281/zenodo.3625237\n - description: \"This is the archived snapshot of version v5.4.0 of WRF-Hydro\"\n type: doi\n value: 10.5281/zenodo.15040873\n - description: \"This is the archived snapshot of version v5.3.0 of WRF-Hydro\"\n type: doi\n value: 10.5281/zenodo.5773161\n - description: \"This is the archived snapshot of version v5.2.0 of WRF-Hydro\"\n type: doi\n value: 10.5281/zenodo.4479912\n - description: \"This is the archived snapshot of version v5.1.2 of WRF-Hydro\"\n type: doi\n value: 10.5281/zenodo.3678643\n - description: \"This is the archived snapshot of version v5.1.1 of WRF-Hydro\"\n type: doi\n value: 10.5281/zenodo.3625238\nmessage: \"Please cite this software using the metadata from this file.\"\n" }, { "path": "CMakeLists.txt", "content": "cmake_minimum_required (VERSION 3.12)\ncmake_policy(SET CMP0074 NEW) # use xxxx_ROOT env vars\nif (NOT CMAKE_BUILD_TYPE)\n set(CMAKE_BUILD_TYPE \"Release\")\nendif()\n\n\n# set project name and version numbers\nproject (WRF_Hydro LANGUAGES Fortran C)\nset (WRF_Hydro_VERSION_MAJOR 5)\nset (WRF_Hydro_VERSION_MINOR 4)\nset (WRF_Hydro_VERSION_PATCH 0)\nset (National_Water_Model_VERSION_MAJOR 3)\nset (National_Water_Model_VERSION_MINOR 1)\nset (National_Water_Model_VERSION_PATCH beta)\n\n# set cmake to work with MPI Fortran\nfind_package(MPI REQUIRED)\nadd_compile_options(${MPI_Fortran_COMPILE_FLAGS})\ninclude_directories(${MPI_Fortran_INCLUDE_PATH})\nlink_directories(${MPI_Fortran_LIBRARIES})\nset(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)\nset(CMAKE_SKIP_BUILD_RPATH FALSE)\nset(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)\n\n# enable ctests\nenable_testing()\n\n#message(\"-- MPI Include directories: \" ${MPI_INCLUDE_PATH} )\n#message(\"-- MPI C COMPILER : \" ${MPI_C_COMPILER} )\n#message(\"-- MPI CXX COMPILER : \" ${MPI_CXX_COMPILER} )\n#message(\"-- MPI Fortran COMPILER : \" ${MPI_Fortran_COMPILER} )\n#message(\"-- MPI COMPILE FLAGS : \" ${MPI_COMPILE_FLAGS} )\n#message(\"-- MPI LINK FLAGS : \" ${MPI_LINK_FLAGS} )\n#message(\"-- MPI Fortran LINK FLAGS : \" ${MPI_Fortran_LINK_FLAGS} )\n#message(\"-- MPI Fortran LINK LIBRARIES : \" ${MPI_Fortran_LIBRARIES} )\n#message(\"-- MPI LIBRARY : \" ${MPI_LIBRARY} )\n#message(\"-- MPI EXTRA LIBRARY : \" ${MPI_EXTRA_LIBRARY} )\n#message(\"-- MPI LIBRARIES : \" ${MPI_LIBRARIES} )\n\n# netcdf does not have a built in package locator so add custom module directory\n# that contains FindNetCDF.cmake\nset(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/src/cmake-modules)\n\n# try to find the installed NETCDF library\nif (NOT TARGET netCDF::netcdff AND TARGET NetCDF::NetCDF_Fortran)\n add_library(netCDF::netcdff ALIAS NetCDF::NetCDF_Fortran)\nendif()\n\nif (NOT TARGET netCDF::netcdff)\n set(NETCDF_F90 \"YES\")\n set(NETCDF_F77 \"YES\")\n find_package(NetCDF REQUIRED)\n message(\"-- NetCDF Include Dir(s): ${NETCDF_INCLUDES_F77} ${NETCDF_INCLUDES_F90}\")\nendif()\n\n# set user controled enviorment variables\nset(HYDRO_LSM $ENV{HYDRO_LSM} CACHE STRING \"Name of the Land Surface Model to Use\")\n\n# set enviorment variables if they have not been set\nif (\"${HYDRO_LSM}\" STREQUAL \"\")\n set(HYDRO_LSM \"NoahMP\")\n message(\"-- Setting LSM to: NoahMP\")\nendif()\n\n# get the variables defined by setEnvar.sh\nset(WRF_HYDRO $ENV{WRF_HYDRO} CACHE STRING \"WRF environment variable. Always set to 1 for WRF-Hydro\")\nset(HYDRO_D $ENV{HYDRO_D} CACHE STRING \"Print additional debug information in WRF-Hydro\")\nset(WRF_HYDRO_RAPID $ENV{WRF_HYDRO_RAPID} CACHE STRING \"WRF-Hydro coupling to RAPID routing model 0=off 1=on\")\nset(SPATIAL_SOIL $ENV{SPATIAL_SOIL} CACHE STRING \"Spatially distributed soil parameters for NoahMP 0=off 1=on\")\nset(WRFIO_NCD_LARGE_FILE_SUPPORT $ENV{WRFIO_NCD_LARGE_FILE_SUPPORT} CACHE STRING \"Large netCDF file support 0=off, 1=on\")\nset(NCEP_WCOSS $ENV{NCEP_WCOSS} CACHE STRING \"WCOSS file units 0=off 1=on\")\nset(NWM_META $ENV{NWM_META} CACHE STRING \"NWM output metadata 0=off 1=on\")\nset(WRF_HYDRO_NUDGING $ENV{WRF_HYDRO_NUDGING} CACHE STRING \"Streamflow nudging 0=off 1=on\")\nset(OUTPUT_CHAN_CONN $ENV{OUTPUT_CHAN_CONN} CACHE STRING \"Output channel connections\")\nset(PRECIP_DOUBLE $ENV{PRECIP_DOUBLE} CACHE STRING \"Precipitation as double\")\nset(WRF_HYDRO_NUOPC $ENV{WRF_HYDRO_NUOPC} CACHE STRING \"NUOPC library 0=off 1=on\")\n\n#set default values for env variables\nif (WRF_HYDRO STREQUAL \"\")\n set(WRF_HYDRO \"1\" CACHE STRING \"WRF environment variable. Always set to 1 for WRF-Hydro\" FORCE)\nendif()\n\nif (HYDRO_D STREQUAL \"\")\n if (CMAKE_BUILD_TYPE STREQUAL \"Debug\")\n set(HYDRO_D \"1\" CACHE STRING \"Print additonal debug information in WRF-Hydro\" FORCE)\n else()\n set(HYDRO_D \"0\" CACHE STRING \"Print additonal debug information in WRF-Hydro\" FORCE)\n endif()\nendif()\n\nif (WRF_HYDRO_RAPID STREQUAL \"\")\n set(WRF_HYDRO_RAPID \"0\" CACHE STRING \"WRF-Hydro coupling to RAPID routing model 0=off 1=on\" FORCE)\nendif()\n\nif (SPATIAL_SOIL STREQUAL \"\")\n set(SPATIAL_SOIL \"0\" CACHE STRING \"Spatially distributed soil parameters for NoahMP 0=off 1=on\" FORCE)\nendif()\n\nif (WRFIO_NCD_LARGE_FILE_SUPPORT STREQUAL \"\")\n set(WRFIO_NCD_LARGE_FILE_SUPPORT \"0\" CACHE STRING \"Large netCDF file support 0=off, 1=on\" FORCE)\nendif()\n\nif (NCEP_WCOSS STREQUAL \"\")\n set(NCEP_WCOSS \"0\" CACHE STRING \"WCOSS file units 0=off, 1=on\" FORCE)\nendif()\n\nif (NWM_META STREQUAL \"\")\n set(NWM_META \"0\" CACHE STRING \"NWM output metadata 0=off, 1=on\" FORCE)\nendif()\n\nif (WRF_HYDRO_NUDGING STREQUAL \"\")\n set(WRF_HYDRO_NUDGING \"0\" CACHE STRING \"Streamflow nudging 0=off, 1=on\" FORCE)\nendif()\n\nif (OUTPUT_CHAN_CONN STREQUAL \"\")\n set(OUTPUT_CHAN_CONN \"0\" CACHE STRING \"Output channel connections\" FORCE)\nendif()\n\nif (PRECIP_DOUBLE STREQUAL \"\")\n set(PRECIP_DOUBLE \"0\" CACHE STRING \"Precipitation as double\" FORCE)\nendif()\n\nif (WRF_HYDRO_NUOPC STREQUAL \"\")\n set(WRF_HYDRO_NUOPC \"0\" CACHE STRING \"NUOPC library 0=off, 1=on\" FORCE)\nendif()\n\n# add preprocessor defines using env variables\n\nmessage(\"=============================================================\")\nmessage(\"-- Start of WRF-Hydro Env VARIABLES\" )\n\n#always use -DMPP_LAND\nadd_definitions(-DMPP_LAND)\n\n# set -DWRF_HYDRO from env\nmessage(\"WRF_HYDRO = \" ${WRF_HYDRO} )\nif (WRF_HYDRO STREQUAL \"1\" )\n add_definitions(-DWRF_HYDRO)\nendif()\n\n#set -DHYDRO_D from env\nmessage(\"HYDRO_D = \" ${HYDRO_D} )\nif (HYDRO_D STREQUAL \"1\" )\n add_definitions(-DHYDRO_D)\nendif()\n\n# set -DWRF_HYDRO_RAPID from env\nif (WRF_HYDRO_RAPID STREQUAL \"1\" )\n message(\"WRF_HYDRO_RAPID = \" ${WRF_HYDRO_RAPID} )\n add_definitions(-DWRF_HYDRO_RAPID)\nendif()\n\n#set -DSPATIAL_SOIL from env\nmessage(\"SPATIAL_SOIL = \" ${SPATIAL_SOIL} )\nif (SPATIAL_SOIL STREQUAL \"1\" )\n add_definitions(-DSPATIAL_SOIL)\nendif()\n\n#set -DWRFIO_NCD_LARGE_FILE_SUPPORT from env\nmessage(\"WRFIO_NCD_LARGE_FILE_SUPPORT = \" ${WRFIO_NCD_LARGE_FILE_SUPPORT} )\nif(WRFIO_NCD_LARGE_FILE_SUPPORT STREQUAL \"1\" )\n add_definitions(-DWRFIO_NCD_LARGE_FILE_SUPPORT)\nendif()\n\n#set -DNCEP_WCOSS from env\nmessage(\"NCEP_WCOSS = \" ${NCEP_WCOSS} )\nif (NCEP_WCOSS STREQUAL \"1\" )\n add_definitions(-DNCEP_WCOSS)\nendif()\n\n#set -DNWM_META from env\nmessage(\"NWM_META = \" ${NWM_META} )\nif (NWM_META STREQUAL \"1\" )\n add_definitions(-DNWM_META)\nendif()\n\n#set -DWRF_HYDRO_NUDGING from env\nmessage(\"WRF_HYDRO_NUDGING = \" ${WRF_HYDRO_NUDGING} )\nif (WRF_HYDRO_NUDGING STREQUAL \"1\" )\n add_definitions(-DWRF_HYDRO_NUDGING)\nendif()\n\n#set -DOUTPUT_CHAN_CONN from env\nif (OUTPUT_CHAN_CONN STREQUAL \"1\" )\n message(\"OUTPUT_CHAN_CONN = \" ${OUTPUT_CHAN_CONN} )\n add_definitions(-DOUTPUT_CHAN_CONN)\n # requires nudging io module\n set(WRF_HYDRO_NUDGING_IO \"1\")\nendif()\n\n#set -DPRECIP_DOUBLE from env\nmessage(\"PRECIP_DOUBLE = \" ${PRECIP_DOUBLE} )\nif (PRECIP_DOUBLE STREQUAL \"1\" )\n add_definitions(-DPRECIP_DOUBLE)\nendif()\n\n#set -DWRF_HYDRO_NUOPC from env\nmessage(\"WRF_HYDRO_NUOPC = \" ${WRF_HYDRO_NUOPC} )\nif (WRF_HYDRO_NUOPC STREQUAL \"1\" )\n add_definitions(-DWRF_HYDRO_NUOPC)\nendif()\n\noption(BUILD_CROCUS \"Build Crocus\" ON)\noption(WRF_HYDRO_CREATE_EXE_SYMLINK \"Create symlink wrfhydro.exe -> wrfhydro\" ON)\nmessage(\"WRF_HYDRO_CREATE_EXE_SYMLINK = \" ${WRF_HYDRO_CREATE_EXE_SYMLINK} )\n\nmessage(\"=============================================================\")\n\n#set compile flags based on compiler id\nif (CMAKE_Fortran_COMPILER_ID MATCHES \"GNU.*\")\n # set compile flags for gfortran\n message( \"-- Using gfortran\")\n set(CMAKE_Fortran_FLAGS \"-cpp -w -ffree-form -ffree-line-length-none -fconvert=big-endian -frecord-marker=4\")\n if (CMAKE_Fortran_COMPILER_VERSION VERSION_GREATER_EQUAL 9)\n set(CMAKE_Fortran_FLAGS \"${CMAKE_Fortran_FLAGS} -fallow-argument-mismatch\")\n endif()\n set(CMAKE_Fortran_FLAGS_RELEASE \"-O2\")\n set(CMAKE_Fortran_FLAGS_DEBUG \"-O0 -g -fbacktrace\")\nelseif (CMAKE_Fortran_COMPILER_ID MATCHES \"Intel.*\")\n # set compile flags for ifort\n message( \"-- Using ifort\")\n set(CMAKE_Fortran_FLAGS \"-fpp -w -ftz -align all -fno-alias -fp-model precise -FR -convert big_endian\")\n set(CMAKE_Fortran_FLAGS_RELEASE \"-O2 -march=core-avx2\")\n set(CMAKE_Fortran_FLAGS_DEBUG \"-O0 -g -traceback\")\nelseif ((CMAKE_Fortran_COMPILER_ID MATCHES \"PGI.*\") OR (CMAKE_Fortran_COMPILER_ID MATCHES \"NVHPC.*\"))\n message(\"-- Using NVHPC / PGI\")\n set(CMAKE_Fortran_FLAGS \"-Mpreprocess -Mfree -byteswapio -Kieee \")\n set(CMAKE_Fortran_FLAGS_RELEASE \"-O2\")\n set(CMAKE_Fortran_FLAGS_DEBUG \"-O0 -g -traceback\")\nelseif ((CMAKE_Fortran_COMPILER_ID MATCHES \"Cray*\"))\n message(\"-- Using Cray\")\n set(CMAKE_Fortran_FLAGS \"-eZ -ffree -ef -h alias=none -h fp1 -hbyteswapio\")\n set(CMAKE_Fortran_FLAGS_RELEASE \"-O3 -G2\")\n set(CMAKE_Fortran_FLAGS_DEBUG \"-O0 -G0\") # -traceback\")\nelse()\n message(\"CMAKE_Fortran_COMPILER full path: \" ${CMAKE_Fortran_COMPILER})\n message(\"Fortran compiler: \" ${Fortran_COMPILER_NAME})\n message(\"No optimized Fortran compiler flags are known, we just try -O2...\")\n set(CMAKE_Fortran_FLAGS \"-cpp\")\n set(CMAKE_Fortran_FLAGS_RELEASE \"-O2\")\n set(CMAKE_Fortran_FLAGS_DEBUG \"-O0 -g\")\nendif()\nmessage(\"-- CMAKE_Fortran_COMPILER full path: \" ${CMAKE_Fortran_COMPILER})\n\n#set output directories for libraries binaries and fortran .mod files\nset(CMAKE_BINARY_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/bin)\nset(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/lib)\nset(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/lib)\nset(CMAKE_Fortran_MODULE_DIRECTORY ${PROJECT_BINARY_DIR}/mods)\n\n#add common include directores need in the build\ninclude_directories(AFTER ${PROJECT_BINARY_DIR}/mods)\ninclude_directories(AFTER ${MPI_INCLUDE_PATH})\n# include_directories(AFTER ${NETCDF_INCLUDES}) # NOTE: We don't need the C include for netCDF\ninclude_directories(AFTER ${NETCDF_INCLUDES_F77})\ninclude_directories(AFTER ${NETCDF_INCLUDES_F90})\ninclude_directories(AFTER ${PROJECT_SOURCE_DIR}/src/Data_Rec)\n\nadd_subdirectory(\"src\")\nadd_subdirectory(\"tests/ctests\")\n" }, { "path": "CODE_OF_CONDUCT.md", "content": "# Contributor Code of Conduct\n\n## Our Pledge\nWe, as contributors, creators, stewards, and maintainers of WRF-Hydro® pledge to make participation in our software, system or hardware project and community a safe, productive, welcoming and inclusive experience for everyone. All participants are required to abide by this Code of Conduct. This includes respectful treatment of everyone regardless of age, body size, disability, ethnicity, gender identity or expression, level of experience, nationality, political affiliation, veteran status, pregnancy, genetic information, physical appearance, race, religion, or sexual orientation, as well as any other characteristic protected under applicable US federal or state law.\n\n## Our Standards \nExamples of behavior that contribute to creating a positive environment include:\n* All participants are treated with respect and consideration, valuing a diversity of views and opinions\n* Be considerate, respectful, and collaborative\n* Communicate openly with respect for others, critiquing ideas rather than individuals and gracefully accepting criticism\n* Acknowledging the contributions of others\n* Avoid personal attacks directed toward other participants\n* Be mindful of your surroundings and of your fellow participants\n* Alert UCAR staff and suppliers/vendors if you notice a dangerous situation or someone in distress\n* Respect the rules and policies of the project and venue\n\nExamples of unacceptable behavior by participants include:\n* Harassment, intimidation, or discrimination in any form\n* Physical, verbal, or written abuse by anyone to anyone, including repeated use of pronouns other than those requested\n* Unwelcome sexual attention or advances\n* Personal attacks directed at other guests, members, participants, etc.\n* Publishing others' private information such as a physical or electronic address, without explicit permission\n* Alarming, intimidating, threatening, or hostile comments or conduct\n* Inappropriate use of nudity and/or sexual images\n* Threatening or stalking anyone, including a participant\n* Other conduct which could reasonably be considered inappropriate in a professional setting\n\n## Scope\nThis Code of Conduct applies to all spaces managed by the project whether they be physical, online or face-to-face. This includes project code, code repository, associated web pages, documentation, mailing lists, project websites and wiki pages, issue tracker, meetings, telecon, events, project social media accounts, and any other forums created by the project team which the community uses for communication. In addition, violations of this Code of Conduct outside these spaces may affect a person's ability to participate within them. Representation of a project may be further defined and clarified by project maintainers.\n\n## Community Responsibilities\nEveryone in the community is empowered to respond to people who are showing unacceptable behavior. They can talk to them privately or publicly. Anyone requested to stop unacceptable behavior is expected to comply immediately. If the behavior continues concerns may be brought to the project administrators or to any other party listed in the *Reporting* section below.\n\n## Project Administrator Responsibilities\nProject administrators are responsible for clarifying the standards of acceptable behavior and are encouraged to model appropriate behavior and provide support when people in the community point out inappropriate behavior. Project administrator(s) are normally the ones that would be tasked to carry out the actions in the *Consequences* section below.\n\nProject administrators are also expected to keep this *Code of Conduct* updated with the main one housed at UCAR as listed below in the *Attribution* section.\n\n## Reporting\nInstances of unacceptable behavior can be brought to the attention of the [project administrator(s)](https://ral.ucar.edu/projects/wrf_hydro/team) who may take any action as outlined in the *Consequences* section below. However, making a report to a project administrator is not considered an 'official report' to UCAR.\n\nInstances of unacceptable behavior may also be reported directly to UCAR via [UCAR's Harassment Reporting and Complaint Procedure](https://operations.ucar.edu/procedures/hr/harassment-reporting-and-complaint-procedure) or anonymously through [UCAR's EthicsPoint Hotline](https://www.ucar.edu/who-we-are/ethics). \n\nComplaints received by UCAR will be handled pursuant to the procedures outlined in UCAR's Harassment Reporting and Complaint Procedure. Complaints to UCAR will be held as confidential as practicable under the circumstances, and retaliation against a person who initiates a complaint or an inquiry about inappropriate behavior will not be tolerated.\n\nAny contributor can use these reporting methods even if they are not directly affiliated with UCAR. For more information, view the [Frequently Asked Questions (FAQ)](https://operations.ucar.edu/procedures/hr/reporting-faqs) page for reporting.\n\n## Consequences\nUpon receipt of a complaint, the project administrator(s) may take any action deemed necessary and appropriate under the circumstances. Such action can include things such as: removing, editing, or rejecting comments, commits, code, wiki edits, email, issues, and other contributions that are not aligned to this Code of Conduct, or banning temporarily or permanently any contributor for other behaviors that are deemed inappropriate, threatening, offensive, or harmful. Project administrators also have the right to report violations to UCAR HR and/or UCAR's Office of Diversity, Equity, and Inclusion (ODEI) as well as a participant's home institution and/or law enforcement. In the event an incident is reported to UCAR, UCAR will follow its [Harassment Reporting and Complaint Procedure](https://operations.ucar.edu/procedures/hr/harassment-reporting-and-complaint-procedure).\n\n## Process for Changes\nAll UCAR-managed projects are required to adopt this Contributor Code of Conduct. Adoption is assumed even if not expressly stated in the repository. Projects should fill in sections where prompted with project-specific information, including, project name, email addresses, adoption date, etc. There is one section below marked \"optional\", which may not apply to a given project.\n\nProjects that adopt this Code of Conduct need to stay up to date with UCAR's Contributor Code of Conduct, linked in the *Attribution* section below. Projects can make limited substantive changes to the Code of Conduct; however, the changes must be limited in scope and may not contradict the UCAR Contributor Code of Conduct.\n\n## Attribution\nThis Code of Conduct was originally adapted from the Contributor Covenant, version 1.4.1. We then aligned it with the UCAR Participant Code of Conduct, which also borrows from the American Geophysical Union (AGU) Code of Conduct. The UCAR Participant Code of Conduct applies to both UCAR employees, as well as participants in activities run by UCAR. We modified the Scope section with the Django Project description. The original version of this for all software projects that have strong management from UCAR or UCAR staff is available on the UCAR website at https://www.ucar.edu/who-we-are/ethics-integrity/codes-conduct/contributors (the date that it was adopted by this project was 10 July 2019). When responding to complaints, UCAR HR and ODEI will do so based on the latest published version. Therefore, any project-specific changes should follow the Process for Changes section above.\n" }, { "path": "LICENSE.txt", "content": "USE OF THIS SOFTWARE IS SUBJECT TO THE FOLLOWING TERMS AND CONDITIONS:\n\n1. License. Subject to these terms and conditions, University Corporation for Atmospheric Research (UCAR)\ngrants you a non-exclusive, royalty-free license to use, create derivative works, publish, distribute,\ndisseminate, transfer, modify, revise and copy the WRF-Hydro® software, in both object and source code\n(the \"Software\"). You shall not sell, license or transfer for a fee the Software, or any work that in any\nmanner contains the Software.\n\n2. Disclaimer of Warranty on Software. Use of the Software is at your sole risk. The Software is provided\n\"AS IS\" and without warranty of any kind and UCAR EXPRESSLY DISCLAIMS ALL WARRANTIES AND/OR CONDITIONS OF\nANY KIND, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTIES OR CONDITIONS OF TITLE,\nNON-INFRINGEMENT OF A THIRD PARTY?S INTELLECTUAL PROPERTY, MERCHANTABILITY OR SATISFACTORY QUALITY AND\nFITNESS FOR A PARTICULAR PURPOSE. THE PARTIES EXPRESSLY DISCLAIM THAT THE UNIFORM COMPUTER INFORMATION\nTRANSACTIONS ACT (UCITA) APPLIES TO OR GOVERNS THIS AGREEMENT. No oral or written information or advice\ngiven by UCAR or a UCAR authorized representative shall create a warranty or in any way increase the scope\nof this warranty. Should the Software prove defective, you (and neither UCAR nor any UCAR representative)\nassume the cost of all necessary correction.\n\n3. Limitation of Liability. UNDER NO CIRCUMSTANCES, INCLUDING NEGLIGENCE, SHALL UCAR BE LIABLE FOR ANY\nDIRECT, INCIDENTAL, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES INCLUDING LOST REVENUE, PROFIT OR DATA,\nWHETHER IN AN ACTION IN CONTRACT OR TORT ARISING OUT OF OR RELATING TO THE USE OF OR INABILITY TO USE THE\nSOFTWARE, EVEN IF UCAR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.\n\n4. Compliance with Law. All Software and any technical data delivered under this Agreement are subject to\nU.S. export control laws and may be subject to export or import regulations in other countries. You agree\nto comply strictly with all applicable laws and regulations in connection with use and distribution of the\nSoftware, including export control laws, and you acknowledge that you have responsibility to obtain any\nrequired license to export, re-export, or import as may be required.\n\n5. No Endorsement/No Support. The names UCAR/NCAR, National Center for Atmospheric Research and the\nUniversity Corporation for Atmospheric Research may not be used in any advertising or publicity to endorse\nor promote any products or commercial entity unless specific written permission is obtained from UCAR. The\nSoftware is provided without any support or maintenance, and without any obligation to provide you with\nmodifications, improvements, enhancements, or updates of the Software.\n\n6. Controlling Law and Severability. This Agreement shall be governed by the laws of the United States and the\nState of Colorado. If for any reason a court of competent jurisdiction finds any provision, or portion\nthereof, to be unenforceable, the remainder of this Agreement shall continue in full force and effect. This\nAgreement shall not be governed by the United Nations Convention on Contracts for the International Sale of\nGoods, the application of which is hereby expressly excluded.\n\n7. Termination. Your rights under this Agreement will terminate automatically without notice from UCAR if you\nfail to comply with any term(s) of this Agreement. You may terminate this Agreement at any time by destroying\nthe Software and any related documentation and any complete or partial copies thereof. Upon termination, all\nrights granted under this Agreement shall terminate. The following provisions shall survive termination:\nSections 2, 3, 6 and 9.\n\n8. Complete Agreement. This Agreement constitutes the entire agreement between the parties with respect to the\nuse of the Software and supersedes all prior or contemporaneous understandings regarding such subject matter. \nNo amendment to or modification of this Agreement will be binding unless in a writing and signed by UCAR.\n\n9. Notices and Additional Terms. Copyright in Software is held by UCAR. You must include, with each copy of the\nSoftware and associated documentation, a copy of this Agreement and the following notice: \n\n\"The source of this material is the Research Applications Laboratory at the National Center for Atmospheric\nResearch, a program of the University Corporation for Atmospheric Research (UCAR) pursuant to a Cooperative\nAgreement with the National Science Foundation; ©2007 University Corporation for Atmospheric Research. All\nRights Reserved.\" \n\nThe following notice shall be displayed on any scholarly works associated with, related to or derived from\nthe Software: \n\n\"The WRF-Hydro modeling system was developed at the National Center for Atmospheric Research (NCAR) through\ngrants from the National Aeronautics and Space Administration (NASA) and the National Oceanic and Atmospheric\nAdministration (NOAA). NCAR is sponsored by the United States National Science Foundation.\"\n\nBY USING OR DOWNLOADING THIS SOFTWARE, YOU AGREE TO BE BOUND BY THE TERMS AND CONDITIONS OF THIS AGREEMENT.\n" }, { "path": "NEWS.md", "content": "# WRF-Hydro® v5.4.0 Release Notes\n\nPlease note that starting with WRF-Hydro v5.4, CMake is the preferred\nbuild system. The legacy configure/compile scripts are still present,\nbut should be considered deprecated and will not be supported in\nfuture releases.\n\nWRF-Hydro model documentation has been migrated from individual Word and\nPDF files to an online documentation system that will be hosted alongside\nthe model code in the GitHub repository. Please see the docs/ directory for\nmore details and view the documentation on the web at:\n\nhttps://wrf-hydro.readthedocs.io/en/latest\n\nFor specific updates, reference the PRs listed in the following sections:\n\n## Model Improvements\n - PR#756: Add initial support for gage-assisted diversions in channel\n routing, which requires a new optional Diversion netCDF parameter file.\n This also adds a C compiler dependency\n - PR#725: `lake_option` added to `&hydro_namelist` to override lake physics\n options (or turn off lakes completely). Reservoir options have been moved\n to a new, separate `&reservoir_nlist` namelist\n - PR#743: liquid water fraction (or snow) added as optional forcing input variables\n Forcing variables names can now be supplied as namelist inputs\n - PR#782: documentation converted to readthedocs, also PR#786, PR#785,\n PR#774, PR#789, PR#795, PR#796, PR#792, PR#799, PR#798, PR#791, PR#799,\n PR#798, PR#797, PR#805, PR#804, PR#809, PR#810\n\n## Bugfixes:\n - PR#803, PR#808: `lake_option` bugfixes\n - PR#813: Finding NetCDF fix for new Derecho environment\n - PR#811: Adding routing diversion Makefiles\n - PR#785: Support Fedora MPI environmental variables for NetCDF\n - PR#752: LSM accumulations not reset if `RSTRT_SWC` equals `no reset`\n - PR#729: Crocus glacier arrays changed to `optional` from `allocatable`\n - Bugfixes: CMake nudging parallel build\n\n## General cleanup and misc.\n - PR#802: increment version numbers\n - PR#794: input namelists and parametere tables\n - PR#790: PR template updates\n - PR#764: adding deprecation warning to configure build, CMake preferred\n - PR#739: general CMake improvements, tabs to spaces\n - PR#720: header info from files removed\n - PR#724: redundant return statements removed\n - PR#723: MPI case style fixed\n - PR#733: .F -> .F90 file renaming\n - PR#717: Added citation file" }, { "path": "docs/BUILD.rst", "content": "Build\n===========\n\n\nRequirements\n~~~~~~~~~~~~\n\n+------------+---------+\n|Compiler | Version |\n+============+=========+\n| GNU | 11+ |\n+------------+---------+\n| Intel | 2023+ |\n+------------+---------+\n| NVidia | 23+ |\n+------------+---------+\n| Cray | 15+ |\n+------------+---------+\n\n+--------------------+---------+\n| Libraries/Software | Version |\n+====================+=========+\n| MPI | 3.x+ |\n+--------------------+---------+\n| Fortran NetCDF | 4.4+ |\n+--------------------+---------+\n| CMake | 3.12+ |\n+--------------------+---------+\n\nNote: Supported compiler versions are chosen based on long-term support (LTS) status, ensuring they continue to receive security and bug fixes.\n\nInstall dependencies for Debain/Ubuntu\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n.. code-block:: bash\n\n $ apt install -y git cmake libnetcdff-dev mpi-default-dev\n\n\nInstall/activate dependencies for Red Hat/Fedora\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n.. code-block:: bash\n\n $ dnf install -y git cmake netcdf-fortran-mpich-devel\n \n $ module load mpi\n\n\nCMake Build\n~~~~~~~~~~~\n\n.. code-block:: bash\n\n $ mkdir build\n $ cd build\n $ cmake ..\n $ make -j 4\n\nThe executables, namelists and tables are now in the ``build/Run`` directory.\nTestcases with domain setups can be found `here `_.\nTo build with additional functionality, enter ``cmake .. -DFOO=1`` where the\navailable options are described in the following table.\n\n+------------------------------------+-------------------------------------------------------------------------------+\n| CMake WRF-Hydro Specific Options | Functionality |\n+====================================+===============================================================================+\n| ``-DWRF_HYDRO=1`` | Default: turn on WRF-Hydro |\n+------------------------------------+-------------------------------------------------------------------------------+\n| ``-DHYDRO_D=1`` | Enhanced diagnostic output for debugging |\n+------------------------------------+-------------------------------------------------------------------------------+\n| ``-DSPATIAL_SOIL=1`` | Spatially distributed parameters for NoahMP |\n+------------------------------------+-------------------------------------------------------------------------------+\n| ``-DWRF_HYDRO_NUDGING=1`` | Enable the streamflow nudging routines for Muskingum-Cunge Routing |\n+------------------------------------+-------------------------------------------------------------------------------+\n| ``-DNWM_META=1`` | Output NWM Metadata |\n+------------------------------------+-------------------------------------------------------------------------------+\n| ``-DPRECIP_DOUBLE=1`` | Double precipitation from hydro forcing |\n+------------------------------------+-------------------------------------------------------------------------------+\n| ``-DNCEP_WCOSS=1`` | Do not use unless working on the WCOSS machines |\n+------------------------------------+-------------------------------------------------------------------------------+\n\n+------------------------------------+-------------------------------------------------------------------------------+\n| Unsupported Functionality | |\n+====================================+===============================================================================+\n| ``-DWRF_HYDRO_NUOPC=1`` | Coupling with NUOPC, this option is not currently supported |\n+------------------------------------+-------------------------------------------------------------------------------+\n\n\nCMake Testcase\n~~~~~~~~~~~~~~\n\nTo download and setup the Croton testcase in ``build/Run`` use one of the\nfollowing commands.\nThe first time the ``croton.tar.gz`` file will be downloaded, extracted, and configured.\nFuture commands will reconfigure the ``Run`` directory.\n\n+---------------------------------+\n| Make Command |\n+=================================+\n| make croton |\n+---------------------------------+\n| make croton-gridded |\n+---------------------------------+\n| make croton-gridded-no-lakes |\n+---------------------------------+\n| make croton-nwm |\n+---------------------------------+\n| make croton-nwm_ana |\n+---------------------------------+\n| make croton-nwm_longe_range |\n+---------------------------------+\n| make croton-reach |\n+---------------------------------+\n| make croton-reach-lakes |\n+---------------------------------+\n" }, { "path": "docs/Makefile", "content": "SOURCEDIR = userguide/\nBUILDDIR = _build/html\n\n# List all source files to track dependencies\nSOURCE_FILES = $(shell find . -name '*.rst' -o -name '*.rest' -o -name '*.py' -o -name '*.css')\n\nall: build\n\nbuild: $(BUILDDIR)/index.html\n\n$(BUILDDIR)/index.html: $(SOURCE_FILES)\n\t@echo \"Building readthedocs documentation\"\n\tsphinx-build -b html $(SOURCEDIR) $(BUILDDIR)\n\t@echo \"Open $(BUILDDIR)/index.html to preview readthedocs documentation\"\n\nopen: build\n\topen $(BUILDDIR)/index.html\n\nclean:\n\trm -rf _build\n" }, { "path": "docs/requirements.txt", "content": "sphinx_rtd_theme\n" }, { "path": "docs/userguide/_static/ug_theme.css", "content": ".wy-nav-content {\n max-width: 1000px !important;\n}\n\n.center {\n text-align: center;\n}\n\n.underline {\n text-decoration: underline;\n}\n\n.filename {\n font-family: Courier, \"Courier New\", monospace;\n white-space: pre-wrap;\n}\n\n.program {\n font-family: Courier, \"Courier New\", monospace;\n white-space: pre-wrap;\n color: greenyellow;\n background-color: black;\n padding-left: 5px;\n padding-right: 5px;\n}\n\n.wy-table-responsive table td, .wy-table-responsive table th {\n white-space: normal;\n}" }, { "path": "docs/userguide/appendices.rest", "content": ".. vim: syntax=rst\n.. include:: meta.rest\n.. role:: raw-html(raw)\n :format: html\n\nAPPENDICES\n==========\n\nThis section contains supplementary information.\n\n.. _section-a1:\n\nA1. Standalone (Uncoupled) WRF-Hydro Test Case User Guide\n---------------------------------------------------------\n\nPurpose\n^^^^^^^\n\nThis example test case is meant to orient you to running the\nWRF-Hydro modelling system using prepared geographical inputs, and\nprepared forcing data for a specific region (domain). We provide\nbaseline instructions to test that your WRF-Hydro executable was\ncompiled correctly and is able to run on your system. Please see the\nReadme.txt file provided with the test case for specific file\ndescriptions and a regional description.\n\nThis test case provides example namelists and prepared geographical\ninput files for three routing configurations. While the step-by-step\nwalkthrough instructions here guide you through running the Gridded\nconfiguration we suggest that you explore the other routing\nconfigurations and related namelists for reference.\n\nFor further information on the WRF-Hydro modeling system and possible\ntraining opportunities, please visit https://ral.ucar.edu/projects/wrf_hydro.\n\nRequirements\n^^^^^^^^^^^^\n\n- WRF-Hydro source code:\n - https://github.com/NCAR/wrf_hydro_nwm_public.git\n - ``git clone`` into directory where you will be running this case\n\n- An official WRF-Hydro example test case:\n - Download from: https://ral.ucar.edu/projects/wrf_hydro/testcases\n - or from release assets at: https://github.com/NCAR/wrf_hydro_nwm_public/releases\n\n- All system libraries needed by the WRF-Hydro modeling system can be found\n in the :ref:`build instructions `.\n\nStep-by-step walkthrough\n^^^^^^^^^^^^^^^^^^^^^^^^\n**Directory structure setup**:\n\nWe will organize all files and folders under a common top-level\ndirectory to simplify commands in this walkthrough. All paths mentioned\nin this walkthrough will be relative to this top-level directory. For\nexample, :file:`/home/user/project_directory/example_case/` will be referred to\nas :file:`example_case/`.\n\n#. Open a terminal window\n\n#. Create a top-level directory that will hold all subdirectories and\n files used for this walkthrough. Hereafter referred to as the\n ‘project directory’.\n\n#. Copy the uncompressed WRF-Hydro source code into the project\n directory created in step 2.\n\n#. Copy the example case directory into\n the project directory as well.\n\n#. An example of your project directory structure using the Croton, NY\n example test case would look like the following:\n\n.. code-block:: console\n\n project_directory/\n ├──wrf_hydro_nwm_public/\n | ├──src/\n |\n ├──example_case/\n ├──Gridded_no_lakes/\n ├──Gridded/\n ├──NWM/\n ├──Reach/\n ├──ReachLakes/\n ├──FORCING/\n ├──supplemental/\n ├──Readme.txt\n\nCompiling the Code\n^^^^^^^^^^^^^^^^^^\n\nIf you have not built WRF-Hydro before on your current system, please follow the\ninstructions in the :ref:`build instructions ` to ensure you have all\nthe necessary library dependencies available. If you have already built WRF-Hydro,\nyou can skip to step \"CMake Build\", repeated here:\n\n.. code-block:: bash\n\n $ cd project_directory/wrf_hydro_nwm_public # project_directory/ from above\n $ mkdir build\n $ cd build\n $ cmake -DHYDRO_D=1 [-DWRF_HYDRO_NUDGING=1] .. # include -DWRF_HYDRO_NUDGING=1 if you want to use the NWM test case\n $ make -j 4\n\nThe executables, namelists and tables will be created in the ``build/Run`` directory.\n\nRunning a WRF-Hydro Simulation\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nIn this section we will use our compiled WRF-Hydro model and an\nexample test case to run a WRF-Hydro simulation. This walkthrough is\nusing the Croton, NY example test case. After extracting the Croton tarball\ndetails on the domain and time period of the simulation are provided in the\n:file:`example_case/Readme.txt` file.\n\n1. First we need to copy the TBL and executable files in the\n :file:`wrf_hydro_nwm_public*/src/build/Run`\n directory to the directory\n containing the domain and forcing files. For the WRF-Hydro Gridded\n configuration, these files are located in the directory\n :file:`example_case/Gridded`.\n\n Copy the :file:`*.TBL` files to the example configuration directory:\n\n | *(from your project directory)*\n | :code:`cp wrf_hydro_nwm_public*/build/Run/\\*.TBL example_case/Gridded`\n\n Copy the :file:`wrf_hydro` file:\n\n :code:`cp wrf_hydro_nwm_public*/build/Run/wrf_hydro example_case/Gridded`\n\n .. note:: There are other configuration subfolders with the names such as :file:`Gridded`, :file:`nwm`, and\n :file:`Reach`. These folders contain prepared files for other configurations of WRF-Hydro. They are found\n under the :file:`src/template/` directory. Information\n regarding physics options and routing configurations can be found in the main body of the *WRF-Hydro*\n v\\ |version_short| *Technical Description*. Also, note that there is only one :file:`FORCING/` directory.\n The same forcing data can be used for all configurations.\n\n2. Next, we need to link our forcing data to the :file:`Gridded/` directory.\n\n From the :file:`example_case/Gridded directory`, create a symlink:\n\n :code:`ln -s ../FORCING .`\n\n Your project directory should now have the following\n directory structure and files:\n\n .. code-block:: console\n\n project_directory/\n ├──wrf_hydro_nwm_public/\n | ├──src/\n | ├──build/\n |\n ├──example_case/\n ├──Gridded/\n ├──FORCING/\n ├──DOMAIN/\n ├──RESTART/\n ├──referenceSim/\n ├──CHANPARM.TBL\n ├──GENPARM.TBL\n ├──HYDRO.TBL\n ├──MPTABLE.TBL\n ├──SOILPARM.TBL\n ├──hydro.namelist\n ├──namelist.hydrodas\n ├──wrf_hydro\n\n3. Now we will run the simulation. Note that there are many options\n and filepaths that need to be set in the two namelist files\n :file:`hydro.namelist` and :file:`namelist.hrldas`. However, for this\n walkthrough these files have been prepared for you.\n\n Before running the model, ensure you are in the :file:`example_case/Gridded`\n directory.\n\n We will now run the model using :command:`mpirun` with 2 cores. This command may\n differ depending on your system configuration, but here is an example\n of what this might look like:\n\n .. code-block:: bash\n\n mpirun -np 2 ./wrf_hydro\n\n4. If your simulation ran successfully, there should now be a large\n number of output files. Descriptions of the output files and their contents\n can be found in :ref:`Appendix A19 `. There are also two\n important files for determining the success or failure of the run,\n :file:`diag_hydro.00000` and :file:`diag_hydro.00001`. These :file:`diag_hydro`\n files contain logs and diagnostics on the simulation run, and one file is\n produced per core used in the run. Since we ran using 2 cores, we\n have 2 :file:`diag_hydro` files.\n\n You can check that your simulation ran successfully by examining the\n last line of the diag files, which should read:\n\n .. code-block:: console\n\n The model finished successfully........\n\n If this line is not present, the simulation did not finish\n successfully.\n\n5. You can check the validity of your simulation results by comparing\n the restart files produced during your model run with the restart\n files included in the :file:`example_case/Gridded/referenceSim` directory.\n The restart files contain all the model states and thus provide a\n simple means for testing if two simulations produced the same\n results.\n\n.. note:: Our current example test cases have only been run and tested with\n the Noah-MP land surface model. For information regarding running\n WRF-Hydro with Noah please see :ref:`Appendix A3 `.\n\n\n.. _section-a2:\n\nA2. Coupled WRF | WRF-Hydro Test Case User Guide\n------------------------------------------------\n\nPurpose\n^^^^^^^\n\nThis test case for the coupled WRF | WRF-Hydro modeling system is meant to\norient you to running the modeling system using prepared geographical inputs\nfor WRF-Hydro and sample initial and boundary conditions for WRF. Note that\nsome of the initial and boundary conditions for this test case have been\nmodified in order to produce a hydrologic response over a very limited spatial\ndomain. Results generated from this test case should not be interpreted as a\nreal simulation and users should consult the WRF and WPS documentation for\nbest practices with respect to domain and model configuration. The purpose of\nthis test case is to provide baseline instructions and a computationally\ntractable test case for users to familiarize themselves with the modeling\nsystem and help ensure the modeling system is running properly on their\nsystems. Please see the README.txt file provided with the test case for a more\ndetailed description of the contents.\n\nFor a detailed technical description of WRF-Hydro and instructions on how to run WRF |\nWRF-Hydro in coupled mode see the `WRF-Hydro Technical Description\ndocumentation `_ and How\nto Run WRF-Hydro V5 in Coupled Mode user guide available from\nhttps://ral.ucar.edu/projects/wrf_hydro.\n\nFor further information regarding the WRF model and the WRF Preprocessing System (WPS)\nsee the WRF Users’ Guide located here:\nhttp://www2.mmm.ucar.edu/wrf/users/docs/user_guide_v4/contents.html\n\nRequirements\n^^^^^^^^^^^^\n\n- WRF-Hydro source code: https://github.com/NCAR/wrf_hydro_nwm_public.git\n - Git clone into directory where you will be running this case\n- Download WRF and WPS source code:\n - WRF: https://github.com/wrf-model/WRF\n - WPS: https://github.com/wrf-model/WPS\n- WPS geographic data\n http://www2.mmm.ucar.edu/wrf/src/wps_files/geog_high_res_mandatory.tar.gz\n- An official WRF-Hydro coupled test case:\n https://ral.ucar.edu/projects/wrf_hydro/testcases\n- All system libraries needed by the WRF-Hydro modelling system can be found\n in the How To Build & Run WRF-Hydro V5 in Standalone Mode user guide and the\n FAQ web page located at https://ral.ucar.edu/projects/wrf_hydro\n- All system libraries needed by the WRF modeling system and WPS can be found\n in the WRF User’s Guide located here:\n http://www2.mmm.ucar.edu/wrf/users/docs/user_guide_v4/contents.html\n\n\nStep-by-step walkthrough\n^^^^^^^^^^^^^^^^^^^^^^^^\n**Directory structure setup**:\nWe will organize all files and folders under a common top-level directory to\nsimplify commands in this walkthrough. All paths mentioned in this walkthrough\nwill be relative to this top-level directory. For example,\n/home/user/project_directory/example_case_coupled/ will be referred to as\nexample_case_coupled/. The following steps walk you through how to setup your\nproject directory.\n\n1. Open a terminal window\n2. Create a top-level directory that will hold all subdirectories and files\n used for this walkthrough. Hereafter referred to as the ‘project\n directory’.\n3. Git clone WRF-Hydro, WRF, and WPS into project directory created in step 2.\n Here are examples of possible commands to use, modify as needed:\n\n.. code-block:: console\n\n git clone https://github.com/NCAR/wrf_hydro_nwm_public.git\n git clone --recurse-submodule --branch v4.7.1 https://github.com/wrf-model/WRF.git\n git clone --branch v4.6.0 https://github.com/wrf-model/WPS.git\n\n\n4. Download and extract testcase and geographic data.\n\n.. code-block:: console\n\n # download and extract files\n wget https://github.com/NCAR/wrf_hydro_nwm_public/releases/download/v5.4.0/front_range_CO_example_testcase_coupled.tar.gz\n tar zxf front_range_CO_example_testcase_coupled.tar.gz\n\n # Note this geog data is currently broken, Derecho users should skip this\n # step and in namelists.wps set\n # geog_data_path = '/glade/work/wrfhelp/WPS_GEOG/',\n wget http://www2.mmm.ucar.edu/wrf/src/wps_files/geog_high_res_mandatory.tar.gz\n tar zxf geog_high_res_mandatory.tar.gz\n\n\n\n5. Move the newly extracted geographic data into the WPS directory.\n\n.. code-block:: console\n\n # create directory and move geopgraphic data\n mkdir -p run/WPS\n mv WPS_GEOG/ run/WPS/geog\n\n\n6. Your project directory structure will look like the following:\n\n.. code-block:: console\n\n project_directory/\n ├──run/\n │ ├──WPS/\n │ └──WRF/\n ├──wrf_hydro_nwm_public*/\n │ └──src/\n ├──WRF/\n ├──WPS/\n │ ├──geogrid/\n │ ├──metgrid/\n │ ├──ungrib/\n │ └──geog/\n └──example_case_coupled/\n ├──WRF_FORCING/\n └──DOMAIN/\n\n\nCompiling the Code\n^^^^^^^^^^^^^^^^^^\n\nThis section will walk you through compiling the coupled WRF | WRF-Hydro\nmodeling system and the WRF Preprocessing System (WPS) utilities\n\n**Compiling the coupled WRF | WRF-Hydro modeling system**\n\n1. Navigate to the WRF source code directory at WRF\n\n.. code-block:: console\n\n cd WRF\n\n2. Remove the old WRF-Hydro source code contained within this directory and replace it\nwith the updated version you just downloaded\n\n.. code-block:: console\n\n rm -r hydro\n cp -r ../wrf_hydro*/src hydro\n\n3. Load appropriate modules on Derecho, the following is an example for GNU compilers.\n\n.. code-block:: console\n\n module purge\n module load ncarenv gcc ncarcompilers cray-mpich craype netcdf cmake\n\n4. Configure and compile WRF\n\n.. warning::\n **On Derecho, use the legacy configure method. CMake has known issues with the coupled case.**\n **Use the legacy configure method for building both WRF and WPS**\n\n\n4a. Configure and compile WRF: CMake\n\n.. code-block:: console\n\n # CMake option to turn on WRF-Hydro nudging `-DWRF_HYDRO_NUDGING=1`\n ./configure_new -x -p gfortran/gcc -- -DWRF_CORE=ARW -DWRF_NESTING=BASIC -DENABLE_HYDRO=ON -DWRF_CASE=EM_REAL\n ./compile_new -j4\n\n\n4b. Configure and compile WRF: Old Method\n\n\n.. code-block:: console\n\n # Load environement variables from WRF directory\n source hydro/template/setEnvar.sh\n\n # Export paths necessary for WRF to find the right libraries on Derecho\n export Jasper_ROOT=/glade/u/home/wrfhelp/UNGRIB_LIBRARIES/\n\n # Configure WRF\n # On Derecho,\n # For GNU (dmpar) and basic nesting\n # 1. enter `printf '34\\n1\\n' | ./configure` or option 34 and 1\n # For IFX (dmpar) and basic nesting\n # 1. enter `printf '78\\n1\\n' | ./configure` or option 78 and 1\n # 2. Login node does not have enough memory to compile succesfully with ifx.\n # User can use interactive node with extra memory, mem=50GB works\n ./configure\n ./compile -j 4 em_real &> compile.log\n # the binaries will be in the run directory\n\n\n**Compiling the WRF Preprocessing System (WPS)**\n\n1. Navigate to the WPS source code directory at WPS\n\n\n2. Configure and compile the WPS. Note that grib2 data is used in the example\n and the Jasper environmental variables need to be set.\n\n2a. Configure and compile WPS: CMake\n\nNote: CMakeLists.txt line 164 in the top directory of WPS will need to be changed to\n\n.. code-block:: console\n\n add_compile_definitions(\n ${WPS_DEFINITIONS_LIST}\n ${WPS_UNDEFINITIONS_LIST}\n USE_JPEG2000\n USE_PNG\n )\n\nNow configure with\n\n.. code-block:: console\n\n ./configure_new -x -p gfortran -- -DBUILD_EXTERNALS=ON\n ./compile_new -j 4 &> compile.log\n\n\n2b. Configure and compile WPS: old Method\n\n\n.. code-block:: console\n\n # Select option 2 and --build-grib2-libs. Option 2 is Linux x86_64, gfortran\n # (dmpar) or select th dmpar option for compiler of choice\n # The user can also enter printf '2\\n' | ./configure --build-grib2-libs to pass the arguments\n export Jasper_ROOT=/glade/u/home/wrfhelp/UNGRIB_LIBRARIES/\n ./configure --build-grib2-libs\n ./compile geogrid -j 4\n ./compile ungrib -j 4\n ./compile metgrid -j 4\n\ncheck the compile log for errors.\n\n\nRunning the WRF Preprocessing System (WPS)\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n.. figure:: media/wps_program_flow.png\n :align: center\n\n Image from `WPS Userguide `_.\n\n\nIn this section we will use the compiled WRF Preprocessing System (WPS)\nutilities along with a namelist file ( namelist.wps ) and meteorological\nforcing data from the coupled test case to generate geogrid and metgrid files\nfor the two model domains (note that the inner nest, or domain 2, is where\nWRF-Hydro will run).\n\n**Running the geogrid utility**\n\n1. Create a run directory for WPS within your project directory\n\n.. code-block:: console\n\n mkdir -p run/WPS\n cd run/WPS\n\n\n2. Now copy the required files for the WPS geogrid utility into your ``run/WPS``\n directory\n\n.. code-block:: console\n\n cp ../../WPS/geogrid/GEOGRID.TBL .\n cp ../../example_case_coupled/namelist.wps .\n\n # for new CMake install method\n cp ../../WPS/install/bin/geogrid.exe .\n\n # or if the older method was used to build\n cp ../../WPS/geogrid.exe .\n\n\n\nEdit the paths within this namelist as appropriate for your system\n\n3. Edit the path to geographic data in your ``namelist.wps`` file so that\n ``geog_data_path`` points to the correct path.\n\n.. code-block:: console\n\n geog_data_path = '/glade/work/wrfhelp/WPS_GEOG/',\n # or geog, note though this is currently not working\n geog_data_path = 'geog',\n\n\n4. Run the geogrid utility\n\n.. code-block:: console\n\n mpiexec -np 2 ./geogrid.exe &> geogrid.log\n\n\n**Running the ungrib utility**\n\nThe ungrib utility takes meteorological forcing data to be used for simulation\ninitial and boundary conditions and converts the files to an intermediate file\nformat used by the metgrid utility. Make sure modules are loaded from previous\nsteps.\n\n\n1. Now copy the additional required files for the WPS ungrib utility into your\n ``run/WPS`` directory\n\n.. code-block:: console\n\n cd run/WPS\n cp ../../WPS/link_grib.csh .\n\n # for new cmake build method\n cp ../../WPS/install/bin/ungrib.exe .\n\n # or if the older method was used to build\n cp ../../WPS/ungrib.exe .\n\n\n2. Next copy over the necessary variable table for your forcing data\n\n.. code-block:: console\n\n cp ../../WPS/ungrib/Variable_Tables/Vtable.NAM Vtable\n\n\n3. Then link your forcing data from the test case to the run directory (this\n script will also rename the files to those expected for the ungrib utility)\n\n.. code-block:: console\n\n ./link_grib.csh ../../example_case_coupled/WRF_FORCING/*\n\n\n4. Next run the ungrib utility\n\n.. code-block:: console\n\n mpiexec -np 2 ./ungrib.exe &> ungrib.log\n\n\n**Running the metgrid utility**\n\nThe metgrid utility does some interpolation of meteorological forcing data to\nthe model domain creating metgrid files to be used as input to the WRF real\nutility.\n\n1. Now copy additional the required files for the WPS metgrid utility into\n your ``run/WPS`` directory\n\n.. code-block:: console\n\n cp ../../WPS/metgrid/METGRID.TBL .\n\n # for newer CMake build method\n cp ../../WPS/install/bin/metgrid.exe .\n\n # or if the older method was used to build\n cp ../../WPS/metgrid.exe .\n\n\n2. Next run the metgrid utility\n\n.. code-block:: console\n\n mpiexec -np 2 ./metgrid.exe &> metgrid.log\n\n\nRunning a coupled WRF | WRF-Hydro simulation\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nIn this section we will use our compiled coupled WRF | WRF-Hydro model to run\na simulation. This walkthrough uses the Front Range coupled example test\ncase. Details on the domain and time period of the simulation are provided in\nthe example_case_coupled/README.txt file.\n\n**Setting up your run directory**\n\nFirst we will create a run directory and copy over or link the required files.\n\n1. Create a run directory for WRF by copying over the run directory from where\n it was compiled\n\n.. code-block:: console\n\n cd project_directory\n # run directory should exist at this point\n cp -RL WRF/run run/WRF\n cd run/WRF\n\n\n2. Copy over parameter tables for WRF-Hydro\n\n.. code-block:: console\n\n cp ../../WRF/hydro/template/HYDRO/*TBL .\n # cp ../../WRF/hydro/template/NoahMP/run/*.TBL .\n # cp ../../WRF/install/test/em_real/*.TBL .\n\n3. Copy over the namelists for real / wrf (namelist.input) and the hydro components\n(hydro.namelist) from the example case\n\n.. code-block:: console\n\n cp ../../example_case_coupled/namelist.input .\n cp ../../example_case_coupled/hydro.namelist .\n cp ../../WRF/hydro/template/NoahMP/namelist.hrldas .\n cp -r ../../example_case_coupled/DOMAIN/ .\n cp ../../WRF/run/CAMtr_volume_mixing_ratio .\n cp ../../WRF/phys/noahmp/parameters/MPTABLE.TBL .\n\n\n4. Link the geogrid and metgrid files we just generated from the WPS utilities\n\n.. code-block:: console\n\n ln -sf ../WPS/met_em* .\n ln -sf ../WPS/geo_em* .\n ln -sf ../../WRF/run/RRTM_DATA .\n\n\n4. Copy executable files\n\n.. code-block:: console\n\n # location for the CMake build, older method will have these files in the WRF/run directory\n cp ../../WRF/install/bin/real real.exe\n cp ../../WRF/install/bin/wrf wrf.exe\n\n\n**Running the real utility**\n\nThe WRF real utility creates the wrfinput* and wrfbdy* initial and boundary\ncondition files to be used as input for the coupled simulation.\n\n1. Execute real using the proper syntax for your system (example below)\n and pipe the output to a log file.\n\n.. code-block:: console\n\n mpirun -np 2 ./real.exe &> real.log\n\n2. Next review the rsl.out.* and rsl.error.* files for possible errors and\n check to make sure the wrfinput* and wrfbdy* files have been created.\n\n.. code-block:: console\n\n tail rsl.error.* -n 1\n\n**Running the coupled model**\n\nNow we will run the coupled model (all included in the wrf binary) using\nthe wrfinput* and wrfbdy* files as initial and boundary conditions and the\nmodel physics and other options selected in the namelist.input and\nhydro.namelist files.\n\n1. Execute wrf using the proper syntax for your system (example below) and\n pipe the output to a log file.\n\n.. code-block:: console\n\n mpirun -np 2 ./wrf.exe &> wrf.log\n\n2. If your simulation ran successfully, there should now be a large number of\n output files. Descriptions of the output files can be found in the\n WRF-Hydro V5 Technical Description at (\n https://ral.ucar.edu/projects/wrf_hydro ) and the WRF User’s Guide found\n here ( http://www2.mmm.ucar.edu/wrf/users/docs/user_guide_v4/contents.html\n ). You will also want to review the rsl.out.* and rsl.error.* files for\n possible error messages.\n\n\n\n.. _section-a3:\n\nA3. Exceptions for Running WRF-Hydro with the Noah LSM\n------------------------------------------------------\n\nSupport for the Noah Land Surface Model (LSM) within WRF-Hydro is\ncurrently frozen at Noah version 3.6, development to use the\n`refactored NoahMP `_ as a submodule\nis under way. Since the Noah LSM is not under\nactive development by the community, WRF-Hydro is continuing to support\nNoah in deprecated mode only. Some new model features, such as the\nimproved output routines, have not been setup to be backward compatible\nwith Noah. Noah users should follow the guidelines below for adapting\nthe WRF-Hydro workflow to work with Noah:\n\n- **LSM initialization:** The simple wrfinput.nc initialization file\n created by the create_Wrfinput.R script does not currently include\n all of the fields required by the Noah LSM. Therefore, Noah users\n should use the WRF real utility to create a wrfinput_d0x file.\n Refer to the WRF documentation and user guides for information on how\n to do this.\n\n- **Time-varying vegetation specifications:** While the Noah LSM will\n be properly initialized with green vegetation fraction from the\n wrfinput file, there is currently no automated method to update this\n field over time (e.g., seasonally based on climatology). Therefore,\n Noah users will need to provide these time-varying fields in the\n model input forcing files (e.g., LDASIN).\n\n- **Spatially varying parameters**: Spatially varying soil and\n vegetation parameters (e.g., soil_properties.nc) are not supported in\n Noah.\n\n- **Model outputs:** The updated output routines have not been adapted\n to work with Noah. Therefore, Noah users should always use\n io_form_outputs = 0 to activate the deprecated output routines.\n Scale/offset and compression options, CF compliance, augmented\n spatial metadata, etc. are not available in this deprecated mode.\n\n.. _section-a4:\n\nA4. Noah `namelist.hrldas` File with Description of Options\n-----------------------------------------------------------\n\nBelow is an annotated namelist.hrldas file for running with the Noah\nland surface model. Notes and descriptions are indicated with <--\n\n.. code-block:: fortran\n\n &NOAHLSM_OFFLINE\n HRLDAS_CONSTANTS_FILE = \"./DOMAIN/wrfinput_d01\" !!<-- Path to wrfinput file containing initialization data\n ! for the LSM. This is required even for a warm start\n ! where a restart file is provided.\n\n INDIR = \"./FORCING\" !<-- Path to atmospheric forcing data directory.\n OUTDIR = \"./\" !<-- Generally leave this as-is (output goes to base run directory);\n ! redirected output only applies to LSM output files and can cause\n ! issues when running coupled to WRF-Hydro.\n START_YEAR = 2013 !<-- Simulation start year\n START_MONTH = 09 !<-- Simulation start month\n START_DAY = 01 !<-- Simulation start day\n START_HOUR = 00 !<-- Simulation start hour\n START_MIN = 00 !<-- Simulation start min\n RESTART_FILENAME_REQUESTED = \"RESTART.2013090100_DOMAIN1\" !<-- Path to LSM restart file if using; this contains a\n ! \"warm\" model state from a previous model run.\n ! Comment out if not a restart simulation.\n\n ! Specification of simulation length in days hours\n KHOUR = 24 !<-- Number of hours for simulation;\n\n ! Timesteps in units of seconds\n FORCING_TIMESTEP = 3600 !<-- Timestep for forcing input data (in seconds)\n NOAH_TIMESTEP = 3600 !<-- Timestep the LSM to cycle (in seconds)\n OUTPUT_TIMESTEP = 86400 !<-- Timestep for LSM outputs, LDASOUT (in seconds)\n\n ! Land surface model restart file write frequency\n RESTART_FREQUENCY_HOURS = 6 !<-- Timestep for LSM restart files to be generated (in hours). A value of -99999\n ! will simply output restarts on the start of each month, useful for longer\n ! model runs. Restart files are generally quite large, so be cognizant of\n ! storage space and runtime impacts when specifying.\n ! Split output after split_output_count output times.\n SPLIT_OUTPUT_COUNT = 1 !<-- Number of timesteps to put in a single output file. This option\n ! must be 1 for NWM output configurations.\n\n ! Soil layer specification\n NSOIL=4 !<-- Number of soil layers\n ZSOIL(1) = 0.10 !<-- Thickness of top soil layer (m)\n ZSOIL(2) = 0.30 !<-- Thickness of second soil layer (m)\n ZSOIL(3) = 0.60 !<-- Thickness of third soil layer (m)\n ZSOIL(4) = 1.00 !<-- Thickness of bottom soil layer (m)\n\n ! Forcing data measurement heights\n ZLVL = 2.0 !<-- Height of input temperature and humidity measurement/estimate\n ZLVL_WIND = 10.0 !<-- Height of input wind speed measurement/estimate\n\n IZ0TLND = 0 !<-- Switch to control land thermal roughness length. Option 0 is the default,\n ! non-vegetation dependent value and option 1 introduces a vegetation dependence.\n SFCDIF_OPTION = 0 !<-- Option to use the newer, option 1, or older,\n option 0, SFCDIF routine. The default value is 0.\n UPDATE_SNOW_FROM_FORCING = .FALSE. !<-- Option to activate or deactivate updating the snow­cover\n ! fields from available analyses. The default option is true.\n\n ! -------- Section: Select atmospheric forcing input file format, FORC_TYP -------- !\n ! Specification of forcing data: 1=HRLDAS-hr format, 2=HRLDAS-min format,\n ! 3=WRF,4=Idealized, 5=Ideal w/ Spec.Precip.,\n ! 6=HRLDAS-hrly fomat w/ Spec. Precip, 7=WRF w/ Spec. Precip\n FORC_TYP = 3\n /\n\n.. _section-a5:\n\nA5. Noah-MP `namelist.hrldas` File with Description of Options\n--------------------------------------------------------------\n\nBelow is an annotated namelist.hrldas file for running with the Noah-MP\nland surface model. Do note that the file says ``&NOAHLSM_OFFLINE``\nhowever it is for use with the Noah-MP LSM. This namelist statement\nhappens to be hardcoded and thus not easily changed. Notes and\ndescriptions are indicated with <-- after sections\nbeing described. See the official HRLDAS namelist description here:\nhttps://github.com/NCAR/hrldas-release/blob/release/HRLDAS/run/README.namelist\n\n.. code-block:: fortran\n\n &NOAHLSM_OFFLINE\n HRLDAS_SETUP_FILE = \"./DOMAIN/wrfinput_d01\" !<-- Path to wrfinput file containing initialization\n ! data for the LSM. This is required even for a warm\n ! start where a restart file is provided.\n INDIR = \"./FORCING\" !<-- Path to atmospheric forcing data directory.\n\n SPATIAL_FILENAME = \"./DOMAIN/soil_properties.nc\" !<-- Path to optional 2d/3d soil and vegetation\n ! parameter file. If you are using this option,\n ! you must also use a binary compiled with\n ! SPATIAL_SOIL=1. If using the traditional\n ! parameter lookup tables, compile with\n ! SPATIAL_SOIL=0 and comment out this option.\n OUTDIR = \"./\" !<-- Generally leave this as-is (output goes to base run directory); redirected\n ! output only applies to LSM output files\n ! and can cause issues when running coupled to WRF-Hydro.\n START_YEAR = 2013 !<-- Simulation start year\n START_MONTH = 09 !<-- Simulation start month\n START_DAY = 12 !<-- Simulation start day\n START_HOUR = 04 !<-- Simulation start hour\n START_MIN = 00 !<-- Simulation start min\n RESTART_FILENAME_REQUESTED = \"RESTART.2013091204_DOMAIN1\" !<-- Path to LSM restart file if using;\n ! this contains a \"warm\" model state\n ! from a previous model run. Comment out\n ! if not a restart simulation.\n ! Specification of simulation length in days OR hours\n KHOUR = 24 !<-- Number of hours for simulation\n\n ! -------- Following Section: Noah-MP physics options -------- !\n\n ! Physics options (see the documentation for details)\n\n DYNAMIC_VEG_OPTION = 4 !<-- options for dynamic vegetation:\n ! 1 -> off (use table LAI; use FVEG = SHDFAC from input)\n ! 2 -> on (together with OPT_CRS = 1)\n ! 3 -> off (use table LAI; calculate FVEG)\n ! **4 -> off (use table LAI; use maximum vegetation fraction)\n ! **5 -> on (use maximum vegetation fraction)\n ! 6 -> on (use FVEG = SHDFAC from input)\n ! 7 -> off (use input LAI; use FVEG = SHDFAC from input)\n ! 8 -> off (use input LAI; calculate FVEG)\n ! 9 -> off (use input LAI; use maximum vegetation fraction)\n\n CANOPY_STOMATAL_RESISTANCE_OPTION = 1 !<-- options for canopy stomatal resistance\n ! **1 -> Ball-Berry\n ! 2 -> Jarvis\n\n BTR_OPTION = 1 !<-- options for soil moisture factor for stomatal resistance\n ! **1 -> Noah (soil moisture)\n ! 2 -> CLM (matric potential)\n ! 3 -> SSiB (matric potential)\n\n RUNOFF_OPTION = 3 !<-- options for runoff and groundwater\n ! 1 -> TOPMODEL with groundwater (Niu et al. 2007 JGR)\n ! 2 -> TOPMODEL with an equilibrium water table (Niu et al. 2005 JGR)\n ! **3 -> original surface and subsurface runoff (free drainage)\n ! 4 -> BATS surface and subsurface runoff (free drainage)\n ! 5 -> Miguez-Macho&Fan groundwater scheme (Miguez-Macho et al. 2007 JGR;\n ! Fan et al. 2007 JGR) [NOT YET SUPPORTED WITH WRF-HYDRO]\n ! 7 -> Xinanjiang runoff scheme\n\n\n SURFACE_DRAG_OPTION = 1 !<-- options for surface layer drag coeff (CH & CM)\n ! **1 -> M-O\n ! 2 -> original Noah (Chen97)\n\n FROZEN_SOIL_OPTION = 1 !<-- options for frozen soil permeability\n ! **1 -> linear effects, more permeable (Niu and Yang, 2006, JHM)\n ! 2 -> nonlinear effects, less permeable (old)\n\n SUPERCOOLED_WATER_OPTION = 1 !<-- options for supercooled liquid water (or ice fraction)\n ! **1 -> no iteration (Niu and Yang, 2006 JHM)\n ! 2 -> Koren's iteration\n\n RADIATIVE_TRANSFER_OPTION = 3 !<-- options for radiation transfer\n ! 1 -> modified two-stream (gap = F(solar angle, 3D structure ...)<1-FVEG)\n ! 2 -> two-stream applied to grid-cell (gap = 0)\n ! **3 -> two-stream applied to vegetated fraction (gap=1-FVEG)\n\n SNOW_ALBEDO_OPTION = 1 !<-- options for ground snow surface albedo\n ! **1 -> BATS\n ! 2 -> CLASS\n\n PCP_PARTITION_OPTION = 1 !<-- options for partitioning precipitation into rainfall & snowfall\n ! **1 -> Jordan (1991)\n ! 2 -> BATS: when SFCTMP SFCTMP < TFRZ\n ! 4 -> Use WRF microphysics output\n\n TBOT_OPTION = 2 !<-- options for lower boundary condition of soil temperature\n ! 1 -> zero heat flux from bottom (ZBOT and TBOT not used)\n ! **2 -> TBOT at ZBOT (8m) read from a file (original Noah)\n\n TEMP_TIME_SCHEME_OPTION = 3 !<-- options for snow/soil temperature time scheme (only layer 1)\n ! 1 -> semi-implicit; flux top boundary condition\n ! 2 -> full implicit (original Noah); temperature top boundary condition\n ! **3 -> same as 1, but FSNO for TS calculation (generally improves snow; v3.7)\n\n GLACIER_OPTION = 2 !<-- options for glacier treatment\n ! 1 -> include phase change of ice\n ! **2 -> ice treatment more like original Noah (slab)\n\n SURFACE_RESISTANCE_OPTION = 4 !<-- options for surface resistent to evaporation/sublimation\n ! 1 -> Sakaguchi and Zeng, 2009\n ! 2 -> Sellers (1992)\n ! 3 -> adjusted Sellers to decrease RSURF for wet soil\n ! **4 -> option 1 for non-snow; rsurf = rsurf_snow for snow (set in MPTABLE); AD v3.8\n\n IMPERV_OPTION = 9 !<-- options for impervious adjustment for surface runoff partitioning\n ! 0 -> none\n ! 1 -> adjust based on impervious fraction\n ! 2 -> adjust based on effective impervious fraction from Alley & Veenhuis\n ! **9 -> original formulation (varies based on runoff option)\n\n ! Timesteps in units of seconds\n FORCING_TIMESTEP = 3600 !<-- Timestep for forcing input data (in seconds)\n NOAH_TIMESTEP = 3600 !<-- Timestep the LSM to cycle (in seconds)\n OUTPUT_TIMESTEP = 86400 !<-- Timestep for LSM outputs, LDASOUT (in seconds)\n\n ! Land surface model restart file write frequency\n RESTART_FREQUENCY_HOURS = 2 !<-- Timestep for LSM restart files to be generated (in hours).\n ! A value of -99999 will simply output restarts on the start of\n ! each month, useful for longer model runs. Restart files are\n ! generally quite large, so be cognizant of storage space and\n ! runtime impacts when specifying.\n ! Split output after split_output_count output times.\n SPLIT_OUTPUT_COUNT = 1 !<-- Number of timesteps to put in a single\n output file. This option must be 1 for NWM output configurations.\n\n ! Soil layer specification\n NSOIL=4 !<-- Number of soil layers\n soil_thick_input(1) = 0.10 !<-- Thickness of top soil layer (m)\n soil_thick_input(2) = 0.30 !<-- Thickness of second soil layer (m)\n soil_thick_input(3) = 0.60 !<-- Thickness of third soil layer (m)\n soil_thick_input(4) = 1.00 !<-- Thickness of bottom soil layer (m)\n\n ! Forcing data measurement height for winds, temp, humidity\n ZLVL = 10.0 !<-- Height of input wind speed\n\n ! -------- Following Section: Restart IO file formats -------- !\n\n ! Options to specify whether restart files (both read in and output)\n ! should be in binary or netCDF format. Generally recommend using\n ! netCDF format (option 0) for both.\n\n ! Restart file format options\n rst_bi_in = 0 !<-- 0: use netcdf input restart file 1: use parallel io for reading multiple\n ! restart files (1 per core)\n rst_bi_out = 0 !<-- 0: use netcdf output restart file 1: use parallel io for outputting multiple\n ! restart files (1 per core)\n\n ! -------- Optional forcing variable names -------- !\n ! These can be left out of the namelist and will default to the values below,\n ! so only need to be specified if using alternative names.\n\n ! Forcing input variable names\n forcing_name_T = \"T2D\" !<-- variable name for air temperature\n forcing_name_Q = \"Q2D\" !<-- variable name for humidity\n forcing_name_U = \"U2D\" !<-- variable name for u-component of wind speed\n forcing_name_V = \"V2D\" !<-- variable name for v-component of wind speed\n forcing_name_P = \"PSFC\" !<-- variable name for surface pressure\n forcing_name_LW = \"LWDOWN\" !<-- variable name for downward longwave radiation\n forcing_name_SW = \"SWDOWN\" !<-- variable name for downward shortwave radiation\n forcing_name_PR = \"RAINRATE\" !<-- variable name for precipitation rate\n ! Optional way to supply liquid or snow fraction of precipitation, e.g., if provided\n ! by an atmospheric model. Otherwise the land model will estimate this.\n ! NOTE: You can provide either frozen fraction or liquid fraction (no need to provide both).\n forcing_name_SN = \"\" !<-- variable name for frozen fraction of precipitation\n forcing_name_LF = \"LQFRAC\" !<-- variable name for liquid fraction of precipitation\n\n /\n\n &WRF_HYDRO_OFFLINE\n\n ! Specification of forcing data: 1=HRLDAS-hr format, 2=HRLDAS-min format,\n ! 3=WRF, 4=Idealized, 5=Ideal w/ Spec.Precip.,\n ! 6=HRLDAS-hrly fomat w/ Spec. Precip, 7=WRF w/ Spec.Precip\n FORC_TYP = 1\n\n /\n\n ! -------- Optional settings for the Crocus snow model -------- !\n ! These options can be excluded if not using the Crocus snow/glacier model.\n\n &CROCUS_nlist\n crocus_opt = 0 !<-- 0 means the Crocus model is off (default)\n ! 1 means the Crocus model is on\n act_lev = 40 !<-- Specify the number of layers the Crocus snow model will resolve.\n ! More layers will require more memory and may slow performance.\n ! 20-40 normal range, 1-50 acceptable\n\n /\n\n.. _section-a6:\n\nA6. WRF-Hydro `hydro.namelist` File with Description of Options\n---------------------------------------------------------------\n\nBelow is an annotated hydro.namelist file. Annotations follow what is\nbeing described, indicated with <-- and blue text. Note that\nannotations describing options are meant to accompany the commented\ndescription in the namelist which precedes the option.\n\n.. _hydro-namelist:\n\n.. code-block:: fortran\n\n &HYDRO_nlist\n !!!! --------------- SYSTEM COUPLING -------------- !!!!\n ! Specify what is being coupled: 1=HRLDAS (offline Noah-LSM),\n ! 2=WRF, 3=NASA/LIS, 4=CLM\n sys_cpl = 1 !<-- For offline runs, including Noah and Noah-MP, this will be option 1.\n\n !!!! ----------- MODEL INPUT DATA FILES ----------- !!!!\n ! Specify land surface model gridded input data file (e.g.: \"geo_em.d01.nc\")\n GEO_STATIC_FLNM = \"./DOMAIN/geo_em.d01.nc\" !<-- Path to the “GEOGRID” file which contains base\n ! information on the LSM grid (this file is generally\n ! created via WPS in the model preprocessing steps).\n\n ! Specify the high-resolution routing terrain input data file (e.g.: \"Fulldom_hires.nc\")\n GEO_FINEGRID_FLNM = \"./DOMAIN/Fulldom_hires.nc\" !<-- Path to the “routing stack” which contains\n ! base information on the high-resolution routing\n ! grid. This file is generally created via the\n ! GIS pre-processing tools.\n\n ! Specify the spatial hydro parameters file (e.g.: \"hydro2dtbl.nc\")\n ! If you specify a filename and the file does not exist, it will\n ! be created for you.\n HYDROTBL_F = \"./DOMAIN/hydro2dtbl.nc\" !<-- Path to the 2d hydro parameters file. If this file\n ! does not exist, it will be created for you based on\n ! HYDRO.TBL and the soil and land class grids found in the\n ! GEOGRID netCDF file\n\n ! Specify spatial metadata file for land surface grid. (e.g.: \"GEOGRID_LDASOUT_Spatial_Metadata.nc\")\n LAND_SPATIAL_META_FLNM = \"./DOMAIN/GEOGRID_LDASOUT_Spatial_Metadata.nc\" !<-- Path to the geospatial\n ! metadata file for your domain. This file is required\n ! if using any of the io_form_outputs options (i.e.,\n ! io_form_outputs > 0). This file is generally created\n ! via the GIS pre-processing tools.\n\n ! Specify the name of the restart file if starting from restart...comment out with '!' if not...\n RESTART_FILE = 'HYDRO_RST.2013-09-12_04:00_DOMAIN3' !<-- Path to hydro restart file; this contains\n ! a \"warm\" model state from a previous model run.\n\n !!!! ------------- MODEL SETUP OPTIONS ------------ !!!!\n ! Specify the domain or nest number identifier...(integer)\n IGRID = 1 !<-- Domain ID number. This comes from the WRF coupling framework and is intended to\n ! specify which nested domain you are running. For standalone runs, this is not relevant\n ! HOWEVER this ID must match the number specified after DOMAIN in your forcing file names\n ! (e.g., the \"1\" in \"2013091200.LDASIN_DOMAIN1\").\n\n ! Specify the restart file write frequency in minutes\n ! A value of -99999 will output restarts on the first day of the month only.\n rst_dt = 120 !<-- Specify how often hydro restart files should be generated, in minutes. This should\n ! generally track your LSM restart file frequency (as specified in namelist.hrldas).\n ! A value of -99999 will simply output restarts on the start of each month, useful for\n ! longer model runs. Hydro restart files are generally quite large, so be cognizant of\n ! storage space and runtime impacts.\n\n ! Reset the LSM soil states from the high-res routing restart file (1=overwrite, 0=no overwrite)\n ! NOTE: Only turn this option on if overland or subsurface routing is active!\n rst_typ = 1 !<-- Specify whether or not to use the soil conditions (soil moisture and ponded water)\n ! from the high-resolution hydro restart file, if \"warm\" starting the model with a\n ! provided HYDRO_RST file. If this option is 0, the LSM restart states will be used\n ! instead. IMPORTANT: If you are NOT running with terrain routing turned on, do not set\n ! this option to 1 as it may bring in invalid values.\n\n ! Restart file format control !<-- Options to whether restart files (input and output separately)\n ! should be in binary or netCDF format. Generally recommend to use\n ! netCDF format (option 0) for both.\n rst_bi_in = 0 !0: use netCDF input restart file (default) 1: use parallel io for reading multiple\n ! restart files, 1 per core\n rst_bi_out = 0 !0: use netCDF output restart file (default) 1: use parallel io for outputting multiple\n ! restart files, 1 per core\n\n ! Restart switch to set restart accumulation variables to 0 (0=no reset, 1=yes reset to 0.0)\n RSTRT_SWC = 0 !<-- Specify whether or not to reset any accumulated output variables to 0 (option 1)\n ! or to continue accumulating from the values in the hydro restart file (option 0).\n ! Note that this only applies to the hydrologic model outputs; the LSM outputs will\n ! always continue to accumulate from the LSM restart file.\n\n ! Specify baseflow/bucket model initialization (0=cold start from table, 1=restart file)\n GW_RESTART = 1 !<-- Specify whether to initialize the groundwater bucket states from the hydro\n ! restart file (option 1) or \"cold\" start the bucket states from the parameter\n ! table, GWBUCKPARM.nc.\n\n !!!! ------------ MODEL OUTPUT CONTROL ------------ !!!!\n ! Specify the output file write frequency...(minutes)\n out_dt = 60 !<-- Timestep for hydro model outputs, in minutes. This covers all output options\n ! listed below (CHRTOUT, GWOUT, RTOUT, LAKEOUT, etc.) so be cognizant of impacts\n ! on disk space and runtime when specifying.\n\n ! Specify the number of output times to be contained within each output history file...(integer)\n ! Currently only 1 and 0 are valid options. 1 will output a single file per timestep.\n ! 0 will output the CHANOBS file only as a single file over the run duration; other\n ! files will be one file per timestep.\n SPLIT_OUTPUT_COUNT = 1 !<-- Number of timesteps to put in a single output file.\n ! 1 = one file per timestep\n ! 0 = same as option 1 but there will be one file for the\n ! full run duration for CHANOBS only\n\n ! Specify the minimum stream order to output to netCDF point file (integer)\n ! Note: lower value of stream order produces more output.\n order_to_write = 4 !<-- Lowest stream order to include in output files. Selecting 1 gives\n ! you output for every reach/channel cell, selecting a higher order number\n ! gives you fewer channel output elements.\n\n ! Flag to turn on/off new I/O routines:\n ! 0 = deprecated output routines (only use when running with the Noah LSM),\n ! 1 = with scale/offset/compression,\n ! 2 = with scale/offset/NO compression,\n ! 3 = compression only,\n ! 4 = no scale/offset/compression (default)\n io_form_outputs = 1 !<-- Specify which output option to use (NOTE: option 0 is the only\n ! supported option when running with the original Noah LSM)\n\n ! Realtime run configuration option:\n ! 0=all (default), 1=analysis, 2=short-range, 3=medium-range,\n ! 4=long-range, 5=retrospective,\n ! 6=diagnostic (includes all of 1-4 outputs combined)\n io_config_outputs = 1 !<-- Specify which configuration of output variables to generate\n ! (NOTE: not active when io_form_outputs=0)\n\n ! Option to write output files at time 0 (restart cold start time): 0=no, 1=yes (default)\n t0OutputFlag = 1 !<-- Select whether or not to create outputs at the initial timestep.\n\n ! Options to output channel & bucket influxes. Only active for UDMP_OPT=1.\n ! Nonzero choice requires that out_dt above matches NOAH_TIMESTEP in namelist.hrldas.\n ! 0=None (default), 1=channel influxes (qSfcLatRunoff, qBucket)\n ! 2=channel+bucket fluxes (qSfcLatRunoff, qBucket, qBtmVertRunoff_toBucket)\n ! 3=channel accumulations (accSfcLatRunoff, accBucket) *NOT TESTED*\n output_channelBucket_influx = 0 !<-- Select which additional channel and groundwater bucket\n ! outputs will be generated. These additional variables can\n ! be used to drive the channel-only model.\n\n ! Output netCDF file control - specify which outputs to generate for the run.\n\n CHRTOUT_DOMAIN = 1 !<-- Channel output variables (streamflow, velocity, head, etc.) as a netCDF\n ! point timeseries output at all channel points (1d) 0 = no output, 1 = output\n\n CHANOBS_DOMAIN = 0 !<-- NetCDF point timeseries at forecast points or gage points (defined in\n ! Route_Link.nc) 0 = no output, 1 = output\n\n CHRTOUT_GRID = 0 !<-- NetCDF grid of channel streamflow values (2d) 0 = no output, 1 = output\n ! NOTE: Not available with reach-based routing\n\n LSMOUT_DOMAIN = 0 !<-- NetCDF grid of variables passed between LSM and routing components (2d)\n ! (generally used for diagnostics only)\n ! 0 = no output, 1 = output NOTE: No scale_factor/add_offset available\n\n RTOUT_DOMAIN = 1 !<-- NetCDF grid of terrain routing variables on routing grid (2d)\n ! 0 = no output, 1 = output\n\n output_gw = 1 !<-- NetCDF groundwater output, 0 = no output, 1 = output\n ! Groundwater bucket outputs [level, inflow, outflow]\n\n outlake = 1 !<-- NetCDF grid of lake values (1d) 0 = no output, 1 = output !\n ! Lake output variables (if lakes are included in the domain) [level, inflow, outflow]\n\n frxst_pts_out = 0 !<-- ASCII text file of streamflow at forecast points or gage points\n ! (defined in Route_Link.nc), 0 = no output, 1 = output\n\n !!!! ---- PHYSICS OPTIONS AND RELATED SETTINGS ---- !!!!\n\n ! Specify the number of soil layers (integer) and the depth of the bottom of each layer... (meters)\n ! Notes: In the current version of WRF-Hydro these must be the same as in the namelist.input file.\n ! Future versions may permit this to be different.\n NSOIL=4 !<-- Number of soil layers\n ZSOIL8(1) = -0.10 !<-- Depth of bottom boundary of top soil layer in meters\n ZSOIL8(2) = -0.40 !<-- Depth of bottom of second soil layer in meters (note that this is specified\n ! differently than the namelist.hrldas; this is total depth from the surface\n instead of thickness)\n ZSOIL8(3) = -1.00 !<-- Depth of bottom of third soil layer in meters (note that this is specified\n ! differently than the namelist.hrldas; this is total depth from the surface\n instead of thickness)\n ZSOIL8(4) = -2.00 !<-- Depth of bottom of fourth (last) soil layer in meters (note that this is\n ! specified differently than the namelist.hrldas; this is total depth from the\n surface instead of thickness)\n\n ! Specify the grid spacing of the terrain routing grid (meters)\n DXRT = 100.0 !<-- Resolution of the high-res routing grid\n ! Specify the integer multiple between the land model grid and the terrain routing grid (integer)\n AGGFACTRT = 10 !<-- Aggregation factor between the high-res routing grid and the LSM grid;\n ! e.g., a 100-m routing grid resolution and a 1km LSM grid resolution would\n ! be AGGFACTRT = 10.\n\n ! Specify the channel routing model timestep (seconds)\n DTRT_CH = 10 !<-- Timestep for the channel routing module to cycle, in seconds; model runtime\n ! will be sensitive to this timestep, so choose something appropriate for your\n ! domain resolution (finer resolutions generally require finer timesteps).\n ! Specify the terrain routing model timestep (seconds)\n DTRT_TER = 10 !<-- Timestep for the terrain routing module to cycle, in seconds; model runtime\n ! will be sensitive to this timestep, so choose something appropriate for your\n ! domain resolution (finer resolutions generally require finer timesteps).\n\n ! Switch to activate subsurface routing...(0=no, 1=yes)\n SUBRTSWCRT = 1 !<-- Turn on/off subsurface routing module.\n ! Switch to activate surface overland flow routing...(0=no, 1=yes)\n OVRTSWCRT = 1 !<-- Turn on/off overland routing module.\n\n ! Specify overland flow routing option:\n ! 1=Seepest Descent (D8) 2=CASC2D (not active)\n ! NOTE: Currently subsurface flow is only steepest descent\n rt_option = 1 !<-- For both terrain routing modules, specify whether flow should follow the\n ! steepest path (option 1) or multi-directional (option 2).\n ! Option 2 is currently unsupported.\n\n ! Specify whether to adjust overland flow parameters based on imperviousness\n imperv_adj = 0 !<-- When overland routing is active and an imperviousness grid is\n ! provided in Fulldom_hires.nc, you can use this option to reduce\n ! the overland roughness and maximum retention depth based on the\n ! impervious fraction.\n ! 0 = no adjustment, 1 = activate parameter adjustments\n\n\n ! Switch to activate channel routing...(0=no, 1=yes)\n CHANRTSWCRT = 1 !<-- Turn on/off channel routing module.\n\n ! Specify channel routing option:\n ! 1=Muskingam-reach, 2=Musk.-Cunge-reach, 3=Diff.Wave-gridded\n channel_option = 3 !<-- If channel routing module is active, select which physics option to use.\n\n ! Specify the reach file for reach-based routing options (e.g.: \"Route_Link.nc\")\n route_link_f = \"./DOMAIN/Route_Link.nc\" !<-- If using one of the reach-based channel routing\n ! options (channel_option = 1 or 2), specify the path\n ! to the Route_Link.nc file, which provides the\n ! channel-reach parameters.\n\n ! If using channel_option=2, activate the compound channel formulation? (Default=.FALSE.)\n ! This option is currently only supported if using reach-basedrouting with UDMP=1.\n compound_channel = .FALSE. !<-- Turn on or off the compound channel formulation.\n ! This option only works with Muskingum-Cunge reach-based\n ! routing with UDMP=1. This option also requires additional\n ! parameters in the routelink file.\n\n ! Switch to activate channel-loss option (0=no, 1=yes) [Requires Kchan in RouteLink]\n ! channel_loss_option = 0 !<-- Turn on or off channel loss. Note that the channel loss\n ! scheme currently only works for Muskingum-Cunge reach-based\n ! channel routing. Also note that activating channel loss will\n ! create a sink in the model, so the water budget will not close.\n ! By default this option is off.\n\n ! Lake / Reservoir options (0=lakes off, 1=level pool (typical default),\n ! 2=passthrough, 3=reservoir DA [see &reservoir_nlist below])\n lake_option = 1 !<-- Set the lake/reservoir option. Note that different options may\n ! require different domain/parameter/input files. Option 0 (lakes off)\n ! will not generate reasonable results for gridded channel routing\n ! domains where lake cells mask out channel cells.\n\n ! Specify the lake parameter file (e.g.: \"LAKEPARM.nc\"). Note: REQUIRED if lakes are on.\n route_lake_f = \"./DOMAIN/LAKEPARM.nc\" !<-- If lakes are active, specify the path to the lake\n ! parameter file, which provides the lake parameters.\n\n ! Switch to activate baseflow bucket model...(0=none, 1=exp. bucket, 2=pass-through,\n ! 4=exp. bucket with area normalized parameters)\n ! Option 4 is currently only supported if using reach-based routing with UDMP=1.\n GWBASESWCRT = 1 !<-- Turn on/off the ground water bucket module. Option 1 activates the\n ! exponential bucket model, Option 2 bypasses the bucket model and dumps all\n ! flow from the bottom of the soil column directly into the channel, and\n ! Option 4 is a variation of the exponential bucket model (option 1) where\n ! the coefficient is scaled by catchment area and only works for UDMP=1.\n ! Option 0 creates a sink at the bottom of the soil column (water draining from\n ! the bottom of the soil column leaves the system, so note that this option will\n ! not have water balance closure).\n\n ! Groundwater/baseflow 2d mask specified on land surface model grid (e.g.: \"GWBASINS.nc\").\n ! NOTE: Only required if baseflow model is active (1 or 2) and UDMP_OPT=0.\n gwbasmskfil = \"./DOMAIN/GWBASINS.nc\" !<-- For configurations where the bucket or pass-through\n ! groundwater modules are active, provide the path to the\n ! 2d netCDF file (LSM grid resolution) that maps the\n ! groundwater basin IDs. Bucket parameters will be specified\n ! through the GWBUCKPARM.nc file, whose IDs should match\n ! those in the groundwater basin mask file.\n\n ! Groundwater bucket parameter file (e.g.: \"GWBUCKPARM.nc\")\n GWBUCKPARM_file = \"./DOMAIN/GWBUCKPARM.nc\" !<-- For configurations where the groundwater bucket\n ! model is active, specify the path to the bucket\n ! parameter file, which provides bucket parameters\n ! by catchment.\n\n ! User defined mapping, such NHDPlus: 0=no (default), 1=yes\n UDMP_OPT = 0 !<-- If 1, this tells the model to use a \"user-defined mapping\" scheme to translate\n ! between terrain and groundwater flow and reaches, e.g., NHDPlus.\n\n ! If user-define mapping is on, specify the user-defined mapping file (e.g.: \"spatialweights.nc\")\n !udmap_file = \"./DOMAIN/spatialweights.nc\" !<-- If UDMP_OPT=1 (user defined mapping is active),\n ! provide the path to the required spatial weights\n ! file, which maps between grid cells and catchments.\n\n / !<-- End of hydro namelist HYDRO_nlist\n\n &NUDGING_nlist !<-- Start of separate namelist for nudging, only used if the model is compiled\n ! with the compile-time option WRF_HYDRO_NUDGING=1. Ignored otherwise.\n\n ! Path to the \"timeslice\" observation files.\n timeSlicePath = \"./nudgingTimeSliceObs/\" !<-- Path to a directory containing nuding “time slice”\n ! observation files. There are no requirements on the\n ! existence of files in the directory, but the directory\n ! itself must exist if specified.\n nudgingParamFile = \"DOMAIN/nudgingParams.nc\" !<-- Path to the required nudging parameter file.\n ! Nudging restart file. nudgingLastObsFile defaults to '', which will look for\n ! nudgingLastObs.YYYY-mm-dd_HH:MM:SS.nc *AT THE INITALIZATION TIME OF THE RUN*. Set to a missing\n ! file to use no restart.\n !nudgingLastObsFile = '/a/nonexistent/file/gives/nudging/cold/start' !<-- Optional path to an\n ! optional nudging restart\n ! file. See comments above.\n ! Parallel input of nudging timeslice observation files?\n readTimesliceParallel = .TRUE. !<-- Can read the observation files in parallel (on different cores)\n ! for quicker run speeds.\n\n ! temporalPersistence defaults to true, only runs if necessary params present.\n temporalPersistence = .FALSE. !<-- This option uses the expCoeff\n ! parameter for persisting observations\n\n ! The total number of last (obs, modeled) pairs to save in nudgingLastObs for removal of bias.\n ! This is the maximum array length. (This option is active when persistBias=FALSE)\n ! (Default=960=10days @15min obs resolution, if all the obs are present and longer if not.)\n nLastObs = 960 !<-- The maximum trailing window size for calculating bias correction.\n\n ! If using temporalPersistence the last observation persists by default. This option instead\n ! persists the bias after the last observation.\n persistBias = .FALSE. !<-- Apply bias correction as observations move into the past?\n ! AnA (FALSE) vs Forecast (TRUE) bias persistence.\n\n ! If persistBias: Does the window for calculating the bias end at model init time (=t0)?\n ! FALSE = window ends at model time (moving),\n ! TRUE = window ends at init=t0(fcst) time.\n ! (If commented out, Default=FALSE)\n ! Note: Perfect restart tests require this option to be .FALSE.\n biasWindowBeforeT0 = .FALSE. !<-- Is the bias window shifting with\n ! model integration?\n\n ! If persistBias: Only use this many last (obs, modeled) pairs.\n ! (If Commented out, Default=-1*nLastObs)\n ! > 0: apply an age-based filter, units=hours.\n ! = 0: apply no additional filter, use all available/usable obs.\n ! < 0: apply an count-based filter, units=count\n maxAgePairsBiasPersist = -960\n\n ! If persistBias: The minimum number of last (obs, modeled) pairs, with age less\n ! than maxAgePairsBiasPersist, required to apply a bias correction. (default=8)\n minNumPairsBiasPersist = 8\n\n ! If persistBias: give more weight to observations closer in time? (default=FALSE)\n invDistTimeWeightBias = .TRUE. !<-- The exact form of this\n ! weighting is currently hard-coded.\n\n ! If persistBias: \"No constructive interference in bias correction?\", reduce the bias\n ! adjustment when the model and the bias adjustment have the same sign relative to the\n ! modeled flow at t0? (default=FALSE)\n ! Note: Perfect restart tests require this option to be .FALSE.\n noConstInterfBias = .FALSE. !<-- Tactical response to phase errors.\n /\n\n.. _section-a7:\n\nA7. Static input files for WRF-Hydro\n-------------------------------------\n\nThe WRF-Hydro model requires several static input files to define the spatial domain and\nits parameters. These include two files in common with the WRF Model, :file:`geo_em.d01.nc`\nand :file:`wrfinput.d01.nc`, as well as the WRF-Hydro routing domain file :file:`Fulldom_hires.nc`.\n\nThe variables in these netCDF files are listed in the tables below:\n\n .. csv-table:: :file:`geo_em.d{X}.nc` `\\qquad` *geo_em*\n :file: input-tables/geo_em.tsv\n :delim: tab\n :header-rows: 1\n\n \\\n\n\n .. csv-table:: :file:`wrfinput.d{X}.nc` `\\qquad` *WRFINPUT*\n :file: input-tables/wrfinput.tsv\n :delim: tab\n :header-rows: 1\n\n \\\n\n\n .. csv-table:: :file:`Fulldom_hires.nc` `\\qquad` *Fulldom_Hires*\n :file: input-tables/Fulldom_hires.tsv\n :delim: tab\n :header-rows: 1\n\n.. _section-a8:\n\nA8. Noah land surface model parameter tables\n--------------------------------------------\n\nThe Noah land surface model requires three parameter table files denoted\nby the file suffix TBL. The variables contained within these files are\ndescribed in the tables below.\n\nPlease refer to the Noah land surface model documentation\n(https://ral.ucar.edu/sites/default/files/public/product-tool/unified-noah-lsm/Noah_LSM_USERGUIDE_2.7.1.pdf)\nfor additional information.\n\n`GENPARM.TBL` - This file contains global parameters for the Noah land surface model.\n\n.. table::\n :width: 90%\n :align: center\n\n +--------------------+-------------------------------------------------+\n | **Variable name** | **Description** |\n +====================+=================================================+\n | SLOPE_DATA | Linear reservoir coefficient |\n +--------------------+-------------------------------------------------+\n | SBETA_DATA | Parameter used to calculate vegetation effect |\n | | on soil heat |\n +--------------------+-------------------------------------------------+\n | FXEXP_DAT | Soil evaporation exponent used in DEVAP |\n +--------------------+-------------------------------------------------+\n | CSOIL_DATA | Soil heat capacity [:math:`J/m^3/K`] |\n +--------------------+-------------------------------------------------+\n | SALP_DATA | Shape parameter of distribution function of |\n | | snow cover |\n +--------------------+-------------------------------------------------+\n | REFDK_DATA | Parameter in the surface runoff |\n | | parameterization |\n +--------------------+-------------------------------------------------+\n | REFKDT_DATA | Parameter in the surface runoff |\n | | parameterization |\n +--------------------+-------------------------------------------------+\n | FRZK_DATA | Frozen ground parameter |\n +--------------------+-------------------------------------------------+\n | ZBOT_DATA | Depth of lower boundary soil temperature |\n | | [:math:`m`] |\n +--------------------+-------------------------------------------------+\n | CZIL_DATA | Parameter used in the calculation of the |\n | | roughness length for heat |\n +--------------------+-------------------------------------------------+\n | SMLOW_DATA | Soil moisture wilt, soil moisture reference |\n | | parameter |\n +--------------------+-------------------------------------------------+\n | SMHIGH_DATA | Soil moisture wilt, soil moisture reference |\n | | parameter |\n +--------------------+-------------------------------------------------+\n | LVCOEF_DATA | Parameter in the snow albedo formulation |\n +--------------------+-------------------------------------------------+\n\n| `SOILPARM.TBL` - This file contains parameters that are assigned based\n upon soil classification.\n| *All parameters are a function of soil class.*\n\n.. table::\n :width: 90%\n :align: center\n\n +-------------+--------------------------------------------------------+\n | **Variable | **Description** |\n | name** | |\n +=============+========================================================+\n | BB | B parameter |\n +-------------+--------------------------------------------------------+\n | DRYSMC | Dry soil moisture threshold at which direct |\n | | evaporation from top soil layer ends |\n +-------------+--------------------------------------------------------+\n | F11 | Soil thermal diffusivity/conductivity coefficient |\n +-------------+--------------------------------------------------------+\n | MAXSMC | Saturation soil moisture content (i.e. porosity) |\n +-------------+--------------------------------------------------------+\n | REFSMC | Reference soil moisture (field capacity), where |\n | | transpiration begins to stress |\n +-------------+--------------------------------------------------------+\n | SATPSI | Saturation soil matric potential |\n +-------------+--------------------------------------------------------+\n | SATDK | Saturation soil conductivity |\n +-------------+--------------------------------------------------------+\n | SATDW | Saturation soil diffusivity |\n +-------------+--------------------------------------------------------+\n | WLTSMC | Wilting point soil moisture |\n +-------------+--------------------------------------------------------+\n | QTZ | Soil quartz content |\n +-------------+--------------------------------------------------------+\n\n| `VEGPARM.TBL` - This file contains parameters that a function of land cover type.\n| *All parameters are a function of land cover type.*\n\n.. table::\n :width: 90%\n :align: center\n\n +-------------------+---------------------------------------------------------+\n | **Variable name** | **Description** |\n +===================+=========================================================+\n | SHDFAC | Green vegetation fraction |\n +-------------------+---------------------------------------------------------+\n | NROOT | Number of soil layers (from the top) reached by |\n | | vegetation roots |\n +-------------------+---------------------------------------------------------+\n | RS | Minimum stomatal resistance [`s/m`] |\n +-------------------+---------------------------------------------------------+\n | RGL | Parameter used in radiation stress function |\n +-------------------+---------------------------------------------------------+\n | HS | Parameter used in vapor pressure deficit function |\n +-------------------+---------------------------------------------------------+\n | SNUP | Threshold water-equivalent snow depth [m] that implies |\n | | 100% snow cover |\n +-------------------+---------------------------------------------------------+\n | MAXALB | Upper bound on maximum albedo over deep snow [`\\%`] |\n +-------------------+---------------------------------------------------------+\n | LAIMIN | Minimum leaf area index through the year |\n | | [dimensionless] |\n +-------------------+---------------------------------------------------------+\n | LAIMAX | Maximum leaf area index through the year |\n | | [dimensionless] |\n +-------------------+---------------------------------------------------------+\n | EMISSMIN | Minimum background emissivity through the year |\n | | [fraction 0.0 to 1.0] |\n +-------------------+---------------------------------------------------------+\n | EMISSMAX | Maximum background emissivity through the year |\n | | [fraction 0.0 to 1.0] |\n +-------------------+---------------------------------------------------------+\n | ALBEDOMIN | Minimum background albedo through the year [fraction |\n | | 0.0 to 1.0] |\n +-------------------+---------------------------------------------------------+\n | ALBEDOMAX | Maximum background albedo through the year [fraction |\n | | 0.0 to 1.0] |\n +-------------------+---------------------------------------------------------+\n | Z0MIN | Minimum background roughness length through the year |\n | | [`m`] |\n +-------------------+---------------------------------------------------------+\n | Z0MAX | Maximum background roughness length through the year |\n | | [`m`] |\n +-------------------+---------------------------------------------------------+\n | TOPT_DATA | Optimum transpiration air temperature [`K`] |\n +-------------------+---------------------------------------------------------+\n | CMCMAX_DATA | Maximum canopy water capacity [volumetric fraction] |\n | | |\n +-------------------+---------------------------------------------------------+\n | CFACTR_DATA | Parameter used in the canopy interception calculation |\n | | [dimensionless] |\n +-------------------+---------------------------------------------------------+\n | RSMAX_DATA | Maximal stomatal resistance [`s/m`] |\n +-------------------+---------------------------------------------------------+\n | BARE | The land-use category representing bare ground (used to |\n | | set the vegetation fraction to zero) [land-use category |\n | | index] |\n +-------------------+---------------------------------------------------------+\n | NATURAL | The land-use category representative of the non-urban |\n | | portion of urban land-use points [land-use category |\n | | index] |\n +-------------------+---------------------------------------------------------+\n\n.. _section-a9:\n\nA9. Noah-MP land surface model parameter tables\n-----------------------------------------------\n\nThe Noah-MP land surface model requires three parameter table files\ndenoted by the file suffix TBL. The variables contained within these\nfiles are described in the tables below.\n\nAs part of the work conducted for the National Water Model\nimplementation, the ability to specify a number of these land surface\nmodel parameters spatially on a two or three dimensional grid was\nintroduced. This is done through the use of the compile time option\n``SPATIAL_SOIL`` and the specification of a netCDF format parameter file\nwith the default filename soil_properties.nc. A list of the variables\ncontained in this file is included in a table below as well.\n\n`GENPARM.TBL` This file contains global parameters for the Noah-MP\nland surface model.\n\n.. table::\n :width: 90%\n :align: center\n\n +---------------+------------------------------------------------------+\n | **Variable | **Description** |\n | name** | |\n +===============+======================================================+\n | SLOPE_DATA | Linear reservoir coefficient |\n +---------------+------------------------------------------------------+\n | SBETA_DATA | Parameter used to calculate vegetation effect on |\n | | soil heat |\n +---------------+------------------------------------------------------+\n | FXEXP_DAT | Soil evaporation exponent used in DEVAP |\n +---------------+------------------------------------------------------+\n | CSOIL_DATA | Soil heat capacity [:math:`J/m^3/K`] |\n +---------------+------------------------------------------------------+\n | SALP_DATA | Shape parameter of distribution function of snow |\n | | cover |\n +---------------+------------------------------------------------------+\n | REFDK_DATA | Parameter in the surface runoff parameterization |\n +---------------+------------------------------------------------------+\n | REFKDT_DATA | Parameter in the surface runoff parameterization |\n +---------------+------------------------------------------------------+\n | FRZK_DATA | Frozen ground parameter |\n +---------------+------------------------------------------------------+\n | ZBOT_DATA | Depth of lower boundary soil temperature [:math:`m`] |\n +---------------+------------------------------------------------------+\n | CZIL_DATA | Parameter used in the calculation of the roughness |\n | | length for heat |\n +---------------+------------------------------------------------------+\n | SMLOW_DATA | Soil moisture wilt, soil moisture reference |\n | | parameter |\n +---------------+------------------------------------------------------+\n | SMHIGH_DATA | Soil moisture wilt, soil moisture reference |\n | | parameter |\n +---------------+------------------------------------------------------+\n | LVCOEF_DATA | Parameter in the snow albedo formulation |\n +---------------+------------------------------------------------------+\n\n`SOILPARM.TBL` - This file contains parameters that are assigned based\non soil classification.\n\n.. table::\n :width: 90%\n :align: center\n\n +--------------+-------------------------------------------------------+\n | **Variable | **Description** |\n | name** | |\n +==============+=======================================================+\n | BB | B parameter |\n +--------------+-------------------------------------------------------+\n | DRYSMC | Dry soil moisture threshold at which direct |\n | | evaporation from top soil layer ends |\n +--------------+-------------------------------------------------------+\n | F11 | Soil thermal diffusivity/conductivity coefficient |\n +--------------+-------------------------------------------------------+\n | MAXSMC | Saturation soil moisture content (i.e. porosity) |\n +--------------+-------------------------------------------------------+\n | REFSMC | Reference soil moisture (field capacity), where |\n | | transpiration begins to stress |\n +--------------+-------------------------------------------------------+\n | SATPSI | Saturation soil matric potential |\n +--------------+-------------------------------------------------------+\n | SATDK | Saturation soil conductivity |\n +--------------+-------------------------------------------------------+\n | SATDW | Saturation soil diffusivity |\n +--------------+-------------------------------------------------------+\n | WLTSMC | Wilting point soil moisture |\n +--------------+-------------------------------------------------------+\n | QTZ | Soil quartz content |\n +--------------+-------------------------------------------------------+\n | AXAJ | Tension water distribution inflection parameter |\n +--------------+-------------------------------------------------------+\n | BXAJ | Tension water distribution shape parameter |\n +--------------+-------------------------------------------------------+\n | XXAJ | Free water distribution shape parameter |\n +--------------+-------------------------------------------------------+\n\n`MPTABLE.TBL` - This file contains parameters that are a function of\nland cover type.\n\n.. table::\n :width: 90%\n :align: center\n\n +-------------------------+--------------------------------------------+\n | **Variable name** | **Description** |\n +=========================+============================================+\n | VEG_DATASET_DESCRIPTION | Land cover classification dataset |\n +-------------------------+--------------------------------------------+\n | NVEG | Number of land cover categories |\n +-------------------------+--------------------------------------------+\n | ISURBAN | Land cover category for urban |\n +-------------------------+--------------------------------------------+\n | ISWATER | Land cover category for water |\n +-------------------------+--------------------------------------------+\n | ISBARREN | Land cover category for barren |\n +-------------------------+--------------------------------------------+\n | ISICE | Land cover category for ice |\n +-------------------------+--------------------------------------------+\n | EBLFOREST | Land cover category for evergreen |\n | | broadleaf forest |\n +-------------------------+--------------------------------------------+\n | .. centered:: *Parameters below are a function of land cover type* |\n +-------------------------+--------------------------------------------+\n | CH2OP | Maximum intercepted H\\ :sub:`2`\\O per unit |\n | | LAI + SAI [:math:`mm`] |\n +-------------------------+--------------------------------------------+\n | DLEAF | Characteristic leaf dimension [:math:`m`] |\n +-------------------------+--------------------------------------------+\n | Z0MVT | Momentum roughness length [:math:`m`] |\n +-------------------------+--------------------------------------------+\n | HVT | Top of canopy [:math:`m`] |\n +-------------------------+--------------------------------------------+\n | HVB | Bottom of canopy [:math:`m`] |\n +-------------------------+--------------------------------------------+\n | DEN | Tree density [:math:`trunks/m^2`\\] |\n +-------------------------+--------------------------------------------+\n | RC | Tree crown radius [:math:`m`] |\n +-------------------------+--------------------------------------------+\n | MFSNO | Snowmelt m parameter |\n +-------------------------+--------------------------------------------+\n | RHOS_VIS | Monthly stem area index (SAI), one-sided |\n +-------------------------+--------------------------------------------+\n | RHOS_NIR | Monthly leaf area index (LAI), one-sided |\n +-------------------------+--------------------------------------------+\n | TAUL_VIS | Leaf transmittance, visible |\n +-------------------------+--------------------------------------------+\n | TAUL_NIR | Leaf transmittance, near infrared |\n +-------------------------+--------------------------------------------+\n | TAUS_VIS | Stem transmittance, visible |\n +-------------------------+--------------------------------------------+\n | TAUS_NIR | Stem transmittance, near infrared |\n +-------------------------+--------------------------------------------+\n | XL | Leaf / stem orientation index |\n +-------------------------+--------------------------------------------+\n | CWPVT | Canopy wind parameter |\n +-------------------------+--------------------------------------------+\n | C3PSN | Photosynthetic pathway [c4 = 0. \\| c3 = |\n | | 1.] |\n +-------------------------+--------------------------------------------+\n | KC25 | CO2 Michaelis-Menten constant |\n | | at 25°C [:math:`Pa`] |\n +-------------------------+--------------------------------------------+\n | AKC | Q10 for KC25 |\n +-------------------------+--------------------------------------------+\n | KO25 | O2 Michaelis-Menten constant |\n | | at 25°C [:math:`Pa`] |\n +-------------------------+--------------------------------------------+\n | AKO | Q10 for KO25 |\n +-------------------------+--------------------------------------------+\n | AVCMX | Q10 for VCMX25 |\n +-------------------------+--------------------------------------------+\n | AQE | Q10 for QE25 |\n +-------------------------+--------------------------------------------+\n | LTOVRC | Leaf turnover [:math:`1/s`] |\n +-------------------------+--------------------------------------------+\n | DILEFC | Coefficient for leaf stress death |\n | | [:math:`1/s`] |\n +-------------------------+--------------------------------------------+\n | DILEFW | Coefficient for leaf stress death |\n | | [:math:`1/s`] |\n +-------------------------+--------------------------------------------+\n | RMF25 | Leaf maintenance respiration at 25°C |\n | | [:math:`umol\\ CO_{2}/m^2/s`] |\n +-------------------------+--------------------------------------------+\n | SLA | Single-side leaf area [:math:`m2/kg`] |\n +-------------------------+--------------------------------------------+\n | FRAGR | Fraction of growth respiration |\n +-------------------------+--------------------------------------------+\n | TMIN | Minimum temperature for photosynthesis |\n | | [:math:`K`] |\n +-------------------------+--------------------------------------------+\n | VCMX25 | maximum rate of carboxylation at 25°C |\n | | [:math:`umol\\ CO_{2}/m^2/s`] |\n +-------------------------+--------------------------------------------+\n | TDLEF | Characteristic temperature for leaf |\n | | freezing [:math:`K`] |\n +-------------------------+--------------------------------------------+\n | BP | Minimum leaf conductance |\n | | [:math:`umol\\ /m^2/s`] |\n +-------------------------+--------------------------------------------+\n | MP | Slope of conductance to photosynthesis |\n | | relationship |\n +-------------------------+--------------------------------------------+\n | QE25 | Quantum efficiency at 25°C |\n | | [:math:`umol\\ CO_{2} / umol\\ photon`] |\n +-------------------------+--------------------------------------------+\n | RMS25 | Stem maintenance respiration at 25°C |\n | | [:math:`umol\\ CO_{2}/kg_{bio}/s`] |\n +-------------------------+--------------------------------------------+\n | RMR25 | Root maintenance respiration at 25°C |\n | | [:math:`umol\\ CO_{2}/kg_{bio}/s`] |\n +-------------------------+--------------------------------------------+\n | ARM | Q10 for maintenance respiration |\n +-------------------------+--------------------------------------------+\n | FOLNMX | Foliage nitrogen concentration when |\n | | :math:`f(n)=1` [:math:`\\%`] |\n +-------------------------+--------------------------------------------+\n | WRRAT | Wood to non-wood ratio |\n +-------------------------+--------------------------------------------+\n | MRP | Microbial respiration parameter |\n | | [:math:`umol\\ CO_{2}/kg_{C}/s`] |\n +-------------------------+--------------------------------------------+\n | NROOT | Number of soil layers with root present |\n +-------------------------+--------------------------------------------+\n | RGL | Parameter used in radiation stress |\n | | function |\n +-------------------------+--------------------------------------------+\n | RS | Stomatal resistance [:math:`s/m`] |\n +-------------------------+--------------------------------------------+\n | HS | Parameter used in vapor pressure deficit |\n | | function |\n +-------------------------+--------------------------------------------+\n | TOPT | Optimum transpiration air temperature [K] |\n +-------------------------+--------------------------------------------+\n | RSMAX | Maximal stomatal resistance |\n | | [:math:`s m-1`] |\n +-------------------------+--------------------------------------------+\n | SAI | Steam area index |\n +-------------------------+--------------------------------------------+\n | LAI | Leaf area index |\n +-------------------------+--------------------------------------------+\n | SLAREA | (not used in Noah-MP as configured in |\n | | WRF-Hydro) |\n +-------------------------+--------------------------------------------+\n | EPS1 | (not used in Noah-MP as configured in |\n | | WRF-Hydro) |\n +-------------------------+--------------------------------------------+\n | EPS2 | (not used in Noah-MP as configured in |\n | | WRF-Hydro) |\n +-------------------------+--------------------------------------------+\n | EPS3 | (not used in Noah-MP as configured in |\n | | WRF-Hydro) |\n +-------------------------+--------------------------------------------+\n | EPS4 | (not used in Noah-MP as configured in |\n | | WRF-Hydro) |\n +-------------------------+--------------------------------------------+\n | EPS5 | (not used in Noah-MP as configured in |\n | | WRF-Hydro) |\n +-------------------------+--------------------------------------------+\n | .. centered:: *Parameters below are a function of soil color index* |\n +-------------------------+--------------------------------------------+\n | ALBSAT_VIS | Saturated soil albedos for visible |\n +-------------------------+--------------------------------------------+\n | ALBSAT_NIR | Saturated soil albedos for near infrared |\n +-------------------------+--------------------------------------------+\n | ALBDRY_VIS | Dry soil albedos for visible |\n +-------------------------+--------------------------------------------+\n | ALBDRY_NIR | Dry soil albedos for near infrared |\n +-------------------------+--------------------------------------------+\n | .. centered:: *Parameters below are global* |\n +-------------------------+--------------------------------------------+\n | ALBICE | Albedo land ice (visible and near |\n | | infrared) |\n +-------------------------+--------------------------------------------+\n | ALBLAK | Albedo frozen lakes (visible and near |\n | | infrared) |\n +-------------------------+--------------------------------------------+\n | OMEGAS | Two-stream parameter for snow |\n +-------------------------+--------------------------------------------+\n | BETADS | Two-stream parameter for snow |\n +-------------------------+--------------------------------------------+\n | BETAIS | Two-stream parameter for snow |\n +-------------------------+--------------------------------------------+\n | EG | Emissivity soil surface (soil and lake) |\n +-------------------------+--------------------------------------------+\n | CO2 | CO\\ :sub:`2` partial pressure |\n +-------------------------+--------------------------------------------+\n | O2 | O\\ :sub:`2` partial pressure |\n +-------------------------+--------------------------------------------+\n | TIMEAN | Grid cell mean topographic index [global |\n | | mean] |\n +-------------------------+--------------------------------------------+\n | FSATMX | Maximum surface saturated fraction [global |\n | | mean] |\n +-------------------------+--------------------------------------------+\n | Z0SNO | Snow surface roughness length [:math:`m`] |\n +-------------------------+--------------------------------------------+\n | SSI | Liquid water holding capacity for snowpack |\n | | [:math:`m^3/m^3`] |\n +-------------------------+--------------------------------------------+\n | SWEMX | New snow mass to fully cover old snow |\n | | [:math:`mm`] |\n +-------------------------+--------------------------------------------+\n | TAU0 | Tau0 from Yang97 eqn. 10a |\n +-------------------------+--------------------------------------------+\n | GRAIN_GROWTH | Growth from vapor diffusion Yang97 |\n | | eqn. 10b |\n +-------------------------+--------------------------------------------+\n | EXTRA_GROWTH | Extra growth near freezing Yang97 |\n | | eqn. 10c |\n +-------------------------+--------------------------------------------+\n | DIRT_SOOT | Dirt and soot term Yang97 eqn. 10d |\n +-------------------------+--------------------------------------------+\n | BATS_COSZ | Zenith angle snow albedo |\n | | adjustment; b in Yang97 eqn. 15 |\n +-------------------------+--------------------------------------------+\n | BATS_VIS_NEW | New snow visible albedo |\n +-------------------------+--------------------------------------------+\n | BATS_NIR_NEW | New snow NIR albedo |\n +-------------------------+--------------------------------------------+\n | BATS_VIS_AGE | Age factor for diffuse visible snow |\n | | albedo Yang97 eqn. 17 |\n +-------------------------+--------------------------------------------+\n | BATS_NIR_AGE | Age factor for diffuse NIR snow |\n | | albedo Yang97 eqn. 18 |\n +-------------------------+--------------------------------------------+\n | BATS_VIS_DIR | Cosz factor for direct visible snow |\n | | albedo Yang97 eqn. 15 |\n +-------------------------+--------------------------------------------+\n | BATS_NIR_DIR | Cosz factor for direct NIR snow |\n | | albedo Yang97 eqn. 16 |\n +-------------------------+--------------------------------------------+\n | RSURF_SNOW | Surface resistance for snow [:math:`s/m`] |\n +-------------------------+--------------------------------------------+\n | RSURF_EXP | Exponent in the shape parameter for |\n | | soil resistance option 1 |\n +-------------------------+--------------------------------------------+\n | IMPERV_URBAN | impervious fraction to use for urban |\n | | type cells [0-1] |\n +-------------------------+--------------------------------------------+\n | SCAMAX | maximum fractional snow covered area [0-1] |\n +-------------------------+--------------------------------------------+\n | SWE_LIMIT | maximum SWE limit [mm] |\n +-------------------------+--------------------------------------------+\n\n`soil\\_properties.nc` [optional]\n\n.. table::\n :width: 90%\n :align: center\n\n +------------+----------------------------------------------------------+\n | **Variable | **Description** |\n | name** | |\n +============+==========================================================+\n | bexp | Beta parameter |\n +------------+----------------------------------------------------------+\n | cwpvt | Empirical canopy wind parameter |\n +------------+----------------------------------------------------------+\n | dksat | Saturated soil hydraulic conductivity |\n +------------+----------------------------------------------------------+\n | dwsat | Saturated soil hydraulic diffusivity |\n +------------+----------------------------------------------------------+\n | hvt | Top of vegetation canopy [:math:`m`] |\n +------------+----------------------------------------------------------+\n | mfsno | Snowmelt m parameter |\n +------------+----------------------------------------------------------+\n | mp | Slope of conductance to photosynthesis relationship |\n +------------+----------------------------------------------------------+\n | psisat | Saturated soil matric potential |\n +------------+----------------------------------------------------------+\n | quartz | Soil quartz content |\n +------------+----------------------------------------------------------+\n | refdk | Parameter in the surface runoff parameterization |\n +------------+----------------------------------------------------------+\n | refkdt | Parameter in the surface runoff parameterization |\n +------------+----------------------------------------------------------+\n | rsurf_exp | Exponent in the shape parameter for soil |\n | | resistance option 1 |\n +------------+----------------------------------------------------------+\n | slope | Slope index |\n +------------+----------------------------------------------------------+\n | smcdry | Dry soil moisture threshold where direction evaporation |\n | | from the top layer ends |\n +------------+----------------------------------------------------------+\n | smcmax | Saturated value of soil moisture [volumetric] |\n +------------+----------------------------------------------------------+\n | smcref | Reference soil moisture (field capacity) [volumetric] |\n +------------+----------------------------------------------------------+\n | smcwlt | Wilting point soil moisture [volumetric] |\n +------------+----------------------------------------------------------+\n | vcmx25 | Maximum rate of carboxylation at 25°C |\n | | [:math:`umol\\ CO_{2}/m^2/s`] |\n +------------+----------------------------------------------------------+\n | AXAJ | Tension water distribution inflection parameter |\n +------------+----------------------------------------------------------+\n | BXAJ | Tension water distribution shape parameter |\n +------------+----------------------------------------------------------+\n | XXAJ | Free water distribution shape parameter |\n +------------+----------------------------------------------------------+\n | rsurfsnow | Surface resistance for snow [s/m] |\n +------------+----------------------------------------------------------+\n | scamax | Maximum fractional snow covered area [0-1] |\n +------------+----------------------------------------------------------+\n | snowretfac | Snowpack water release timescale factor [1/s] |\n +------------+----------------------------------------------------------+\n | ssi | Liquid water holding capacity for snowpack |\n | | [:math:`m^3/m^3`] |\n +------------+----------------------------------------------------------+\n | tau0 | Snow albedo decay timescale parameter [s] |\n +------------+----------------------------------------------------------+\n | imperv | Impervious fraction (optional) [0-1] |\n +------------+----------------------------------------------------------+\n\n\n\n.. _section-a10:\n\nA10. Terrain routing parameter files\n------------------------------------\n\nParameters for the lateral routing component of WRF-Hydro are specified\nvia either the `HYDRO.TBL` file or the `hydro2dtbl.nc` file. Variables\nwithin these files are described in the tables below.\n\n`HYDRO.TBL`\n\n.. table::\n :width: 90%\n :align: center\n\n +--------------------+------------------------------------------------------+\n | **Variable name** | **Description** |\n +====================+======================================================+\n | .. centered:: *The parameter below is a function of land cover type* |\n +--------------------+------------------------------------------------------+\n | SFC_ROUGH | Overland flow roughness coefficient |\n +--------------------+------------------------------------------------------+\n | .. centered:: *The parameters below are a function of soil class* |\n +--------------------+------------------------------------------------------+\n | SATDK | Saturated soil hydraulic conductivity [:math:`m/s`] |\n +--------------------+------------------------------------------------------+\n | MAXSMC | Maximum volumetric soil moisture |\n | | [:math:`m^3/m^3`] |\n +--------------------+------------------------------------------------------+\n | REFSMC | Reference volumetric soil moisture |\n | | [:math:`m^3/m^3`] |\n +--------------------+------------------------------------------------------+\n | WLTSMC | Wilting point volumetric soil moisture |\n | | [:math:`m^3/m^3`] |\n +--------------------+------------------------------------------------------+\n | QTZ | Quartz fraction of the soil |\n +--------------------+------------------------------------------------------+\n\n`hydro2dtbl.nc`\n\n.. table::\n :width: 90%\n :align: center\n\n +-----------------------+----------------------------------------------+\n | **Variable name** | **Description** |\n +=======================+==============================================+\n | SMCMAX1 | Maximum volumetric soil moisture |\n | | [:math:`m^3/m^3`] |\n +-----------------------+----------------------------------------------+\n | SMCREF1 | Reference volumetric soil moisture |\n | | [:math:`m^3/m^3`] |\n +-----------------------+----------------------------------------------+\n | SMCWLT1 | Wilting point volumetric soil moisture |\n | | [:math:`m^3/m^3`] |\n +-----------------------+----------------------------------------------+\n | OV_ROUGH2D | Overland flow roughness coefficient |\n +-----------------------+----------------------------------------------+\n | LKSAT | Lateral saturated soil hydraulic |\n | | conductivity [:math:`m/s`] |\n +-----------------------+----------------------------------------------+\n | NEXP | Exponent in the decay function for lateral |\n | | Ksat over depth |\n +-----------------------+----------------------------------------------+\n\n\n.. _section-a11:\n\nA11. Channel routing parameter tables (`CHANPARM.TBL` and `Route\\_Link.nc`)\n---------------------------------------------------------------------------\n\nVariables of the the channel routing parameter tables are described in\nthe tables below.\n\n| `CHANPARM.TBL`\n| *All parameters are a function of Strahler stream order*\n\n.. table::\n :width: 90%\n :align: center\n\n +----------------------+---------------------------------------------------+\n | **Variable name** | **Description** |\n +======================+===================================================+\n | Bw | Channel bottom width [:math:`m`] |\n +----------------------+---------------------------------------------------+\n | HLINK | Initial depth of water in the channel [:math:`m`] |\n +----------------------+---------------------------------------------------+\n | ChSSlp | Channel side slope [:math:`m/m`] |\n +----------------------+---------------------------------------------------+\n | MannN | Manning’s roughness coefficient |\n +----------------------+---------------------------------------------------+\n\n| `Route\\_Link.nc`\n| *All parameters are specified per stream specified per stream segment (i.e. link)*\n\n.. table::\n :width: 90%\n :align: center\n\n +----------------------+-----------------------------------------------+\n | **Variable name** | **Description** |\n +======================+===============================================+\n | BtmWdth | Channel bottom width [:math:`m`] |\n +----------------------+-----------------------------------------------+\n | ChSlp | Channel side slope [:math:`m/m`] |\n +----------------------+-----------------------------------------------+\n | Kchan | Channel conductivity [:math:`mm/hr`] |\n +----------------------+-----------------------------------------------+\n | Length | Stream segment length [:math:`m`] |\n +----------------------+-----------------------------------------------+\n | MusK | Muskingum routing time [:math:`s`] |\n +----------------------+-----------------------------------------------+\n | MusX | Muskingum weighting coefficient |\n +----------------------+-----------------------------------------------+\n | NHDWaterbodyComID | ComID of an associated water body if any |\n +----------------------+-----------------------------------------------+\n | Qi | Initial flow in link [:math:`m^3/s`] |\n +----------------------+-----------------------------------------------+\n | So | Slope [:math:`m/m`] |\n +----------------------+-----------------------------------------------+\n | alt | Elevation from the NAD88 datum at start node |\n | | [:math:`m`] |\n +----------------------+-----------------------------------------------+\n | ascendingIndex | Index to user for sorting IDs - *only in NWM |\n | | files* |\n +----------------------+-----------------------------------------------+\n | from | From Link ID |\n +----------------------+-----------------------------------------------+\n | gages | Identifier for stream gage at this location |\n +----------------------+-----------------------------------------------+\n | lat | Latitude of the segment midpoint *[degrees |\n | | north]* |\n +----------------------+-----------------------------------------------+\n | link | Link ID |\n +----------------------+-----------------------------------------------+\n | lon | Longitude of the segment midpoint *[degrees |\n | | east]* |\n +----------------------+-----------------------------------------------+\n | n | Manning's roughness |\n +----------------------+-----------------------------------------------+\n | nCC | Compound Channel Manning's roughness |\n +----------------------+-----------------------------------------------+\n | order | Strahler stream order |\n +----------------------+-----------------------------------------------+\n | to | To Link ID |\n +----------------------+-----------------------------------------------+\n | time | Time of measurement |\n +----------------------+-----------------------------------------------+\n | TopWdth | Top Width [m] |\n +----------------------+-----------------------------------------------+\n | TopWdthCC | Compound Channel Top Width [m] |\n +----------------------+-----------------------------------------------+\n\n.. _section-a12:\n\nA12. Groundwater input and parameter files\n------------------------------------------\n\nThe contents of the groundwater input and parameter files are described\nin the tables below.\n\n`GWBASINS.nc`\n\n.. table::\n :width: 90%\n :align: center\n\n +----------------------+-----------------------------------------------+\n | **Variable name** | **Description** |\n +======================+===============================================+\n | y | projection y coordinate |\n +----------------------+-----------------------------------------------+\n | x | projection x coordinate |\n +----------------------+-----------------------------------------------+\n | crs | coordinate reference system definition |\n +----------------------+-----------------------------------------------+\n | BASIN | groundwater basin ID |\n +----------------------+-----------------------------------------------+\n\n`GWBUCKPARM.nc`\n\n.. table::\n :width: 90%\n :align: center\n\n +-----------------------+----------------------------------------------+\n | **Variable name** | **Description** |\n +=======================+==============================================+\n | Basin | Basin monotonic ID (1...n) |\n +-----------------------+----------------------------------------------+\n | Coeff | Coefficient |\n +-----------------------+----------------------------------------------+\n | Expon | Exponent |\n +-----------------------+----------------------------------------------+\n | Zmax | Zmax |\n +-----------------------+----------------------------------------------+\n | Zinit | Zinit |\n +-----------------------+----------------------------------------------+\n | Area_sqkm | Basin area [:math:`km^2`] |\n +-----------------------+----------------------------------------------+\n | ComID | NHDCatchment FEATUREID (NHDFlowline ComID) |\n +-----------------------+----------------------------------------------+\n | Loss | Fraction of bucket output lost |\n +-----------------------+----------------------------------------------+\n\n.. _section-a13:\n\nA13. Spatial weights input file variable description\n----------------------------------------------------\n\nThe contents of the `spatialweights.nc` file is described in the table\nbelow.\n\n.. table::\n :width: 90%\n :align: center\n\n +--------------+---------------------------------------------+---------------+\n | **Variable | **Description** | **Dimension** |\n | name** | | |\n +==============+=============================================+===============+\n | polyid | ID of polygon | polyid |\n +--------------+---------------------------------------------+---------------+\n | IDmask | Polygon ID (polyid) associated with each | data |\n | | record) | |\n +--------------+---------------------------------------------+---------------+\n | overlaps | Number of intersecting polygons | polyid |\n +--------------+---------------------------------------------+---------------+\n | weight | Fraction of intersecting polygon(polyid) | data |\n | | intersected by poly2 | |\n +--------------+---------------------------------------------+---------------+\n | regridweight | Fraction of intersecting | data |\n | | polyid(overlapper) intersected by | |\n | | polygon(polyid) | |\n +--------------+---------------------------------------------+---------------+\n | i_index | Index in the x dimension of the raster | data |\n | | grid *(starting with 1,1 in the LL corner)* | |\n +--------------+---------------------------------------------+---------------+\n | j_index | Index in the y dimension of the raster | data |\n | | grid *(starting with 1,1 in the LL corner)* | |\n +--------------+---------------------------------------------+---------------+\n\n.. _section-a14:\n\nA14. Lake and reservoir parameter tables (`LAKEPARM.nc`)\n--------------------------------------------------------\n\nVariables within the `LAKEPARM.nc` file are described in the tables below.\n\n.. table::\n :width: 90%\n :align: center\n\n +--------------------+-------------------------------------------------+\n | **Variable name** | **Description** |\n +====================+=================================================+\n | lake_id | Lake index (consecutively from 1 to n # of |\n | | lakes) |\n +--------------------+-------------------------------------------------+\n | LkArea | Area [:math:`m^2`] |\n +--------------------+-------------------------------------------------+\n | LkMxE | Elevation of maximum lake height [:math:`m`, |\n | | AMSL] |\n +--------------------+-------------------------------------------------+\n | WeirC | Weir coefficient (ranges from zero to one) |\n +--------------------+-------------------------------------------------+\n | WeirL | Weir length [:math:`m`] |\n +--------------------+-------------------------------------------------+\n | WeirE | Weir elevation [:math:`m`, AMSL] |\n +--------------------+-------------------------------------------------+\n | OrificeC | Orifice coefficient (ranges from zero to one) |\n +--------------------+-------------------------------------------------+\n | OrificeA | Orifice area [:math:`m^2`] |\n +--------------------+-------------------------------------------------+\n | OrificeE | Orifice elevation [:math:`m`, AMSL] |\n +--------------------+-------------------------------------------------+\n | Dam_Length | Dam length as a multiplier on WeirL [multiplier]|\n +--------------------+-------------------------------------------------+\n | lat | Latitude *[decimal degrees north]* |\n +--------------------+-------------------------------------------------+\n | lon | Longitude *[decimal degrees east]* |\n +--------------------+-------------------------------------------------+\n | time | time |\n +--------------------+-------------------------------------------------+\n | ascendingIndex | Index to use for sorting IDs (ascending) |\n +--------------------+-------------------------------------------------+\n | ifd | Initial fraction water depth |\n +--------------------+-------------------------------------------------+\n | crs | CRS definition |\n +--------------------+-------------------------------------------------+\n\n.. _section-a15:\n\nA15. Restart Files Overview\n---------------------------\n\n**Cold start versus warm start model simulations:**\n\nWhen one start the model as a `cold start` (meaning that it is starting with the default values at the very\nbeginning), it takes time for the model to warm up and reach an equilibrium state. For example, consider\nsimulating streamflow values for a stream which has a base flow of at least 10 cms during the year, and you\nhave a `cold start`. The default values of the streamflow might be zeros at the start of the modeling. It then\ntakes time for the simulated streamflow within the model to reach the 10 cms. In contrast, a `warm start` is\nwhen the model simulation begins with the simulated values of a given time step (starting time step) from a\nprevious run. This eliminates the processing time the model would take to reach an equilibrium state.\nDepending on which variable of the model you are looking at, the time required to reach to the warm state may\ndiffer. For example, groundwater requires a longer time period to reach to equilibrium.\n\n**How to do a warm start simulations with WRF-Hydro?**\n\nWRF-Hydro model outputs two set of model restart files (:file:`RESTART.YYYYmmddHH_DOMAIN` and\n:file:`HYDRO_RST.YYYY-mm-dd_HH:MM_DOMAIN1`) which store the model states at a specified time and\ncould be used to start the model from that point in time. :file:`RESTART.YYYYmmddHH_DOMAIN` stores the\nstate variables reqiured for restarting LSM and :file:`HYDRO_RST.YYYY-mm-dd_HH:MM_DOMAIN`\nstores the state variables required to resume the hydro components of the WRF-Hydro model.\n\nTo warm start the LSM part of the model, specify path to the restart file in the :file:`namelist.hrldas`\nusing `RESTART\\_FILENAME\\_REQUESTED` option.\nTo warm start the HYDRO part of the model, specify the path to the `HYDRO\\_RST` file in\nthe :file:`hydro.namelist` using the option `RESTART\\_FILE`, and also set the `gw\\_restart` option to 1.\nIf the path to the files are left empty or commented out, it means the model simulation is cold started.\n\n\nOne could control the frequency of outputting restart files using the options `RESTART\\_FREQUENCY\\_HOURS`\nand `rst\\_dt` in the :file:`namelist.hrldas` and :file:`hydro.namelist`, respectively. If these options are set\nto -9999, model outputs restart files once a month. Restart files are large in size, and therefore user\nneeds to be cautious of how frequently it outputs the restart files.\n\n.. figure:: media/restarts.png\n :align: center\n\n **Figure A15.** Overview of restart files for the various model physics\n components.\n\nA15.1 RESTART_MP File Variable Table\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n.. note::\n Noah-MP restarts are written in ``subroutine lsm_restart()`` in :file:`module_NoahMP_hrldas_driver.F`.\n Noah-MP variables are defined in ``subroutine noahmplsm()`` in :file:`module_sf_noahmpdrv.F`\n\n`RESTART\\_MP` file variable descriptions\n\n.. table::\n :width: 90%\n :align: center\n\n +-------------+-------------------------------------------+------------------+\n | **Variable | **Description** | **Units** |\n | name** | | |\n +=============+===========================================+==================+\n | ACCPRCP | Accumulated precipitation | :math:`mm` |\n +-------------+-------------------------------------------+------------------+\n | ACCECAN | Accumulated canopy evaporation | :math:`mm` |\n +-------------+-------------------------------------------+------------------+\n | ACCEDIR | Accumulated direct soil evaporation | :math:`mm` |\n +-------------+-------------------------------------------+------------------+\n | ACCETRAN | Accumulated transpiration | :math:`mm` |\n +-------------+-------------------------------------------+------------------+\n | ACMELT | accumulated melting water out of snow | :math:`mm` |\n | | bottom | |\n +-------------+-------------------------------------------+------------------+\n | ACSNOW | accumulated snowfall on grid | :math:`mm` |\n +-------------+-------------------------------------------+------------------+\n | ALBOLD | snow albedo at last time step (-) | |\n +-------------+-------------------------------------------+------------------+\n | AREAXY | (in the file but not used by the model) | |\n +-------------+-------------------------------------------+------------------+\n | CANICE | Canopy ice water content / | :math:`mm` |\n | | canopy-intercepted ice | |\n +-------------+-------------------------------------------+------------------+\n | CANLIQ | Canopy liquid water content / | :math:`mm` |\n | | canopy-intercepted liquid water | |\n +-------------+-------------------------------------------+------------------+\n | CH | Sensible heat exchange coefficient | |\n +-------------+-------------------------------------------+------------------+\n | CM | Momentum drag coefficient | |\n +-------------+-------------------------------------------+------------------+\n | DEEPRECHXY | soil moisture below the bottom of the | :math:`m^3/m^3` |\n | | column | |\n +-------------+-------------------------------------------+------------------+\n | EAH | canopy air vapor pressure | :math:`Pa` |\n +-------------+-------------------------------------------+------------------+\n | EQZWT | (in the file but not used by the model) | |\n +-------------+-------------------------------------------+------------------+\n | FASTCP | short-lived carbon in shallow soil | :math:`g/m^2` |\n +-------------+-------------------------------------------+------------------+\n | FDEPTHXY | (in the file but not used by the model) | |\n +-------------+-------------------------------------------+------------------+\n | FWET | Wetted or snowed fraction of canopy | :math:`fraction` |\n +-------------+-------------------------------------------+------------------+\n | GVFMAX | annual maximum in vegetation fraction | |\n +-------------+-------------------------------------------+------------------+\n | GVFMIN | annual minimum in vegetation fraction | |\n +-------------+-------------------------------------------+------------------+\n | ISNOW | Number of snow layers | :math:`count` |\n +-------------+-------------------------------------------+------------------+\n | LAI | leaf area index | |\n +-------------+-------------------------------------------+------------------+\n | LFMASS | Leaf mass | :math:`g/m^2` |\n +-------------+-------------------------------------------+------------------+\n | PEXPXY | (in the file but not used by the model) | |\n +-------------+-------------------------------------------+------------------+\n | QRFSXY | Stem mass | :math:`g/m^2` |\n +-------------+-------------------------------------------+------------------+\n | QRFXY | (in the file but not used by the model) | |\n +-------------+-------------------------------------------+------------------+\n | QSFC | bulk surface specific humidity | |\n +-------------+-------------------------------------------+------------------+\n | QSLATXY | Stable carbon in deep soil | :math:`g/m^2` |\n +-------------+-------------------------------------------+------------------+\n | QSNOW | snowfall rate on the ground | :math:`mm/s` |\n +-------------+-------------------------------------------+------------------+\n | QSPRINGSXY | Mass of wood and woody roots | :math:`g/m^2` |\n +-------------+-------------------------------------------+------------------+\n | QSPRINGXY | (in the file by not used by the model) | |\n +-------------+-------------------------------------------+------------------+\n | RECHXY | recharge to the water table (diagnostic) | :math:`m^3/m^3` |\n +-------------+-------------------------------------------+------------------+\n | RIVERBEDXY | (in the file but not used by the model) | |\n +-------------+-------------------------------------------+------------------+\n | RIVERCONDXY | (in the file but not used by the model) | |\n +-------------+-------------------------------------------+------------------+\n | RTMASS | mass of fine roots | :math:`g/m^2` |\n +-------------+-------------------------------------------+------------------+\n | SAI | stem area index | |\n +-------------+-------------------------------------------+------------------+\n | SFCRUNOFF | Accumulatetd surface runoff | :math:`mm` |\n +-------------+-------------------------------------------+------------------+\n | SH2O | volumetric liquid soil moisture | :math:`m^3/m^3` |\n +-------------+-------------------------------------------+------------------+\n | SMC | Volumetric Soil Moisture | :math:`m^3/m^3` |\n +-------------+-------------------------------------------+------------------+\n | SMCWTDXY | soil moisture below the bottom of the | :math:`m^3/m^3` |\n | | column | |\n +-------------+-------------------------------------------+------------------+\n | SMOISEQ | volumetric soil moisture | :math:`m^3/m^3` |\n +-------------+-------------------------------------------+------------------+\n | SNEQV | Snow water equivalent | :math:`kg/m^2` |\n +-------------+-------------------------------------------+------------------+\n | SNEQVO | snow mass at last time step | :math:`mm` |\n +-------------+-------------------------------------------+------------------+\n | SNICE | snow layer ice | :math:`mm` |\n +-------------+-------------------------------------------+------------------+\n | SNLIQ | Snow layer liquid water | :math:`mm` |\n +-------------+-------------------------------------------+------------------+\n | SNOWH | Snow depth | :math:`m` |\n +-------------+-------------------------------------------+------------------+\n | SNOW_T | snow temperature | :math:`K` |\n +-------------+-------------------------------------------+------------------+\n | SOIL_T | Soil Temperature on NSOIL layers | :math:`K` |\n +-------------+-------------------------------------------+------------------+\n | STBLCP | Stable carbon in deep soil | :math:`g/m^2` |\n +-------------+-------------------------------------------+------------------+\n | STMASS | stem mass | :math:`g/m^2` |\n +-------------+-------------------------------------------+------------------+\n | TAH | Canopy Air Temperature | :math:`K` |\n +-------------+-------------------------------------------+------------------+\n | TAUSS | snow age factor | |\n +-------------+-------------------------------------------+------------------+\n | TG | Ground Temperature | :math:`K` |\n +-------------+-------------------------------------------+------------------+\n | TV | Canopy Temperature | :math:`K` |\n +-------------+-------------------------------------------+------------------+\n | UDRUNOFF | Accumulated underground runoff\" | :math:`mm` |\n +-------------+-------------------------------------------+------------------+\n | WA | Water in aquifer relative to reference | :math:`kg/m^2` |\n | | level | |\n +-------------+-------------------------------------------+------------------+\n | WOOD | Mass of wood and woody roots | :math:`g/m^2` |\n +-------------+-------------------------------------------+------------------+\n | WSLAKE | lake water storage | :math:`mm` |\n +-------------+-------------------------------------------+------------------+\n | WT | Water in aquifer and saturated soil | :math:`kg/m^2` |\n +-------------+-------------------------------------------+------------------+\n | ZSNSO | Snow layer depths from snow surface | :math:`m` |\n +-------------+-------------------------------------------+------------------+\n | ZWT | water table depth | :math:`m` |\n +-------------+-------------------------------------------+------------------+\n | VEGFRA | Vegetation fraction | |\n +-------------+-------------------------------------------+------------------+\n\n\n\n.. _section-a15.2:\n\nA15.2 HYDRO_RST File Variable Table\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n.. note::\n The variables are written to the `HYDRO\\_RST` file in the subroutine of\n ``RESTART_OUT_nc`` in the :file:`Routing/module_HYDRO_io.F90`. The tables below\n contain all the information on the dimensions and variables in the Hydro\n RESTART file (`HYDRO\\_RST`).\n\n.. table::\n :width: 90%\n :align: center\n\n +---------------+-----------------------------+---------------------------+\n | **Dimension** | **Description** | **It is written** |\n +===============+=============================+===========================+\n | depth | Number of soil layers | |\n +---------------+-----------------------------+---------------------------+\n | ix | Number of columns in the | |\n | | coarse grid (LSM) | |\n +---------------+-----------------------------+---------------------------+\n | iy | Number of rows in the | |\n | | coarse grid (LSM) | |\n +---------------+-----------------------------+---------------------------+\n | ixrt | Number of columns in the | |\n | | fine grid (hydro) | |\n +---------------+-----------------------------+---------------------------+\n | iyrt | Number of rows in the fine | |\n | | grid (hydro) | |\n +---------------+-----------------------------+---------------------------+\n | links | Number of links/reaches | |\n +---------------+-----------------------------+---------------------------+\n | basns | Number of basins for the | Only if ``GWBASESWCRT=1`` |\n | | groundwater/baseflow | in the `hydro.namelist` |\n | | modeling | |\n +---------------+-----------------------------+---------------------------+\n | lakes | Number of lakes | Only if the lake |\n | | | routing is turned on |\n +---------------+-----------------------------+---------------------------+\n\n.. table::\n :width: 90%\n :align: center\n\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | **Variable | **Description** | **# Dimensions | **Resolution** | **Units** |\n | name** | | (not | | |\n | | | including | | |\n | | | time)** | | |\n +==============+===============================+================+================+=================+\n | cvol | volume of stream in cell | 1 | fine/link | :math:`m^3` |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | hlink | stream stage | 1 | fine/link | :math:`m` |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | infxsrt | infiltration excess water | 2 | coarse | :math:`mm` |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | infxswgt | weights for disaggregation of | 2 | fine | \\- |\n | | infxsrt | | | |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | qbdryrt | accumulated value of the | 2 | fine | :math:`mm` |\n | | boundary flux | | | |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | qlink1 | stream flow in to cell/reach | 1 | fine/link | :math:`m^3/s` |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | qlink2 | stream flow out of cell/reach | 1 | fine/link | :math:`m^3/s` |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | qstrmvolrt | Accumulated depth of stream | 2 | fine | :math:`mm` |\n | | channel inflow | | | |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | sfcheadrt | surface head on the coarse | 2 | coarse | :math:`mm` |\n | | grid | | | |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | sfcheadsubrt | surface head on the routing | 2 | fine | :math:`mm` |\n | | grid | | | |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | sh2owgt | weights for disaggregation of | 3 | fine | \\- |\n | | total soil moisture (smc) | | | |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | sh2ox | liquid soil moisture | 3 | coarse | :math:`m^3/m^3` |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | smc | total liq+ice soil moisture. | 3 | coarse | :math:`m^3/m^3` |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | soldrain | soil drainage | 2 | coarse | :math:`mm` |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | stc | soil temperature | 3 | coarse | :math:`K` |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | lake_inflort | lake inflow | 2 | fine | :math:`mm` |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | resht | water surface elevation | 1 | link | :math:`m` |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | qlakeo | outflow from lake used in | 1 | link | :math:`m^3/s` |\n | | diffusion scheme | | | |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | qlakei | lake inflow | numLakes | link | :math:`m^3/s` |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n | z_gwsubbas | depth in ground water bucket | 1 | link | :math:`m` |\n +--------------+-------------------------------+----------------+----------------+-----------------+\n\n\n.. _section-a16:\n\nA16. Streamflow Nudging\n-----------------------\n\nBelow is an example netCDF header nudging time slice\nobservation file containing 2 gages. The command :program:`ncdump -h` was used to\nproduce this header information.\n\n::\n\n netcdf 2013-06-01_21:45:00.15min.usgsTimeSlice {\n dimensions:\n stationIdStrLen = 15 ;\n stationIdInd = UNLIMITED ; // (2 currently)\n timeStrLen = 19 ;\n variables:\n char stationId(stationIdInd, stationIdStrLen) ;\n stationId:long_name = \"USGS station identifier of length 15\" ;\n char time(stationIdInd, timeStrLen) ;\n time:units = \"UTC\" ;\n time:long_name = \"YYYY-MM-DD_HH:mm:ss UTC\" ;\n float discharge(stationIdInd) ;\n discharge:units = \"m^3/s\" ;\n discharge:long_name = \"Discharge.cubic_meters_per_second\" ;\n short discharge_quality(stationIdInd) ;\n discharge_quality:units = \"-\" ;\n discharge_quality:long_name = \"Discharge quality 0 to 100 to be scaled by 100.\" ;\n float queryTime(stationIdInd) ;\n queryTime:units = \"seconds since 1970-01-01 00:00:00 local TZ\" ;\n // global attributes:\n :fileUpdateTimeUTC = \"2017-08-25_17:24:22\" ;\n :sliceCenterTimeUTC = \"2013-06-01_21:45:00\" ;\n :sliceTimeResolutionMinutes = \"15\" ;\n }\n\nBelow is an example `nudgingParams.nc` file containing\nparameters for 3 gages. The command :program:`ncdump -h` was used to create this\nheader information.\n\n::\n\n netcdf nudgingParams {\n dimensions:\n stationIdInd = UNLIMITED ; // (3 currently)\n monthInd = 12 ;\n threshCatInd = 2 ;\n threshInd = 1 ;\n stationIdStrLen = 15 ;\n variables:\n float G(stationIdInd) ;\n G:units = \"-\" ;\n G:long_name = \"Amplitude of nudging\" ;\n float R(stationIdInd) ;\n R:units = \"meters\" ;\n R:long_name = \"Radius of influence in meters\" ;\n float expCoeff(stationIdInd, monthInd, threshCatInd) ;\n expCoeff:units = \"minutes\" ;\n expCoeff:long_name = \"Coefficient b in denominator e^(-dt/b)\" ;\n float qThresh(stationIdInd, monthInd, threshInd) ;\n qThresh:units = \"m^3/s\" ;\n qThresh:long_name = \"Discharge threshold category\" ;\n char stationId(stationIdInd, stationIdStrLen) ;\n stationId:units = \"-\" ;\n stationId:long_name = \"USGS station identifer\" ;\n float tau(stationIdInd) ;\n tau:units = \"minutes\" ;\n tau:long_name = \"Time tapering parameter half window size in minutes\" ;\n }\n\n.. _section-a17:\n\nA17. National Water Model (NWM) Configuration\n---------------------------------------------\n\nThe community WRF-Hydro modeling system is currently the underlying modeling\narchitecture for the NOAA National Water Model. This means that the community\nWRF-Hydro model code is configurable into the National Water Model\nconfigurations that run in operations at the National Center for\nEnvironmental Prediction (NCEP).\n\n.. pull-quote::\n\n “\\ *The NWM is an hourly cycling uncoupled analysis and forecast system\n that provides streamflow for 2.7 million river reaches and other\n hydrologic information on 1km and 250m grids. The model provides\n complementary hydrologic guidance at current NWS River Forecast Center\n (RFC) river forecast locations and significantly expanded guidance\n coverage and type in underserved locations.*\n\n *The NWM ingests forcing from a variety of sources including Multi-Radar\n Multi-Sensor (MRMS) radar-gauge observed precipitation data and\n High-Resolution Rapid Refresh (HRRR), Rapid Refresh (RAP), Global\n Forecast System (GFS) and Climate Forecast System (CFS) Numerical\n Weather Prediction (NWP) forecast data. USGS real-time streamflow\n observations are assimilated and all NWM configurations benefit from the\n inclusion of ~5500 reservoirs. The core of the NWM system is the\n National Center for Atmospheric Research (NCAR)-supported community\n Weather Research and Forecasting (WRF)-Hydro hydrologic model. WRF-Hydro\n is configured to use the Noah Multi-Parameterization (Noah-MP) Land Surface Model (LSM) to simulate land\n surface processes. Separate water routing modules perform diffusive wave\n surface routing and saturated subsurface flow routing on a 250m grid,\n and Muskingum-Cunge channel routing down NHDPlusV2 stream reaches. River\n analyses and forecasts are provided across a domain encompassing the\n continental U.S. and hydrologically-contributing areas, while land\n surface output is available on a larger domain that extends beyond the\n continental U.S. into Canada and Mexico (roughly from latitude 19N to\n 58N). In addition, NWM forcing datasets are provided on this domain at a\n resolution of 1km.*\\ ”\n\n.. centered:: *Excerpt from NOUS41 KWBC 061735 PNSWSH NWS Office of Science and Technology Integration*\n\nNewer versions of the National Water Model were extended to Hawaii, Puerto Rico and the U.S. Virgin Islands, and South-Central Alaska.\n\nA17.1 Operational NWM\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nFor more information regarding the operational configuration, input, and\noutput data of the National Water Model see the Office of Water\nPrediction website: http://water.noaa.gov/about/nwm and the Open Commons\nConsortium Environmental Data Commons website:\nhttp://edc.occ-data.org/nwm/.\n\nThere are different NWM configurations that run operationally. The full\nlist of the configurations and their specifics can be found at\n\n- https://water.noaa.gov/about/nwm\n\nThe latest NWM configuration and files can be found on the NOAA NCEP site:\n\n- https://www.nco.ncep.noaa.gov/pmb/codes/nwprod/\n (scroll to the nwm.vX folder)\n\nNamelists for different operational configurations can be found on the NOAA NCEP site, for example:\n\n- NWMv3.0 CONUS Analysis & Assimilation cycle:\n https://www.nco.ncep.noaa.gov/pmb/codes/nwprod/nwm.v3.0.12/parm/analysis_assim/\n\n- NWMv3.0 South-Central Alaska Medium-Range Forecast cycle:\n https://www.nco.ncep.noaa.gov/pmb/codes/nwprod/nwm.v3.0.12/parm/ak_medium_range/\n\n- NWMv3.0 Hawaii Short-Range Forecast cycle:\n https://www.nco.ncep.noaa.gov/pmb/codes/nwprod/nwm.v3.0.12/parm/hi_short_range/\n\n- NWMv3.0 Puerto Rico & U.S. Virgin Islands Short-Range Forecast cycle:\n https://www.nco.ncep.noaa.gov/pmb/codes/nwprod/nwm.v3.0.12/parm/pr_short_range/\n\n\nAn archive of National Water Model operational outputs can be found on Google Cloud:\n\n- https://console.cloud.google.com/storage/browser/national-water-model/\n\n\nA17.2 NWM Retrospectives\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nIn addition to the operational model outputs, we also produce long-term (20-40 year)\nretrospectives for most versions of the National Water Model.\n\n\nThe National Water Model Retrospectives can be found on AWS and Google Cloud:\n\n- https://registry.opendata.aws/nwm-archive/\n\n- https://console.cloud.google.com/storage/browser/national-water-model-v3-0\n\n\n.. _section-a18:\n\nA18. The Crocus Glacier Model\n-----------------------------\n\nCrocus is an energy and mass transfer snowpack model, initially developed for\navalanche forecasting (*Brun et al., 1989, 1992*). The version that was\nimplemented into the French SURFEX model V8.0 (*Vionnet et al., 2012*) is being\nused here. This version has several updates from older versions of Crocus, such\nas the impacts of wind drift.\n\nThe Crocus snowpack model is a multilayered, physically based snow model that\nexplicitly calculates snow grain properties in each snow layer and how these\nproperties change over time. The grain properties of dendricity, sphericity and\nsize are prognosed in Crocus through metamorphism, compaction and impacts of\nwind drift. Furthermore, the snow albedo is calculated based on the snow grain\nproperties from the top 3cm of the snowpack (*Vionnet et al., 2012*) and is\ncalculated in three spectral bands (0.3-0.8, 0.8-1.5 and 1.5-2.5 `\\mu m`).\nImpurities in aging snow are parameterized in the UV and visible spectral band\n(0.3-0.8 `\\mu m`) from the age of the snow, with a time constant of 60 days. See\n*Vionnet et al. (2012)* for a detailed description of the albedo calculations.\nThe albedo over ice is constant in all spectral bands and is 0.38, 0.23 and\n0.08 for the spectral bands 0.3-0.8, 0.8-1.5 and 1.5-2.5 `\\mu m`. The sensible and\nlatent heat are parameterized with an effective roughness length over snow and\nice (see *Vionnet et al. (2012)* for further details).\n\nIn the Crocus model, it is possible to divide the snow into a user-defined\nmaximum numbers of dynamically evolving layers. As new snow is accumulated, a\nnew active layer is added. As different snow layers become similar (based upon\nthe number of user-set layers, the thickness of the snow layers and the snow\ngrain characteristics), these snow layers will merge into single snow layers.\n\nThe Crocus module is added to the Noah-MP land surface model in WRF-Hydro to\nact as a glacier mass balance model (*Eidhammer et al. 2021*). Over designated\nglacier grid points, the Crocus snow model represents both snow and ice, while\noutside of the designated glacier grid points, the regular three-layer snow\nmodel in Noah-MP is used. Since the current Crocus implementation in WRF-Hydro\nonly acts over designated glacier grid points, we follow *Gerbaux et al. (2005)*\nand assume that the temperatures at the bottom of the glacier and the ground\nbelow are both at `0^\\circ C`. Note that we have not yet incorporated\nfluxes between the glacier and the ground below; thus, there is a constant\ntemperature boundary condition.\n\nBoth Crocus and Noah-MP (for the non-glacier grid points) output runoff from\nsnowmelt (and precipitation). This runoff is provided to the terrain routing\nmodels in WRF-Hydro.\n\nNote that the implementation of Crocus as a glacier mass balance model does not\naddress glacier movement (i.e., plastic flow) nor lateral wind (re)distribution\nof snow. However, there are two options for including impacts on the snow due\nto wind. One of the options impacts the snow density during blowing snow events\n(*Brun et al., 1997*). This option is important in polar environments (*Brun et\nal., 1997*). The other option is the sublimation due to snow drift, which was\nimplemented by *Vionnet et al. (2012)* and which is in the Crocus version that\nis used in this study.\n\nAs implemented, if the glacier completely melts over a user-defined glacier\ngrid point, the original Noah-MP module is used from this point on. Therefore,\nas currently implemented, the glacier cannot grow horizontally in extent; it\ncan only decrease in extent, as no dynamic response of the ice mass is included\nin the model. Over short model time periods, the lack of increase in glacier\nextent might impact a few grid points at the edges of the glacier. However,\ngiven the expected increase in temperature in the future, we do not expect that\nlimiting glacier horizontal growth will have a major impact over most studied\nglaciers as most are likely to decrease in mass and extent.\n\n.. rubric:: Running WRF-Hydro / Glacier\n\nBelow is a description on how to run with Crocus as a glacier model. There are\nonly a few namelist options that needs to be added in :file:`namelist.hrldas`:\n\n.. code-block:: fortran\n\n &CROCUS_nlist\n crocus_opt = 1 ! 0 model is off, 1 model is on\n act_lev = 40 ! 1-50, 20-40 normal options\n /\n\nThe initialization file wrfinput needs two additional fields to be defined:\n\n | ``glacier``\n | ``glacier_thickness``\n\nThe field ``glacier`` should have the value of 1 over glacier gridpoints. The\n``glacier`` field can be provided by the user, or the user can use the glacier\ncategory from ``IVGTYP``.\n\nHere is an example how to generate initial glacier fields for an “ideal”\nsimulation, with homogeneous glacier thickness layer. In this case,\n``IVGTYP=24`` represents glaciers:\n\n.. code-block:: bash\n\n ncap2 -O -s 'glacier=IVGTYP' wrfinput.nc wrfinput.nc\n ncap2 -O -s 'where(glacier!=24) glacier=0' wrfinput.nc wrfinput.nc\n ncap2 -O -s 'where(glacier==24) glacier=1' wrfinput.nc wrfinput.nc\n\nTo create a 300 m thick glacier:\n\n.. code-block:: bash\n\n ncap2 -O -s 'glacier_thickness=glacier*300' wrfinput.nc wrfinput.nc\n\nAt initialization, it is assumed that the glacier consists of only ice, and the\ndensity is that of pure ice (`900 \\frac{kg}{m^3}`). Within the user-defined maximum\nlayers (``act_lev``) the glacier is initialized with all the layers having the same\nassumed density and snow grain properties. As new snow accumulates during the\nsimulations, the layers representing the glacier will start to merge since all\nlayers contain the initialized ice.\n\n.. rubric:: Crocus outputs\n\n.. table::\n :width: 90%\n :align: center\n :name: table-a16\n\n +--------------+-----------+----------------------------------------------+--------------------+\n | | Dimension | Explanation | Units |\n +==============+===========+==============================================+====================+\n | PSNOWSWE | 3D | Snow water equivalent | `kg/m^2` |\n +--------------+-----------+----------------------------------------------+--------------------+\n | PSNOWTEMP | 3D | Glacier temperature | `K` |\n +--------------+-----------+----------------------------------------------+--------------------+\n | PSNOWALB | 2D | Albedo | `-` |\n +--------------+-----------+----------------------------------------------+--------------------+\n | PSNOWTHRUFAL | 2D | Accumulated surface runoff | `kg/m^2` |\n +--------------+-----------+----------------------------------------------+--------------------+\n | PSNOWHEIGHT | 2D | Total glacier thickness | `m` |\n +--------------+-----------+----------------------------------------------+--------------------+\n | PSNOWTOTSWE | 2D | Total glacier snow water equivalent | `kg/m^2` |\n +--------------+-----------+----------------------------------------------+--------------------+\n | PSNOWGRAN1 | 3D | Snow grain parameter 1 | `-` |\n +--------------+-----------+----------------------------------------------+--------------------+\n | PSNOWGRAN2 | 3D | Snow grain parameter 2 | `-` |\n +--------------+-----------+----------------------------------------------+--------------------+\n | PSNOWDZ | 3D | Thickness of snow/ice layers | `m` |\n +--------------+-----------+----------------------------------------------+--------------------+\n | PSNOWHIST | 3D | Snow grain historical parameter | `-` |\n +--------------+-----------+----------------------------------------------+--------------------+\n | PSNOWLIQ | 3D | Liquid content | `kg/m^2` |\n +--------------+-----------+----------------------------------------------+--------------------+\n | PSNOWRHO | 3D | Snow/ice density | `kg/m^3` |\n +--------------+-----------+----------------------------------------------+--------------------+\n | FLOW_ICE | 2D | Accumulated surface runoff from ice surface | `kg/m^2` (or `mm`) |\n +--------------+-----------+----------------------------------------------+--------------------+\n | FLOW_SNOW | 2D | Accumulated surface runoff from snow surface | `kg/m^2` (or `mm`) |\n +--------------+-----------+----------------------------------------------+--------------------+\n\n.. note::\n Note on other WRF-Hydro outputs: The following outputs are informed\n from both Noah-MP and Crocus. Over glacier gridpoints, the outputs\n are informed from Crocus: ``ACCET``, ``ALBEDO``, ``SNOWEQV``, ``SNOWH``\n and ``ACSNOWM``.\n\n Currently there are no namelist options to change parameter values.\n Several important parameters that can be modified can be found in:\n :file:`src/Land_models/NoahMP/phys/surfex/modd_snow_par.F90`\n\n Surface runoff is assigned to ``FLOW_ICE`` when the top active layer at the\n specific grid point has a density of 850 kg/m3, while surface runoff is\n assigned to ``FLOW_SNOW`` when the top active layer has a density equal to\n or less than 850 kg/m3. The sum of ``FLOW_ICE`` and ``FLOW_SNOW`` is equal\n to ``PSNOWTHRUFAL``. Note that runoff from precipitation is included in\n surface runoff, thus ``FLOW_SNOW`` and ``FLOW_ICE`` cannot be used directly\n as indication if melt is from the ice part of the glacier or snow part of\n the glacier.\n\n\n.. _section-a19:\n\nA19. Model Output Variables\n---------------------------------------------\n\nA19.1. Land surface model output variables\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n :file:`{YYYYMMDDHHMM}.LDASOUT_DOMAIN{X}`\n\n .. csv-table:: LDASOUT\n :file: output-tables/LDASOUT_DOMAIN.csv\n :header-rows: 1\n\nA19.2. Land surface diagnostic output variables\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n :file:`{YYYYMMDDHHMM}.LSMOUT_DOMAIN{X}`\n\n .. csv-table:: LSMOUT\n :file: output-tables/LSMOUT.csv\n :header-rows: 1\n\nA19.3. Streamflow output variables at all channel reaches/cells\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n :file:`{YYYYMMDDHHMM}.CHRTOUT_DOMAIN{X}`\n\n .. csv-table:: CHRTOUT\n :file: output-tables/CHRTOUT_DOMAIN.csv\n :header-rows: 1\n\nA19.4. Streamflow output variables at forecast points or gage reaches/cells\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n :file:`{YYYYMMDDHHMM}.CHANOBS_DOMAIN{X}`\n\n .. csv-table:: CHANOBS_DOMAIN\n :file: output-tables/CHANOBS_DOMAIN.csv\n :header-rows: 1\n\nA19.5. Streamflow output variables on the 2D high resolution routing grid\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n :file:`{YYYYMMDDHHMM}.CHRTOUT_GRID{X}`\n\n .. csv-table:: CHRTOUT_GRID\n :file: output-tables/CHRTOUT_GRID.csv\n :header-rows: 1\n\nA19.6. Terrain routing variables on the 2D high resolution routing grid\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n :file:`{YYYYMMDDHHMM}.RTOUT_DOMAIN{X}`\n\n .. csv-table:: RTOUT\n :file: output-tables/RTOUT_DOMAIN.csv\n :header-rows: 1\n\nA19.7. Lake output variables\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n :file:`{YYYYMMDDHHMM}.LAKEOUT_DOMAIN{X}`\n\n .. csv-table:: LAKEOUT\n :file: output-tables/LAKEOUT_DOMAIN.csv\n :header-rows: 1\n\nA19.8. Ground water output variables\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n :file:`{YYYYMMDDHHMM}.GWOUT_DOMAIN{X}`\n\n .. csv-table:: GWOUT\n :file: output-tables/GWOUT_DOMAIN.csv\n :header-rows: 1\n" }, { "path": "docs/userguide/conf.py", "content": "project = 'WRF-Hydro Modeling System'\nauthor = 'WRF-Hydro Team'\ncopyright = '2024, '+author\nversion = 'v5.4.0'\nrelease = '5.4.0'\ntry:\n import sphinx_rtd_theme\n extensions = [\n 'sphinx_rtd_theme',\n ]\n # html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]\n html_theme = 'sphinx_rtd_theme'\n html_theme_options = {\n 'navigation_depth': -1\n }\nexcept:\n print(\"Warning: sphinx_rtd_theme not installed, using default theme\")\n pass\nhtml_static_path = ['_static']\nhtml_css_files = ['ug_theme.css']\nnumfig_secnum_depth = 2\n\n#these are enforced by rstdoc, but keep them for sphinx-build\nnumfig = 0\nsmartquotes = 0\nsource_suffix = '.rest'\ntemplates_path = []\nlanguage = 'en'\nhighlight_language = \"none\"\ndefault_role = 'math'\npygments_style = 'sphinx'\nexclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']\nmaster_doc = 'index'\n" }, { "path": "docs/userguide/index.rest", "content": ".. vim: syntax=rst\n.. include:: meta.rest\n\n.. image:: media/wrfhydro-banner.png\n :align: center\n\n=========================================================\nThe NCAR WRF-Hydro® Modeling System Technical Description\n=========================================================\n.. rst-class:: center\n\n | Version |version_long|\n |\n | Originally Created:\n | April 14, 2013\n |\n | Updated:\n | January 17, 2025\n\nUntil further notice, please cite the WRF-Hydro® modeling system as\nfollows:\n\nGochis, D.J., M. Barlage, R. Cabell, M. Casali, E. Dougherty, A. Dugger, T. Eidhammer, T. Enzminger,\nK. FitzGerald, F. Felfelani, A. Gaydos, L. Karsten, A. Mazrooei, M. McAllister, J. McCreight, A. McCluskey,\nN. Omani, A. RafieeiNasab, S. Rasmussen, L. Read, K. Sampson, I. Srivastava, D. Yates, W. Yu, and\nY. Zhang (2025).\n*The WRF-Hydro® Modeling System Technical Description,* (Version 5.4).\ndoi:`10.5281/zenodo.15040873`\nNCAR Technical Note. Available online at:\nhttps://wrf-hydro.readthedocs.io/en/latest/\n\n\n.. rubric:: Links:\n\n- `Project Website `_\n- `GitHub Repository `_\n\n.. rubric:: FORWARD\n\nThis Technical Description describes the WRF-Hydro® model coupling\narchitecture and physics options, released in Version 5.4 in January 2025.\nAs the WRF-Hydro® modeling system is developed further, this document\nwill be continuously enhanced and updated. Please send feedback to\nwrfhydro@ucar.edu.\n\n.. rubric:: Prepared by:\n\nDavid Gochis, Michael Barlage, Ryan Cabell, Matt Casali, Erin Dougherty, Aubrey Dugger, Trude\nEidhammer, Tom Enzminger, Katelyn FitzGerald, Farshid Felfelani, Andy Gaydos, Amir Mazrooei, Molly McAllister,\nJames McCreight, Alyssa McCluskey, Nina Omani, Arezoo RafieeiNasab, Soren Rasmussen, Laura Read, Kevin Sampson,\nIshita Srivastava, David Yates, and Yongxin Zhang\n\n.. rubric:: Special Acknowledgments:\n\nDevelopment of the NCAR WRF-Hydro system has been significantly enhanced\nthrough numerous collaborations. The following persons are graciously\nthanked for their contributions to this effort:\n\n- John McHenry and Carlie Coats, Baron Advanced Meteorological Services\n\n- Martyn Clark, Fei Chen, Cenlin He, Prasanth Valayamkunnath, Dan Rosen, Rocky Dunlap,\n Alessandro Fanfarillo, National Center for Atmospheric Research\n\n- Zong-Liang Yang, Cedric David, Peirong Lin and David Maidment of the\n University of Texas at Austin\n\n- Harald Kunstmann, Benjamin Fersch and Thomas Rummler of Karlsruhe\n Institute of Technology, Garmisch-Partenkirchen, Germany\n\n- Alfonso Senatore, University of Calabria, Cosenza, Italy\n\n- Brian Cosgrove, Ed Clark, Fernando Salas, Trey Flowers, Zhengtao Cui, Xia Feng, Nels Frazier,\n James Halgren, Don Johnson, Yuqiong Liu, Dave Mattern, Fred Ogden, Cham Phan, Mehdi Rezaeianzadeh,\n and Tom Graziano of the National Oceanic and Atmospheric Administration Office of Water Prediction\n\n- Ismail Yucel, Middle East Technical University, Ankara, Turkey\n\n- Erick Fredj, The Jerusalem College of Technology, Jerusalem, Israel\n\n- Amir Givati, Surface water and Hydrometeorology Department, Israeli\n Hydrological Service, Jerusalem.\n\n- Antonio Parodi, Fondazione CIMA - Centro Internazionale in Monitoraggio\n Ambientale, Savona, Italy\n\n- Blair Greimann, Sedimentation and Hydraulics section, U.S. Bureau of\n Reclamation\n\n- Z George Xue and Dongxiao Yin, Louisiana State University\n\n- Tim Lahmers and Sujay Kumar, NASA Goddard Space Flight Center\n\nFunding support for the development and application of the WRF-Hydro®\nmodeling system has been provided by:\n\n- The National Science Foundation National Center for Atmospheric\n Research\n\n- The U.S. National Weather Service\n\n- The Colorado Water Conservation Board\n\n- Baron Advanced Meteorological Services\n\n- National Aeronautics and Space Administration (NASA)\n\n- National Oceanic and Atmospheric Administration (NOAA) Office of Water\n Prediction (OWP)\n\n- U.S. Geological Survey (USGS) Water Mission Area\n\n\n.. toctree::\n :hidden:\n\n Preface / Acknowledgements \n introduction\n model-code-config\n model-physics\n nudging\n model-inputs-preproc\n model-outputs\n references\n appendices\n" }, { "path": "docs/userguide/input-tables/Fulldom_hires.tsv", "content": "VariableName\tDimensions\tDescription\tUnits\tNotes\r\nTOPOGRAPHY\tRouting grid\tTerrain grid or Digital Elevation Model (DEM).\tm\r\nFLOWDIRECTION\tRouting grid\tFlow direction grid, which explicitly defines flow directions along the channel network in gridded routing. This variable dictates where water flows into channels from the land surface as well as in the channel.\tcategorical\r\nFLOWACC\tRouting grid\tNumber of upstream cells that drain into each cell.\tcount\r\nCHANNELGRID\tRouting grid\tChannel network grid identifying the location of stream channel grid cells (-9999=no channel, -1=deactivated channel, 0=active channel)\tcategorical\r\nSTREAMORDER\tRouting grid\tStrahler stream order grid identifying the stream order for all channel pixels within the channel network.\tcategorical\r\nLKSATFAC\tRouting grid\tMultiplier on saturated hydraulic conductivity in lateral flow direction.\tdimensionless\r\nRETDEPRTFAC\tRouting grid\tMultiplier on maximum retention depth before flow is routed as overland flow.\tdimensionless\r\nOVROUGHRTFAC\tRouting grid\tMultiplier on Manning's roughness for overland flow.\tdimensionless\r\nfrxst_pts\tRouting grid\tPrescribed forecast points\tindex\r\nbasn_msk\tRouting grid\tPrescribed basin masks\tindex\r\nLAKEGRID\tRouting grid\tPrescribed lakes\tindex\r\nlanduse\tRouting grid\tLand use from geogrid regridded to the high-res routing grid\tcategorical" }, { "path": "docs/userguide/input-tables/geo_em.tsv", "content": "VariableName\tDimensions\tDescription\tUnits\tNotes\r\nLU_INDEX\tLSM grid\tLand cover type\tCategorical\tHydro routing code uses this variable to define land cover type. The classification scheme is determined by the global attribute MMINLU and ISURBAN, ISWATER, and ISOILWATER are used to define special types. See MPTABLE.TBL for NoahMP-supported land cover classification schemes.\r\nSCT_DOM\tLSM grid\tDominant top layer soil texture class\tCategorical\tHydro routing code uses this variable to define soil type (texture class). Currently there is only one texture class defined per cell (not variable with depth). See SOILPARM.TBL for the supported texture classes.\r\nHGT_M\tLSM grid\tElevation\tm\tNot used by the model but useful for reference." }, { "path": "docs/userguide/input-tables/wrfinput.tsv", "content": "VariableName\tDimensions\tDescription\tUnits\tNotes\r\nSMOIS\tLSM grid, soil layers\tInitial volumetric soil moisture content\tm3/m3\r\nTSLB\tLSM grid, soil layers\tInitial soil temperature\tK\r\nSNOW\tLSM grid\tInitial snow water equivalent\tmm (kg/m2)\r\nCANWAT\tLSM grid\tInitial canopy water storage\tmm (kg/m2)\r\nTSK\tLSM grid\tInitial surface temperature\tK\tUsed to initialize model temperatures other than soil, e.g., canopy leaf and air temperature\r\nLAI\tLSM grid\tInitial leaf area index\tm2/m2\tOnly used by certain NoahMP settings\r\nIVGTYP\tLSM grid\tLand cover type\tCategorical\tLSM uses this variable to define land cover type. The classification scheme is determined by the global attribute MMINLU and ISURBAN, ISWATER, and ISICE are used to define special types. See MPTABLE.TBL for NoahMP-supported land cover classification schemes.\r\nISLTYP\tLSM grid\tSoil texture class\tCategorical\tLSM uses this variable to define soil type (texture class). Currently there is only one texture class defined per cell (not variable with depth). See SOILPARM.TBL for the supported texture classes.\r\nTMN\tLSM grid\tConstant deep ­soil temperature\tK\tUsed as fixed lower boundary temperature for TBOT_OPTION=2\r\nSHDMAX\tLSM grid\tMaximum annual vegetation fraction\t% (0-100)\tOnly used by certain NoahMP settings\r\nSHDMIN\tLSM grid\tMinimum annual vegetation fraction\t% (0-100)\tOnly used by certain NoahMP settings\r\nSEAICE\tLSM grid\tPresence of sea ice\tfraction\tSet to 0; if >0, model will skip execution\r\nXLAND\tLSM grid\tLand/water mask (1=land, 2=water)\tcategorical\tSet to 1 for land points; if =2, model will skip execution\r\nHGT\tLSM grid\tElevation\tm\tNot used by the model but useful for reference." }, { "path": "docs/userguide/introduction.rest", "content": ".. vim: syntax=rst\n.. include:: meta.rest\n\n1. Introduction\n===============\n\nThe purpose of this technical note is to describe the physical\nparameterizations, numerical implementation, coding conventions and\nsoftware architecture for the NCAR Weather Research and Forecasting\nmodel (WRF) hydrological modeling system, hereafter referred to as\nWRF-Hydro. The system is intended to be flexible and extensible and\nusers are encouraged to develop, add and improve components to meet\ntheir application needs.\n\nIt is critical to understand that like the WRF atmospheric modeling\nsystem, the WRF-Hydro modeling system is not a singular 'model' per se\nbut instead it is a modeling architecture that facilitates coupling of\nmultiple alternative hydrological process representations. There are\nnumerous (over 100) different configuration permutations possible in\nWRF-Hydro Version |version_short|. Users need to become familiar with the concepts\nbehind the processes within the various model options in order to\noptimally tailor the system for their particular research and\napplication activities.\n\n1.1 Brief History\n-----------------\n\nThe WRF-Hydro modeling system provides a means to couple hydrological\nmodel components to atmospheric models and other Earth System modeling\narchitectures. The system is intended to be extensible and is built upon\na modular Modern Fortran architecture. The code has also been parallelized\nfor distributed memory parallel computing applications. Numerous options\nfor terrestrial hydrologic routing physics are contained within Version\n|version_short| of WRF-Hydro but users are encouraged to add additional components\nto meet their research and application needs. The initial version of\nWRF-Hydro (originally called 'Noah-distributed' in 2003) included a\ndistributed, 3-dimensional, variably-saturated surface and subsurface\nflow model previously referred to as 'Noah-distributed' for the\nunderlying land surface model upon which the original code was based.\nInitially, the implementation of terrain routing and, subsequently,\nchannel and reservoir routing functions into the 1-dimensional Noah land\nsurface model was motivated by the need to account for increased\ncomplexity in land surface states and fluxes and to provide\nphysically-consistent land surface flux and stream channel discharge\ninformation for hydrometeorological applications. The original\nimplementation of the surface overland flow and subsurface saturated\nflow modules into the Noah land surface model are described by Gochis\nand Chen (2003). In that work, a simple subgrid\ndisaggregation-aggregation procedure was employed as a means of mapping\nland surface hydrological conditions from a “coarsely” resolved land\nsurface model grid to a much more finely resolved terrain routing grid\ncapable of adequately resolving the dominant local landscape gradient\nfeatures responsible for the gravitational redistribution of terrestrial\nmoisture. Since then numerous improvements to the Noah-distributed model\nhave occurred including optional selection for 2-dimensional (in `x` and\n`y`) or 1-dimensional (“steepest descent” or so-called “D8” methodologies)\nterrain routing, a 1-dimensional, grid-based, hydraulic routing model, a\nreservoir routing model, 2 reach-based hydrologic channel routing\nmodels, and a simple empirical baseflow estimation routine. In 2004, the\nentire modeling system, then referred to as the NCAR WRF-Hydro\nhydrological modeling extension package was coupled to the Weather\nResearch and Forecasting (WRF) mesoscale meteorological model (*Skamarock\net al., 2005*) thereby permitting a physics-based, fully coupled land\nsurface hydrology-regional atmospheric modeling capability for use in\nhydrometeorological and hydroclimatological research and applications.\nThe code has since been fully parallelized for high-performance\ncomputing applications. During late 2011 and 2012, the WRF-Hydro code\nunderwent a major reconfiguration of its coding structures to facilitate\ngreater and easier extensibility and upgradability with respect to the\nWRF model, other hydrological modeling components, and other Earth\nsystem modeling frameworks. Additional changes to the\ndirectory structure occurred during 2014-2015 to accommodate the\ncoupling with the new Noah-MP land modeling system. Between 2015-2018,\nnew capabilities were added to permit more generalized, user-defined\nmapping onto irregular objects, such as catchments or hydrologic\nresponse units. During 2018-2022, some of the modules underwent\na code refactoring and automated testing capabilities were added.\nIn 2024, the directory structure was again updated for consistency with modern\nsoftware design practices and this user guide was ported to an interactive\nonline format. As additional changes and enhancements to WRF-Hydro \noccur they will be documented in future versions of this document.\n\n1.2 Model Description\n------------------------\n\nWRF-Hydro has been developed to facilitate improved representations of\nterrestrial hydrologic processes related to the spatial redistribution\nof surface, subsurface and channel waters across the land surface and to\nfacilitate coupling of hydrologic models with atmospheric models.\nSwitch-activated modules in WRF-Hydro enable treatment of terrestrial\nhydrological physics, which have either been created or have been\nadapted from existing distributed hydrological models. The conceptual\narchitecture for WRF-Hydro is shown in Figures 1.1 and 1.2 where\nWRF-Hydro exists as a coupling architecture (blue box) or “middle-ware”\nlayer between weather and climate models and terrestrial hydrologic\nmodels and land data assimilation systems. WRF-Hydro can also operate in\na standalone mode as a traditional land surface hydrologic modeling\nsystem.\n\n.. _figure-1.1:\n.. figure:: media/conceptual_diagram_wrfhydro.png\n :align: center\n :scale: 80%\n\n **Figure 1.1.** Generalized conceptual schematic of the WRF-Hydro\n architecture showing various categories of model components.\n\n.. figure:: media/coupling_schematic.png\n :align: center\n :scale: 80%\n\n **Figure 1.2.** Model schematic illustrating where many existing\n atmosphere, land surface and hydrological model components *could* fit\n into the WRF-Hydro architecture. NOTE: Not all of these models are\n currently coupled into WRF-Hydro at this time. This schematic is meant\n to be illustrative. Components which are coupled have an asterisk (\\*)\n by their name.\n\nWRF-Hydro is designed to enable improved simulation of land surface\nhydrology and energy states and fluxes at a fairly high spatial\nresolution (typically 1 km or less) using a variety of physics-based and\nconceptual approaches. As such, it is intended to be used as either a\nland surface model in both standalone (“uncoupled” or “offline”) mode\nand fully-coupled (to an atmospheric model) mode. Both time-evolving\n“forcing” and static input datasets are required for model operation.\nThe exact specification of both forcing and static data depends greatly\non the selection of model physics and component options to be used. The\nprincipal model physics options in WRF-Hydro include:\n\n- 1-dimensional (vertical) land surface parameterization\n\n- surface overland flow\n\n- saturated subsurface flow\n\n- channel routing\n\n- reservoir routing\n\n- conceptual/empirical baseflow\n\nBoth the Noah land surface and Noah-MP land surface model options are\navailable for use in the current version of the WRF-Hydro. The rest of\nthis document will focus on their implementation. Future versions will\ninclude other land surface model options.\n\nLike nearly all current land surface models, the Noah and Noah-MP land\nsurface parameterizations require a few basic meteorological forcing\nvariables. Required meteorological forcing variables are listed in Table\n1.1.\n\n.. table:: **Table 1.1** Required input meteorological forcing variables for the\n Noah and Noah-MP LSMs\n :width: 90%\n :align: center\n\n +----------------------------------------+-----------+\n | **Variable** | **Units** |\n +========================================+===========+\n | Incoming shortwave radiation | `W/m^2` |\n +----------------------------------------+-----------+\n | Incoming longwave radiation | `W/m^2` |\n +----------------------------------------+-----------+\n | Specific humidity | `kg/kg` |\n +----------------------------------------+-----------+\n | Air temperature | `K` |\n +----------------------------------------+-----------+\n | Surface pressure | `Pa` |\n +----------------------------------------+-----------+\n | Near surface wind in the u - component | `m/s` |\n +----------------------------------------+-----------+\n | Near surface wind in the v-component | `m/s` |\n +----------------------------------------+-----------+\n | Liquid water precipitation rate | `mm/s` |\n +----------------------------------------+-----------+\n\n*[Different land surface models may require other or additional forcing\nvariables or the specification of forcing variables in different units.]*\n\nWhen coupled to the WRF regional atmospheric model the meteorological\nforcing data is provided by the atmospheric model with a frequency\ndictated by the land surface model time-step specified in WRF. When run\nin a standalone mode, meteorological forcing data must be provided as\ngridded input time series. Further details on the preparation of forcing\ndata for standalone WRF-Hydro execution is provided in :ref:`section-5.7`\n\nExternal, third party, Geographic Information System (GIS) tools are\nused to delineate a stream channel network, open water (i.e., lake,\nreservoir, and ocean) grid cells and groundwater/baseflow basins. Water\nfeatures are mapped onto the high-resolution terrain-routing grid and\npost-hoc consistency checks are performed to ensure consistency between\nthe coarse-resolution Noah/Noah-MP land model grid and the fine-resolution \nterrain and channel routing grid.\n\nThe WRF-Hydro model components calculate fluxes of energy and moisture\neither back to the atmosphere or also, in the case of moisture fluxes,\nto stream and river channels and through reservoirs. Depending on the\nphysics options selected, the primary output variables include but are\nnot limited to those in the table below. Output variables and options\nare discussed in detail in :ref:`section-6.0`\n\n.. table:: **Table 1.2** Primary Output data from WRF-Hydro\n :width: 90%\n :align: center\n\n +-----------------------------------------------------------+------------+\n | **Variable** | **Units** |\n +===========================================================+============+\n | Surface latent heat flux | `W/m^2` |\n +-----------------------------------------------------------+------------+\n | Surface sensible heat flux | `W/m^2` |\n +-----------------------------------------------------------+------------+\n | Ground heat flux | `W/m^2` |\n +-----------------------------------------------------------+------------+\n | Ground surface and/or canopy skin temperature | `K` |\n +-----------------------------------------------------------+------------+\n | Surface evaporation components (soil evaporation, | `kg/m^2/s` |\n | transpiration, canopy water evaporation, snow sublimation | |\n | and ponded water evaporation) | |\n +-----------------------------------------------------------+------------+\n | Soil moisture | `m^3/m^3` |\n +-----------------------------------------------------------+------------+\n | Soil temperature | `K` |\n +-----------------------------------------------------------+------------+\n | Deep soil drainage | `mm` |\n +-----------------------------------------------------------+------------+\n | Surface runoff | `mm` |\n +-----------------------------------------------------------+------------+\n | Canopy moisture content | `mm` |\n +-----------------------------------------------------------+------------+\n | Snow depth | `m` |\n +-----------------------------------------------------------+------------+\n | Snow liquid water equivalent | `mm` |\n +-----------------------------------------------------------+------------+\n | Stream channel inflow (optional with terrain routing) | `mm` |\n +-----------------------------------------------------------+------------+\n | Channel flow rate (optional with channel routing) | `m^3/s` |\n +-----------------------------------------------------------+------------+\n | Channel flow depth (optional with channel routing) | `mm` |\n +-----------------------------------------------------------+------------+\n | Reservoir height and discharge (optional with channel and | `m` and |\n | reservoir routing) | `m^3/s` |\n +-----------------------------------------------------------+------------+\n\nWRF-Hydro has been developed for Linux-based operating systems including\nsmall local clusters and high-performance computing systems.\nAdditionally, the model code has also been ported to a selection of\nvirtual machine environments (e.g. \"containers\") to enable the use of\nsmall domain cases on many common desktop computing platforms (e.g.\nWindows and MacOS) and in the cloud. The parallel computing schema is provided in\n:ref:`section-2.3`. WRF-Hydro utilizes a combination of netCDF and flat\nASCII file formats.\n\nThe majority of input and output is handled using the netCDF data format\nand the netCDF library is a requirement for running the model. Details on the\nsoftware requirements are available online on the FAQs page of the\nwebsite as well as in the *How To Build & Run WRF-Hydro V5 in Standalone\nMode* document also available from\nhttps://ral.ucar.edu/projects/wrf_hydro.\n\nWRF-Hydro is typically set up as a computationally-intensive modeling\nsystem. Simple small domains (e.g. 16 `km^2`) can be configured to\nrun on a desktop platform. Large-domain model runs can require hundreds\nor thousands of processors. We recommend beginning with an example “test\ncase” we supply at the WRF-Hydro website\nhttps://ral.ucar.edu/projects/wrf_hydro before moving to your region of\ninterest, particularly if your region or domain is reasonably large.\n" }, { "path": "docs/userguide/meta.rest", "content": ".. |version_short| replace:: 5.4\n.. |version_long| replace:: 5.4.0\n\n.. role:: center\n :class: center\n\n.. role:: underline\n :class: underline\n\n.. role:: file\n :class: filename\n\n.. role:: program\n :class: program\n\n.. role:: output\n :class: filename" }, { "path": "docs/userguide/model-code-config.rest", "content": ".. vim: syntax=rst\n.. include:: meta.rest\n\n2. Model Code and Configuration Description\n===========================================\n\nThis chapter presents the technical description of the WRF-Hydro model\ncode. The chapter is divided into the following sections:\n\n2.1 Brief Code Overview\n-----------------------\n\nWRF-Hydro is written in a modularized, modern Fortran coding structure whose\nrouting physics modules are switch-activated through a model namelist\nfile called :ref:`hydro.namelist `. The code has been\nparallelized for execution on high-performance, parallel computing\narchitectures including Linux operating system commodity clusters and\nmulti-processor desktops as well as multiple supercomputers. More detailed model\nrequirements depend on the choice of model driver, described in the next section.\n\n2.2 Driver Level Description\n----------------------------\n\nWRF-Hydro is essentially a group of modules and functions which handle\nthe communication of information between atmosphere components (such as\nWRF, CESM or prescribed meteorological analyses) and sets of land\nsurface hydrology components. From a coding perspective the WRF-hydro\nsystem can be called from an existing architecture such as the WRF\nmodel, the CESM, NASA LIS, etc. or can run in a standalone mode with its\nown driver which has adapted part of the NCAR High Resolution Land Data\nAssimilation System (HRLDAS). Each new coupling effort requires some\nbasic modifications to a general set of functions to manage the\ncoupling. In WRF-Hydro, each new system that WRF-Hydro is coupled into\ngets assigned to a directory indicating the name of the coupling\ncomponent WRF-Hydro is coupled to. For instance, the code which handles\nthe coupling to the WRF model is contained in the :file:`WRF_cpl/` directory in\nthe WRF-Hydro system. Similarly, the code which handles the coupling to\nthe offline Noah land surface modeling system is contained within the\n:file:`Noah_cpl/` directory and so on. Description of each directory is\nprovided in :ref:`section-2.4`.\n\nThe coupling structure is illustrated here, briefly, in terms of the\ncoupling of WRF-Hydro into the WRF model. A similar approach is used for\ncoupling the WRF-Hydro extension package into other modeling systems or\nfor coupling other modeling systems into WRF-Hydro.\n\n *Example:* For coupled WRF/WRF-Hydro runs the WRF-Hydro components are\n compiled as a single library function call with the WRF system. As such,\n a single executable is created upon compilation (:program:`wrf`). As\n illustrated in :ref:`Figure 2.1 `, WRF-hydro is called directly\n from WRF in the WRF surface driver module (:file:`phys/module_surface_driver.F90`).\n The code that manages the communication is the :file:`WRF_drv_Hydro.F90`\n interface module that is contained within the :file:`WRF_cpl/` directory.\n The :file:`WRF_drv_Hydro.F90` interface module is the specific instance of\n a 'General WRF-Hydro Coupling Interface' for the WRF model which passes data,\n grid and time information between WRF and WRF-Hydro. Components within\n WRF-Hydro then manage the dynamic regridding “data mapping” and sub-component\n routing functions (e.g. surface, subsurface and/or channel routing) within\n WRF-Hydro (see :ref:`Fig. 1.1 ` for an illustration of components\n contained within WRF-Hydro).\n\nUpon completion of the user-specified routing functions, WRF-Hydro will\nremap the data back to the WRF model grid and then pass the necessary\nvariables back to the WRF model through the :file:`WRF_drv_Hydro.F90` interface\nmodule. Therefore, the key component of the WRF-Hydro system is the\nproper construction of the :file:`WRF_cpl_Hydro` interface module (or more\ngenerally :file:`{XXX}_cpl_Hydro`). Users wishing to couple new modules to\nWRF-Hydro will need to create a unique “General WRF-Hydro Coupling\nInterface” for their components. Some additional examples of this\ninterface module are available upon request for users to build new\ncoupling components. This simple coupling interface is similar in\nstructure to other general model coupling interfaces such as those\nwithin the Earth System Modeling Framework (ESMF) or the Community\nSurface Dynamics Modeling System (CSDMS).\n\n.. _figure2.1:\n.. figure:: media/wrf_coupling.png\n :align: center\n\n **Figure 2.1** Schematic illustrating the coupling and calling structure\n of WRF-Hydro from the WRF Model.\n\nThe model code has been compiled using the Intel :program:`ifort` compiler and\nthe freely-available GNU Fortran compiler :program:`gfortran` for use with\nUnix-type operating systems on desktops, clusters, and supercomputing\nsystems. Because the WRF-Hydro modeling system relies on netCDF input and\noutput file conventions, netCDF Fortran libraries must be installed and\nproperly compiled on the system upon which WRF-Hydro is to be executed.\nNot doing so will result in numerous error messages such as :code:`*…undefined\nreference to netCDF library …*` or similar messages upon compilation.\nFor further installation requirements see the FAQs page of the website\nas well asin the *How To Build & Run WRF-Hydro v5 in Standalone Mode* document\nalso available from https://ral.ucar.edu/projects/wrf_hydro.\n\n.. _section-2.3:\n\n2.3 Parallelization strategy\n----------------------------\n\nParallelization of the WRF-Hydro code utilizes geographic domain\ndecomposition and 'halo' array passing structures similar to those used\nin the WRF atmospheric model (:ref:`Figures 2.2 ` and :ref:`2.3 `).\nMessage passing between processors is accomplished using MPI protocols. Therefore the\nrelevant MPI libraries must be installed and properly compiled on the\nsystem upon which WRF-Hydro is to be executed in parallel mode.\nCurrently sequential compile is not supported so MPI libraries are\nrequired even if running over a single core.\n\n.. figure:: media/gridded_decomp.png\n :align: center\n :name: figure2.2\n\n **Figure 2.2** Schematic of parallel domain decomposition scheme in\n WRF-Hydro. Boundary or 'halo' arrays in which memory is shared between\n processors (P1 and P2) are shaded in purple.\n\n.. figure:: media/channel_decomp.png\n :align: center\n :name: figure2.3\n\n **Figure 2.3** Schematic of parallel domain decomposition scheme in\n WRF-Hydro as applied to channel routing. Channel elements (stars) are\n communicated at boundaries via ‘halo’ arrays in which memory is shared\n between processors (P1 and P2). Black and red stars indicate overlapping\n channel elements used in the diffusive wave solver.\n\n.. _section-2.4:\n\n2.4 Directory Structures\n------------------------\n\nThe top-level directory structure of the code is provided below as\nnested under the :file:`wrf_hydro_nwm_public` root directory and the\nsubdirectory structures are described thereafter. The tables below provide\nbrief descriptions of the file contents of each directory where the model code\nresides.\n\n.. default-role:: file\n\n.. table:: **Table 2.1** Description of the file contents of each directory\n where the model *code* resides\n :align: center\n :width: 90%\n :name: table-2.1\n\n +-------------------------+--------------------------------------------------+\n | **File/directory name** | **Description** |\n | | |\n +=========================+==================================================+\n | Main code files and directories (under version control in |\n | a GitHub repository): |\n +-------------------------+--------------------------------------------------+\n | :underline:`Top-Level Files and Directories:` |\n +-------------------------+--------------------------------------------------+\n | `CMakeLists.txt` | Top-level CMake build script used to compile |\n | | the WRF-Hydro model |\n +-------------------------+--------------------------------------------------+\n | `docs/` | Pointer to location of full documentation (i.e. |\n | | this document). |\n +-------------------------+--------------------------------------------------+\n | `tests/` | Scripts and data used to test the model |\n +-------------------------+--------------------------------------------------+\n | `src/` | WRF-Hydro Model source code |\n +-------------------------+--------------------------------------------------+\n | :underline:`Source code directories under \\`src/\\`:` |\n +-------------------------+--------------------------------------------------+\n | `CPL/Noah_cpl/` | Contains the WRF-Hydro coupling interface for |\n | | coupling WRF-Hydro components with the |\n | | standalone (offline) Noah land surface model |\n | | data assimilation and forecasting system |\n +-------------------------+--------------------------------------------------+\n | `CPL/NoahMP_cpl/` | Contains the WRF-Hydro coupling interface for |\n | | coupling WRF-Hydro components with the |\n | | standalone (offline) Noah-MP land surface model |\n | | data assimilation and forecasting system |\n +-------------------------+--------------------------------------------------+\n | `CPL/WRF_cpl/` | Contains the WRF-Hydro coupling interface for |\n | | coupling WRF-Hydro components with the WRF |\n | | system |\n +-------------------------+--------------------------------------------------+\n | `CPL/CLM_cpl/` , | Work in progress for ongoing coupling work. |\n | `CPL/LIS_cpl/` , | Only NUOPC is actively supported. |\n | `CPL/NUOPC_cpl/` | |\n +-------------------------+--------------------------------------------------+\n | `Data_Rec/` | Contains some data declaration modules |\n +-------------------------+--------------------------------------------------+\n | `Debug_Utilities/` | Utilities for debugging |\n +-------------------------+--------------------------------------------------+\n | `deprecated/` | Contains files not currently used |\n +-------------------------+--------------------------------------------------+\n | `HYDRO_drv/` | Contains the high-level WRF-Hydro component |\n | | driver: `module_HYDRO_drv.F90` |\n +-------------------------+--------------------------------------------------+\n | `Land_models/Noah/` | Contains the Noah land surface model driver for |\n | | standalone or uncoupled applications |\n +-------------------------+--------------------------------------------------+\n | `Land_models/NoahMP/` | Contains the Noah-MP land surface model driver |\n | | for standalone or uncoupled applications |\n +-------------------------+--------------------------------------------------+\n | `MPP/` | Contains MPI parallelization routines and |\n | | functions |\n +-------------------------+--------------------------------------------------+\n | `nudging/` | Contains nudging data assimilation routines and |\n | | functions |\n +-------------------------+--------------------------------------------------+\n | `Rapid_routing/` | Contains the files necessary for RAPID routing |\n | | model coupling. Unsupported as version of RAPID |\n | | is out of date. |\n +-------------------------+--------------------------------------------------+\n | `Routing/` | Contains modules and drivers related to specific |\n | | routing processes in WRF-Hydro |\n +-------------------------+--------------------------------------------------+\n | `template/` | Contains example namelist files for Noah, |\n | | Noah-MP and the WRF-Hydro modules (HYDRO). |\n | | Default and example parameter tables are also |\n | | included for HYDRO. Note: Parameter tables for |\n | | Noah and Noah-MP are stored within the |\n | | :file:`Land_models` directory. |\n +-------------------------+--------------------------------------------------+\n | `utils/` | internal model versioning |\n +-------------------------+--------------------------------------------------+\n | :underline:`Files:` |\n +-------------------------+--------------------------------------------------+\n | `docs/BUILD.md` | WRF-Hydro build instructions for the standalone |\n | | model |\n +-------------------------+--------------------------------------------------+\n | `wrf_hydro_config` | Configure script for coupled WRF \\| WRF-Hydro |\n | | configuration |\n +-------------------------+--------------------------------------------------+\n | `\\*.json` | JSON files used for testing |\n +-------------------------+--------------------------------------------------+\n | Local files and directories created by CMake in the build directory |\n | (not part of the version controlled repository): |\n +-------------------------+--------------------------------------------------+\n | :underline:`Directories:` |\n +-------------------------+--------------------------------------------------+\n | `lib/` | Directory where compiled libraries are written |\n +-------------------------+--------------------------------------------------+\n | `mods/` | Directory where compiled `.mod`` files are |\n | | written upon compilation |\n +-------------------------+--------------------------------------------------+\n | `Run/` | Directory where model executable, example |\n | | parameter tables, and example namelist files |\n | | for the compiled model configuration will be |\n | | populated. These files will be overwritten on |\n | | compile. It is recommended the user copy the |\n | | contents of this directory into an alternate |\n | | location, separate from the code, to execute |\n | | model runs. |\n +-------------------------+--------------------------------------------------+\n\n.. table:: **Table 2.2** Modules within the :file:`Routing/` directory which relate to\n routing processes in WRF-Hydro\n :width: 90%\n :align: center\n :name: table-2.2\n\n +--------------------------------------+-------------------------------------------------+\n | **File/directory name** | **Description** |\n | | |\n +======================================+=================================================+\n | `Overland/` | Directory containing overland routing modules |\n +--------------------------------------+-------------------------------------------------+\n | `Makefile` | Makefile for WRF-Hydro component |\n +--------------------------------------+-------------------------------------------------+\n | `module_channel_routing.F90` | Module containing WRF-Hydro channel routing |\n | | components |\n +--------------------------------------+-------------------------------------------------+\n | `module_date_utilities_rt.F90` | Module containing various date/time utilities |\n | | for routing routines |\n +--------------------------------------+-------------------------------------------------+\n | `module_GW_baseflow.F90` | Module containing model physics for simple |\n | | baseflow model |\n +--------------------------------------+-------------------------------------------------+\n | `module_HYDRO_io.F90` | Module containing WRF-Hydro input and (some) |\n | | output functions |\n +--------------------------------------+-------------------------------------------------+\n | `module_HYDRO_utils.F90` | Module containing several WRF-Hydro utilities |\n | | |\n +--------------------------------------+-------------------------------------------------+\n | `module_lsm_forcing.F90` | Module containing the options for reading in |\n | | different forcing data types |\n +--------------------------------------+-------------------------------------------------+\n | `module_noah_chan_param_init_rt.F90` | Module containing routines to initialize |\n | | WRF-Hydro routing grids |\n +--------------------------------------+-------------------------------------------------+\n | `module_NWM_io.F90` | Module containing output routines to produce |\n | | CF-compliant desired output files. |\n +--------------------------------------+-------------------------------------------------+\n | `module_NWM_io_dict.F90` | Dictionary to support CF-compliant output |\n | | routines. |\n +--------------------------------------+-------------------------------------------------+\n | `module_RT.F90` | Module containing the calls to all the |\n | | WRF-Hydro routing initialization |\n +--------------------------------------+-------------------------------------------------+\n | `module_UDMAP.F90` | Module for the user-defined mapping |\n | | capabilities, currently used for NWM |\n | | configuration (NHDPlus network) |\n +--------------------------------------+-------------------------------------------------+\n | `Noah_distr_routing.F90` | Module containing overland flow and subsurface |\n | | physics routines and grid disaggregation |\n | | routine |\n +--------------------------------------+-------------------------------------------------+\n | `module_gw_gw2d.F90` | Module containing routines for the experimental |\n | | 2D groundwater model |\n +--------------------------------------+-------------------------------------------------+\n\n.. default-role::\n\n2.5 Model Sequence of Operations\n--------------------------------\n\nThe basic structure and sequencing of WRF-Hydro are diagrammatically\nillustrated in :ref:`Figure 2.4 ` management, initialization,\nI/O and model completion) is handled by the WRF-Hydro system unless\nWRF-Hydro is coupled into, and beneath, a different modeling architecture.\nThe WRF-Hydro system can either call an independent land model driver such\nas the NCAR High Resolution Land Data Assimilation System (HRLDAS) for\nboth Noah and Noah-MP land surface models to execute column land surface\nphysics or be called by a different modeling architecture such as WRF,\nthe NCAR CESM, or the NASA LIS. When run in a standalone or “uncoupled”\nmode, WRF-Hydro must read in the meteorological forcing data necessary to\nperform land surfac model calculations and it contains the necessary\nroutines to do this. When run in a coupled mode with WRF or another larger\narchitecture, WRF-Hydro receives meteorological forcing or land surface\nstates and fluxes from the parent architecture. The basic execution\nprocess is as follows:\n\n 1. Upon initialization static land surface physiographic data are read\n into the WRF-Hydro system and the model domain and computational\n arrays are established.\n\n 2. Depending on whether or not WRF-Hydro is run offline as a standalone\n system or whether it is coupled into another architecture, either\n forcing data is read in or land surface states and fluxes are passed\n in.\n\n 3. For offline simulations which require land model execution, the\n gridded column land surface model is executed.\n\n 4. If routing is activated and there is a difference between the land\n model grid and the routing grid, land surface states and fluxes are\n then disaggregated to the high-resolution terrain routing grids.\n\n 5. If activated, sub-surface routing physics are executed.\n\n 6. If activated, surface routing physics are executed.\n\n 7. If activated, the conceptual base flow model is executed.\n\n 8. If activated, channel and reservoir routing components are executed.\n Streamflow nudging is currently available to be applied within the\n Muskingum-Cunge routing call.\n\n 9. Updated land surface states and fluxes are then aggregated from the\n high-resolution terrain routing grid to the land surface model grid\n (if routing is activated and there is a difference between the land\n model grid and the routing grid).\n\n 10. Results from these integrations are then written to the model output\n files and restart files or, in the case of a coupled WRF/WRF-Hydro\n simulation, passed back to the WRF model.\n\nAs illustrated at the bottom of the :ref:`Figure 2.4 `\ncomponent with `NCAR’s DART `__\n(https://www.image.ucar.edu/DAReS/DART/) has been developed. This\ncurrently only works with WRF-Hydro in standalone mode. DART updates\nWRF-Hydro states independently of model time integration.\n\n.. _figure2.4:\n.. figure:: media/modular_calling.png\n :align: center\n\n **Figure 2.4** Modular calling structure of WRF-Hydro.\n\n2.6 WRF-Hydro compile-time options\n----------------------------------\n\nCompile time options are choices about the model structure which are\ndetermined when the model is compiled. Compile time choices select a\nWRF-Hydro instance from some of the options illustrated in\n:ref:`Figure 2.4. ` Compile time options fall into two\ncategories: 1) the selected model driver, and 2) the compile options\nfor the choice of driver. In this guide we limit the description of\nmodel drivers to WRF, Noah, and Noah-MP. Configuring, compiling, and\nrunning WRF-Hydro in standalone mode is described in detail in the\n*How To Build & Run WRF-Hydro V5 in Standalone Mode* document available\nfrom https://ral.ucar.edu/projects/wrf_hydro.\n\nCompile-time options are listed during the CMake build configuration\nprocess. These options are passed to CMake as environment variables\nusing ``-D[OPTION]=[0|1]`` syntax. Those options/variables are listed\nbelow along with a description of what each option does:\n\n.. parsed-literal::\n\n ===================================================================\n -- Start of WRF-Hydro Env VARIABLES\n WRF_HYDRO = 1 *Always set to 1 for WRF-Hydro*\n\n HYDRO_D = 0 *Set to 1 for enhanced diagnostic output*\n\n SPATIAL_SOIL = 1 *Set to 1 to allow NoahMP LSM to use*\n *spatially distributed parameter*\n *vs. a table based on soil class and*\n *land use categories*\n\n WRFIO_NCD_LARGE_FILE_SUPPORT = 0 *Set to 1 if using a*\n *WRF/WRF-Hydro coupled build*\n\n NCEP_WCOSS = 0 *Set to 1 if compile for NOAA WCOSS*\n\n NWM_META = 0 *Set to 1 if using NWM-style metadata in output*\n\n WRF_HYDRO_NUDGING = 0 *Set to 1 if using streamflow nudging*\n\n PRECIP_DOUBLE = 0 *Set to 1 to double all incoming*\n *precipitation (for debug purposes only)*\n\n WRF_HYDRO_NUOPC = 0 *Set to 1 when using NUOPC coupling*\n ===================================================================\n\n.. _section-2.7:\n\n2.7 WRF-Hydro run time options\n------------------------------------\n\nThere are two namelist files that users must edit in order to\nsuccessfully execute the WRF-Hydro system in a standalone mode or\n“uncoupled” to WRF. One of these namelist files is the hydro.namelist\nfile and in it are the various settings for operating all of the routing\ncomponents of the WRF-Hydro system. The hydro.namelist file is\ninternally commented so that it should be clear as to what is needed for\neach setting. A full annotated example of the hydro.namelist file is\nprovided in :ref:`section-a6`.\n\nThe second namelist is the namelist which specifies the land surface\nmodel options to be used. This namelist can change depending on which\nland model is to be used in conjunction with the WRF-Hydro routing\ncomponents. For example, a user would use one namelist when running the\nNoah land surface model coupled to WRF-Hydro but that user would need to\nuse a different namelist file when running the CLM model, the Noah-MP\nmodel or NASA LIS model coupled to WRF-Hydro. The reason for this is\nWRF-Hydro is intended to be *minimally-invasive* to other land surface\nmodels or land model driver structures and not require significant\nchanges to those systems. This minimal invasiveness facilitates easier\ncoupling with new systems and helps facilitate easy supportability and\nversion control with those systems. When the standalone WRF-Hydro model\nis compiled the appropriate namelist.hrldas template file is copied over\nto the Run directory based upon the specified land surface model.\n\nIn WRF-Hydro v\\ |version_short|, Noah and Noah-MP land surface models are the main\nland surface model options when WRF-Hydro is run in standalone mode.\nBoth Noah and Noah-MP use a namelist file called namelist.hrldas, which,\nas noted above, will contain different settings for the two different\nland surface models. For a run where WRF-Hydro is coupled to the WRF\nmodel, the WRF model input file namelist.input becomes the second\nnamelist file. Full annotated example namelist.hrldas files for Noah and\nNoah-MP are provided in :ref:`section-a4` and :ref:`section-a5`.\n\n.. _section-2.8:\n\n2.8 Build Instructions\n------------------------------------\n.. include:: ../BUILD.rst\n :start-line: 2\n" }, { "path": "docs/userguide/model-inputs-preproc.rest", "content": ".. vim: syntax=rst\n.. include:: meta.rest\n\n5. Model inputs and preprocessing\n=================================\n\nThis chapter describes WRF-Hydro input and parameter file requirements\nand the preprocessing tools used to generate them.\n\n5.1 Overview of model inputs\n----------------------------\n\n.. _figure-5.1:\n.. figure:: media/physics-inputs.png\n :align: center\n :figwidth: 90%\n\n **Figure 5.1** WRF-Hydro input and parameter files organized by model\n physics component. See the Key for files specific to a certain land\n model or channel configuration.\n\nWRF-Hydro requires a number of input files describing the model domain,\nparameters, initial conditions, and when run in a standalone\nconfiguration meteorological forcing files. A full list of these files\nbroken up by model physics component is shown in :ref:`Figure 5.1 `.\nNote that the set of files required to run WRF-Hydro varies depending upon\nmodel configuration. For example, different land surface models and model\nphysics components may require different parameter and input files.\n\nWhile some parameter files and templates are included with the model\nsource code, most must be generated by the user. We provide a number of\nscripts and preprocessing utilities on the WRF-Hydro website\n(https://ral.ucar.edu/projects/wrf_hydro/pre-processing-tools) in order to aid in this\nprocess. These include NCAR Command Language (NCL) scripts to regrid\nforcing data from commonly used data sources, R scripts to generate\nparameter and model initialization files, and a set of Python based\nArcGIS pre-processing tools. The specific utilities used to generate\ndifferent files are listed in :ref:`Table 5.1 `. Users\nshould be aware that these tools do not support all potential datasets\nand use cases and that the use of default parameters will often result\nin suboptimal model performance. More details regarding the pre-processing\nutilities, file requirements, and descriptions follow.\n\nIn addition to the ArcGIS pre-processing tools, the WRF-Hydro group has also\ndeveloped a set of open-source, Python-based preprocessing tools. These tools\nreplicate existing capabilities and operate within the same software\nenvironments as WRF-Hydro. Built with Python 3 and libraries such as\nWhitebox Tools, NumPy, and GDAL, users can configure their environments\nusing Anaconda, Miniconda, or custom setups. This initiative responds to user\ndemand for an open-source option, ensuring portability and multi-platform\nsupport while offering efficient, parallelized geoprocessing. All underlying\nlibraries are open-source, eliminating proprietary licensing restrictions.\nFor more information, please visit:\nhttps://ral.ucar.edu/dataset/open-source-wrf-hydro-gis-pre-processing-tools-beta.\n\n5.2 Domain processing and description of surface physiographic input files\n--------------------------------------------------------------------------\n\nThis subsection describes the process of defining the WRF-Hydro model\ndomain, generating model initial conditions, and deriving geospatial\ninput and parameter files via the WRF-Hydro GIS pre-processing tools. As\nnoted in the previous section a number of scripts and utilities have\nbeen developed to facilitate the creation of these files. Additionally,\nwe rely on a utility within the Weather Research and Forecasting (WRF)\nmodel preprocessing system (WPS) called GEOGRID to define the land\nsurface model grid and relevant geospatial data and produce the\nresulting :file:`geo_em.d0{x}.nc` file hereafter referred to as a “geogrid”\nfile. This geogrid file is then used as input to the ArcGIS preprocessing\ntools, along with external datasets such as high resolution topographic\ndata, which generate the high resolution routing grid and all surface\nphysiographic input data files required by the model. The geogrid file\nis also passed to utilities in order to generate land surface model\ninitial condition files.\n\n5.2.1 Defining the model domain\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThe data required to define the domain and geospatial attributes of a\nspatially-distributed, or gridded, 1-dimensional (vertical) land surface\nmodel (LSM) are specified in a geogrid (:file:`geo_em.d0{x}.nc`) netCDF file.\nThis file is generated by the :program:`GEOGRID` utility in the `WRF preprocessing system (WPS)\n`_.\nWPS is a preprocessing system that prepares both land surface and\natmospheric data for use in the model. The GEOGRID component of WPS\nautomates the procedure of defining in space, georeferencing and\nattributing most of the land surface parameter data required to execute\nboth the Noah and Noah-MP land surface models. GEOGRID interpolates land\nsurface terrain, soils and vegetation data from standard, readily\navailable data products. These data are distributed as a geographical\ninput data package via the WRF website. Complete documentation and user\ninstructions for use of the WPS system are provided online by NCAR and\nare updated regularly and, thus, are not discussed in great detail here.\nThis :file:`geo_em.d0{x}.nc` file is also required as input to other WRF-Hydro\npreprocessing utilities.\n\n5.2.2 Initial land surface conditions\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nInitial conditions for the land surface, such as soil moisture, soil\ntemperature, and snow states, are prescribed via the :file:`wrfinput_d0x.nc`\nfile. This netCDF file can be generated one of two ways, through the\n:program:`real.exe` program within WRF or via an R script (:file:`create_wrfinput.R`)\ndistributed on the `WRF-Hydro website `_.\nWhen created using the real.exe program in WRF,\ninitial conditions are pulled from existing reanalysis\nor realtime products (see WRF documentation for data and system\nrequirements). This will typically result in more realistic initial\nmodel states. However, the process is somewhat involved and requires the\nuser to obtain additional external datasets.\n\nThe R script will create a simplified version of the :file:`wrfinput_d0x.nc`\nfile including all necessary fields for the\nNoah-MP land surface model, but with spatially uniform initial conditions\nthat are prescribed within the script and requires only the geogrid file\n:file:`geo_em.d0{x}.nc` as input. Step-wise instructions and detailed\nrequirements are included in the documentation distributed with the script.\nUsers should be aware that the model will likely require additional spin-up\ntime when initialized from this file.\n\n5.2.3 Generating hydrologic routing input files via the WRF-Hydro GIS pre-processing tools\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nA suite of Python based utilities, the *WRF-Hydro GIS Pre-processing\nToolkit*, have been developed to facilitate the process of deriving\nWRF-Hydro input and parameter files from commonly available geospatial\ndata products, such as hydrologically processed digital elevation\nmodels. A large number of the hydro input and parameter files described\nin :ref:`Table 5.1 ` can be generated by these tools as well\nas a geospatial metadata file to support georeferencing of WRF-Hydro model\noutput files and relevant shapefiles to aid in visualizing the model\ncomponents. The WRF-Hydro GIS pre-processing tools are developed to\nfunction as an additional ArcToolbox within the Esri ArcGIS software.\nSpecific operating system and software requirements are addressed in the\nfull *WRF-Hydro GIS Pre-processing Toolkit* `documentation\n`_.\n\nThe minimum input data requirements for the pre-processing tools are the\ngeogrid file :file:`geo_em.d0x.nc` and a hydrologically conditioned digital\nelevation model covering the full extent of the domain of interest. From\nthese datasets the terrain routing files (e.g. :file:`Fulldom_hires.nc`, :file:`hydro2dtbl.nc`)\nand channel routing files (e.g. :file:`Route_Link.nc`) can be created (see Appendices :ref:`A7 `,\n:ref:`A10 `, and :ref:`A11 `).\n\nA ``.txt`` or ``.csv`` file with stream gage locations can optionally\nbe supplied, allowing the user to demarcate these locations in the model input files\nand optionally produce time series outputs (e.g. :file:`*CHANOBS_DOMAIN{x}`) for only these locations.\nThis text file denoting the location of stream gages or \"forecast points\"\ncan also be used to generate groundwater input files. Effectively\ngroundwater basins are delineated above each of these locations and\ndefault parameters will be assigned to a parameter file that can also be\ngenerated using this tool. More details are available in the *WRF-Hydro GIS Pre-processing Toolkit* `documentation\n`_.\n\nLake and reservoir component input files also require a supplementary\ninput file. A shapefile containing polygons defining the extent of each\nlake must be provided as input. From this file and the processed digital\nelevation model a number of parameters are derived for each lake\n(however, note that other parameters are only assigned a global default\nvalue). More details about this process and the contents of the input\nand parameter files can be found in Appendix :ref:`A14 `\nand the full *WRF-Hydro GIS Pre-processing Toolkit* `documentation\n`_.\n\nThe *WRF-Hydro GIS Pre-processing Toolkit* will also produce a geospatial\nmetadata file (e.g. :file:`GEOGRID_LDASOUT_Spatial_Metadata.nc`) for the land surface\nmodel grid (as defined by the geogrid file :file:`geo_em.d0{x}.nc`). This file contains\nprojection and coordinate information for the land surface model grid.\nWhile this file is an optional input to WRF-Hydro, in combination with\nthe new file output routines in version 5.0 of WRF-Hydro this file will\nallow for the creation of CF (Climate and Forecast metadata convention)\ncompliant output files. This allows for files to be more easily viewed\nin GIS systems (e.g. ArcGIS and QGIS) as well as other visualization\nsoftware. Additional documentation for this toolkit including step by\nstep instructions and detailed requirements is provided on the WRF-Hydro\nwebsite.\n\nRequirements for the hydro components of the model (i.e. those not\ndirectly associated with the land surface model or data assimilation)\nare described in the model physics :ref:`Section\n3 ` and in :ref:`Table 5.1 `.\n\n.. table:: **Table 5.1** Input and parameter files for hydro components of\n WRF-Hydro.\n :width: 90%\n :align: center\n :name: table-5.1\n\n +---------------------------+---------------------+----------------------------------+--------------+\n | **Filename** | **Description** | **Source** | **Required** |\n +===========================+=====================+==================================+==============+\n | :file:`Fulldom_hires.nc` | High resolution | WRF-Hydro GIS | Yes |\n | | full domain file. | pre-processing | |\n | | Includes all fields | toolkit | |\n | | specified on the | | |\n | | routing grid. | | |\n +---------------------------+---------------------+----------------------------------+--------------+\n | :file:`Route_Link.nc` | Channel reach | WRF-Hydro GIS | When reach |\n | | parameters (ComID, | pre-processing | based |\n | | gage ID, bottom | toolkit | routing is |\n | | width, slope, | | used |\n | | roughness, order, | | (including |\n | | etc.) | | user defined |\n | | | | mapping) |\n +---------------------------+---------------------+----------------------------------+--------------+\n | :file:`GWBASINS.nc` | 2D file defining | WRF-Hydro GIS | When the |\n | | the locations of | pre-processing | baseflow |\n | | groundwater basins | toolkit | bucket model |\n | | on a grid | | is turned on |\n | | | | and user |\n | | | | defined |\n | | | | mapping is |\n | | | | off |\n +---------------------------+---------------------+----------------------------------+--------------+\n | :file:`GWBUCKPARM.nc` | Groundwater | WRF-Hydro GIS | When the |\n | | parameter table | pre-processing | baseflow |\n | | containing bucket | toolkit | bucket model |\n | | model parameters | | is turned on |\n | | for each basin | | |\n +---------------------------+---------------------+----------------------------------+--------------+\n | :file:`LAKEPARM.nc` | Lake parameter | WRF-Hydro GIS | When lake |\n | | table containing | pre-processing | and |\n | | lake model | toolkit | reservoir |\n | | parameters for each | | routing is |\n | | catchment | | turned on |\n +---------------------------+---------------------+----------------------------------+--------------+\n | :file:`hydro2dtbl.nc` | Spatially | :file:`create_SoilProperties.R` | When using |\n | | distributed netCDF | script | spatially |\n | | version of | | distributed |\n | | :file:`HYDRO.TBL` | (will also be automatically | terrain |\n | | | generated by WRF-Hydro) | routing |\n | | | | parameters |\n +---------------------------+---------------------+----------------------------------+--------------+\n | :file:`HYDRO.TBL` | Parameter table for | :file:`template/HYDRO` | Yes |\n | | lateral flow | directory in the | |\n | | routing within | model code | |\n | | WRF-Hydro. In the | | |\n | | :file:`HYDRO.TBL` | | |\n | | file parameters are | | |\n | | specified by land | | |\n | | cover type or soil | | |\n | | category | | |\n +---------------------------+---------------------+----------------------------------+--------------+\n | :file:`HYDRO_MODIS.TBL` | Version of | :file:`template/HYDRO` | Replacement |\n | | :file:`HYDRO.TBL` | directory in the | for |\n | | using MODIS land | model code | |HYDRO.TBL| |\n | | use categories | | when using |\n | | rather than USGS. | | MODIS land |\n | | (Change name to | | use |\n | | :file:`HYDRO.TBL` | | categories |\n | | for use.) | | |\n +---------------------------+---------------------+----------------------------------+--------------+\n | :file:`CHANPARM.TBL` | Parameters for | :file:`template/HYDRO` | When gridded |\n | | gridded channel | directory in the | routing is |\n | | routing scheme. | model code | used |\n | | Parameters are | | |\n | | specified by | | |\n | | Strahler stream | | |\n | | order | | |\n +---------------------------+---------------------+----------------------------------+--------------+\n | :file:`spatialweights.nc` | Spatial weight file | distributed with NWM domain | When using |\n | | used to map fluxes | files | user defined |\n | | to catchment | | mapping |\n | | objects | | |\n +---------------------------+---------------------+----------------------------------+--------------+\n.. |HYDRO.TBL| replace:: :file:`HYDRO.TBL`\n\n.. _section-5.3:\n\n5.3 Description of land surface model and lateral routing parameter files\n-------------------------------------------------------------------------\n\nParameters for the Noah and Noah-MP land surface models as well as for\nthe lateral routing component are specified via a collection of text\nfiles (i.e. parameter tables) denoted by the file suffix ``.TBL``.\nDefault parameter tables for the Noah and Noah-MP models are included in\nthe WRF-Hydro source code within the directory structure for their\nrespective land model and the appropriate files are automatically moved\nto the Run directory upon building the model.\n\nThe Noah land surface model requires three parameter table files, outlined\nin :ref:`Table 5.2 `. The first of these is the general parameter\ntable or :file:`GENPARM.TBL`. This file contains a number of global parameters\nfor the Noah land surface model. The next is the vegetation parameter table or\n:file:`VEGPARM.TBL`. This file contains parameters that are a function\nof land cover type. The final table is the soil parameter table or\n:file:`SOILPARM.TBL`. This parameter table contains parameters that are\nassigned based upon the soil classification. The variables contained\nwithin these files are described in the Appendix :ref:`A8 `.\n\n.. table:: **Table 5.2** Parameter tables for the Noah land surface model. These\n parameter tables can be found within the land surface model source code\n :file:`Run/` directory and will be copied over the the WRF-Hydro Run\n directory when the compile script for this LSM is run.\n :align: center\n :width: 90%\n :name: table-5.2\n\n .. default-role:: file\n\n +---------------+-------------------------------------------+----------------+\n | **Filename** | **Description** | **Required** |\n +===============+===========================================+================+\n | GENPARM.TBL | Miscellaneous model parameters that are | Yes |\n | | applied globally | |\n +---------------+-------------------------------------------+----------------+\n | VEGPARM.TBL | Vegetation parameters indexed by land use | Yes |\n | | / land cover categories | |\n +---------------+-------------------------------------------+----------------+\n | SOILPARM.TBL | Soil parameters indexed by soil texture | Yes |\n | | classes | |\n +---------------+-------------------------------------------+----------------+\n\n .. default-role::\n\nThe Noah-MP land surface model also requires three parameter table files, outlined\nin :ref:`Table 5.3 `. The first of these is the general parameter\ntable or :file:`GENPARM.TBL`. This file contains a number of global parameters\nfor the Noah-MP land surface model. The next table is the\n:file:`MPTABLE.TBL`. This file contains parameters that are a function\nof land cover type. The last one is the soil parameter table or\n:file:`SOILPARM.TBL`. This parameter table contains parameters that are\nassigned based upon the soil classification. The variables contained within these files are\ndescribed in Appendix :ref:`A9 `.\n\nAs part of work conducted for the National Water Model implementation,\nthe ability to specify a number of these land surface model parameters\nspatially on a two or three dimensional grid was introduced. This is\ndone through the use of the compile time option ``SPATIAL_SOIL`` and the\nspecification of a netCDF format parameter file with the default\nfilename :file:`soil_properties.nc`. A list of the variables contained in\nthis file is included in Appendix :ref:`A9 `.\n\n.. table:: **Table 5.3** Parameter tables for the Noah-MP land surface model. These\n parameter tables can be found within the land surface model source code\n Run directory and will be copied over to the WRF-Hydro Run directory\n when the compile script for this LSM is run.\n :name: table-5.3\n :align: center\n :width: 90%\n\n .. default-role:: file\n\n +----------------------+---------------------------------------------+----------------+\n | **Filename** | **Description** | **Required** |\n +======================+=============================================+================+\n | `GENPARM.TBL` | Miscellaneous model parameters that are | Yes |\n | | applied globally | |\n +----------------------+---------------------------------------------+----------------+\n | `MPTABLE.TBL` | Vegetation parameters indexed by land use / | Yes |\n | | land cover categories | |\n +----------------------+---------------------------------------------+----------------+\n | `SOILPARM.TBL` | Soil parameters indexed by soil texture | Yes |\n | | classes | |\n +----------------------+---------------------------------------------+----------------+\n | `soil_properties.nc` | NetCDF file with spatially distributed land | No |\n | | surface model parameters used when | |\n | | WRF-Hydro is compiled with SPATIAL_SOIL=1. | |\n | | This allows the user to specify parameters | |\n | | on the model grid rather than as a single | |\n | | value or function of soil or land cover | |\n | | type. | |\n | | | |\n | | This file is created by the | |\n | | :file:`create_SoilProperties.R` script | |\n +----------------------+---------------------------------------------+----------------+\n\n .. default-role:: file\n\n\nParameters for the lateral routing component of WRF-Hydro are specified\nin a similar way via the :file:`HYDRO.TBL` file or the :file:`hydro2dtbl.nc`\nfile. This file is also distributed with the WRF-Hydro source code in the\n:file:`templates/HYDRO` directory and is copied over to the :file:`Run` directory\nupon building the model. There is also an additional :file:`HYDRO_MODIS.TBL`\nfile for those using the MODIS land cover classification scheme.\n\nThe :file:`HYDRO.TBL` parameter table file contains 2 parts. The first part\ncontains the Manning's roughness coefficients for overland flow as a\nfunction of the USGS vegetation types as that data is used in the Noah\nland surface model. The roughness values are strictly indexed to the\nUSGS vegetation classes so that if one wanted to use a different\nvegetation index dataset (e.g. the MODIS/IGBP option in the Noah land\nsurface model) a user would need to remap these roughness values to\nthose new vegetation indices. Users can alter the values of overland\nflow roughness here for a given vegetation type. However, users may also\n'scale' these initial values of roughness by changing the gridded values\nof the overland flow roughness scaling factor (``OVROUGHRTFAC``) that are\ncontained within the high resolution routing data netCDF file (e.g., :file:`Fulldom_hires{x}.nc`).\nBecause hydrological models are often calibrated over a particular region or\nwatershed as opposed to a specific vegetation type it is recommended\nthat users modify the ``OVROUGHRTFAC`` scaling factor as opposed to altering\nthe roughness values in :file:`HYDRO.TBL`.\n\nThe second part of the :file:`HYDRO.TBL` parameter table contains several soil\nhydraulic parameters that are classified as functions of soil type.\nThese soil parameters are copied from the :file:`SOILPARM.TBL` parameter table\nfrom the Noah land surface model. They are provided in :file:`HYDRO.TBL` to\nallow the user to modify those parameters as needed during model\ncalibration activities without modifying the :file:`SOILPARM.TBL` file and thus\nis just done for convenience. In effect, when routing options in\nWRF-Hydro are activated the code will read the soil hydraulic parameters\nfrom :file:`HYDRO.TBL`. If the Noah land surface model is executed within WRF-Hydro\nwithout any of the routing options activated, the code will simply use the\nparameter values specified in :file:`HYDRO.TBL`.\n\nThe file :file:`hydro2dtbl.nc` is a spatially distributed netCDF file version of the\n:file:`HYDRO.TBL` parameter table. This netCDF file can be created via the\n:file:`create_SoilProperties.R` script distributed on the WRF-Hydro website\n(https://ral.ucar.edu/projects/wrf_hydro) or will automatically be\ngenerated by the model from the :file:`HYDRO.TBL` if the filename specified in\nthe :file:`hydro.namelist` does not already exist. See Appendix\n:ref:`A10 ` for further explanation of the variables in the\n:file:`HYDRO.TBL` and :file:`hydro2dtbl.nc` files.\n\n5.3.1 Spatially distributed parameter files\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nAs of version 5.0 of WRF-Hydro we now allow for the specification of a\nnumber of spatially distributed land surface model and / or lateral\nrouting parameters in netCDF input files :file:`soil_properties.nc` and\n:file:`hydro2dtbl.nc`. This option was implemented as part of work conducted\nfor the National Water Model and allows the user to specify parameters on\nthe model grid rather than as a single value or function of soil or land\ncover type. The files can be generated via an R script provided on our\nwebsite (:file:`create_SoilProperties.R`) and are described in more detail in\nAppendices :ref:`A9 ` and :ref:`A10 `. In order for the\nmodel to read in the :file:`soil_properties.nc` file the ``SPATIAL_SOIL`` environment\nvariable must be set to 1 at compile time. This option gives users more\nflexibility in the specification of land surface model parameters and is\nparticularly useful in the context of calibration and parameter\nregionalization.\n\n.. _section-5.4:\n\n5.4 Description of channel routing parameter files\n--------------------------------------------------\n\nChannel parameters for WRF-Hydro are specified in one of two files. If\nthe model is configured using gridded channel routing these parameters\nwill be stored in :file:`CHANPARM.TBL`. If the model is configured using reach-based\nrouting (including the NWM configuration) the parameters and\nchannel geometry are specified within the :file:`Route_Link.nc` file generated\nby the *WRF-Hydro GIS Pre-processing Toolkit*. Variables of the\n:file:`CHANPARM.TBL` and :file:`Route_Link.nc` files are described in Appendix\n:ref:`A11 `.\n\nIt is important to keep in mind that there is large uncertainty\nassociated with these parameters. Therefore, model calibration is almost\nalways warranted. Also, because fully-distributed estimates of flow\ndepth (``HLINK`` in :file:`CHANPARM.TBL`) are not available for model initialization,\nit is almost always necessary to use a small initial value of ``HLINK`` and let the model\ncome to its own equilibrium (i.e. “spin-up”) after several hours of\nintegration. The necessary time required to spin up the channel network\nis a direct function of how dense and long your channel network is.\nLarger, more dense networks will take substantially longer to spin up.\nEstimates of total travel time from the furthest channel element to the\nbasin outline are a reasonable initial approximation of the time it will\ntake to spin up the channel elements.\n\n.. _section-5.5:\n\n5.5 Description of groundwater input and parameter files\n--------------------------------------------------------\n\nDepending upon the choice of channel configuration, groundwater input and\nparameter files are specified in slightly different ways. For the\nNational Water Model (NWM) implementation of the model - where user\ndefined mapping is active - the :file:`spatialweights.nc` file is used to map\ngridded fluxes to the appropriate catchments, the spatial unit of the\nNWM groundwater bucket model. In other configurations of the model where\nuser defined mapping is not used, grid-based groundwater basins are\ndefined in a :file:`GWBASINS.nc` netCDF file. The contents of these files are\ndescribed in Appendix :ref:`A12 `.\n\nGroundwater bucket model parameters are assigned via the :file:`GWBUCKPARM.nc`\nfile for all configurations. The contents of these files are also\nsummarized in Appendix :ref:`A12 ` and like the\ngroundwater basins files these files are produced by the *WRF-Hydro GIS\nPre-processing Toolkit*. Note that global default parameters are\nprescribed when these files are generated so user adjustments and/or\ncalibration are recommended.\n\n.. _section-5.6:\n\n5.6 Description of lake and reservoir parameter tables\n------------------------------------------------------\n\nLake parameter values are specified for each one of the lake objects.\nTypically, baseline parameters are derived within the high-resolution\nterrain preprocessing stages described above using tools such as ArcGIS\n(e.g. ``LkArea``, ``LkMxE`` in the file :file:`LAKEPARM.nc`).\nValues for the weir and orifice coefficients and\nsizes can be drawn from standard engineering hydraulics textbooks (e.g.\n*Chow et al., 1957*) and calibrated based on lake level performance. Weir\nparameters are specified for reservoir “overflow” or “spill” and orifice\nparameters are specified for design operations. The behavior of the\nreservoir to store and release water is highly dependent on these\nparameters and therefore it is highly recommended that the user modify\nthis file with their own set of parameters beyond the default given in\nthe *WRF-Hydro GIS Pre-processing Toolkit*. See Appendix\n:ref:`A14 ` for descriptions of the variables within the\n:file:`LAKEPARM.nc` file.\n\n.. _section-5.7:\n\n5.7 Specification of meteorological forcing data\n------------------------------------------------\n\nModern land surface hydrology models, including WRF-Hydro, require\nmeteorological forcing data to simulate land-atmosphere exchanges and\nterrestrial hydrologic processes when uncoupled to atmospheric modeling\nsystems. Most land models require a similar set of input variables with\nsome variation in terms of the units, spectral bandwidths of radiation,\nhandling of precipitation phase, etc. Most commonly these variables\ninclude: incoming short and longwave radiation, humidity, temperature,\npressure, wind speed and precipitation rate and type. The required variables for the\nNoah and Noah-MP land surface models supported in version 5.x of\nWRF-Hydro are listed in :ref:`Table 5.4 `. These variables'\nnames, units, and several of the forcing data file format options described\nbelow are borrowed from the High-Resolution Land Data Assimilation System\n(`HRLDAS `__),\nan offline driver for Noah land surface models. When WRF-Hydro is\ncoupled into other modeling architectures such as the NASA Land\nInformation System (LIS), these systems will set the requirements for\nthe forcing data.\n\n.. table:: **Table 5.4** Input forcing data for the Noah and Noah-MP land surface\n models\n :width: 90%\n :align: center\n :name: table-5.4\n\n +-----------------+------------------------------------+---------------+\n | **Variable | **Description** | **Units** |\n | name** | | |\n +=================+====================================+===============+\n | ``SWDOWN`` | Incoming shortwave radiation | `W/m^2` |\n +-----------------+------------------------------------+---------------+\n | ``LWDOWN`` | Incoming longwave radiation | `W/m^2` |\n +-----------------+------------------------------------+---------------+\n | ``Q2D`` | Specific humidity | `kg/kg` |\n +-----------------+------------------------------------+---------------+\n | ``T2D`` | Air temperature | `K` |\n +-----------------+------------------------------------+---------------+\n | ``PSFC`` | Surface pressure | `Pa` |\n +-----------------+------------------------------------+---------------+\n | ``U2D`` | Near surface wind in the | `m/s` |\n | | `u`-component | |\n +-----------------+------------------------------------+---------------+\n | ``V2D`` | Near surface wind in the | `m/s` |\n | | `v`-component | |\n +-----------------+------------------------------------+---------------+\n | ``RAINRATE`` | Precipitation rate | `mm/s` *or* |\n | | | `kg/m^2` |\n +-----------------+------------------------------------+---------------+\n | ``LQFRAC`` | Precipitation type | `unitless` |\n | (optional) | i.e., liquid water fraction (0-1) | |\n +-----------------+------------------------------------+---------------+\n\nHere we simply describe the requirements and options that are available\nin the standalone version of WRF-Hydro. Presently, there are 9 forcing\ndata input types in WRF-Hydro. Because it is untenable to support a\nlarge variety of input file formats and data types within the model,\nWRF-Hydro requires that most processing of forcing data be handled\nexternal to the model (i.e. as a “pre-process”) and that users put their\nforcing data into one of the required formats. This includes performing\ntasks like, gridding of station observations, making sure forcing data\nis gridded to match the domain grid and has the correct variable names\nand units (see :ref:`Table 5.4 `), reformatting data into the\nprescribed netCDF format, etc. Note that The WRF-Hydro code will not\nremap or spatially-subset the forcing data in any way. To facilitate these pre-processing activities\nwe have developed `WRF-Hydro Forcing Engine `_\nand numerous scripts which can be executed to help in the forcing data preparation process.\nThese scripts along with sample data files are distributed on the WRF-Hydro website.\n\nThe input forcing data type is specified in the land surface model\nnamelist file :file:`namelist.hrldas` by modifying the ``FORC_TYP`` namelist\noption. Model forcing type namelist options are specified and described as follows,\nSee Appendices :ref:`A4 ` and :ref:`A5 `\nfor more details.\n\n:\n\n # 1 = HRLDAS-hr format\n # 2 = HRLDAS-min format\n # 3 = WRF output\n # 4 = Idealized\n # 5 = Idealized with specified precipitation\n # 6 = HRLDAS-hr format with specified precipitation\n # 7 = WRF output with specified precipitation\n FORC_TYP = 1\n\n.. rubric:: 1 - HRLDAS hourly format input files:\n\nThis option requires meteorological forcing data to be provided in the HRLDAS\nhourly forcing data format. Scripts provided on the WRF-Hydro website will\ngenerate files in this format. Forcing files in this format can also be found\nin the example cases. In this format, gridded forcing data for all\nmeteorological forcing variables with the names and units shown in :ref:`Table\n5.4 ` are included in a single netCDF file for each time step. The\nforcing data grids must match the model grid specified in the :file:`geo_em.d0{x}.nc`\n“geogrid” file. Filenames must conform to the following convention:\n:file:`YYYYMMDDHH.LDASIN_DOMAIN{X}`\n\n.. rubric:: 2 - HRLDAS minute format input files:\n\nThis option requires meteorological forcing data to be provided in the HRLDAS\nminute forcing data format. Like the HRLDAS hourly format, this standard is\nborrowed from the HRLDAS modeling system. However, this format allows for the\nspecification of forcing data at more frequent time intervals (up to\nevery minute as specified by the forcing time step in the\n:file:`namelist.hrldas` file). In this format, gridded forcing data for all\nmeteorological forcing variables with the names and units shown in :ref:`Table\n5.4 ` are included in a single netCDF file for each time step. The forcing\ndata grids must match the model grid specified in the :file:`geo_em.d0{x}.nc`\nfile. Filenames must conform to the following convention:\n:file:`YYYYMMDDHHmm.LDASIN_DOMAIN{X}`\n\n.. rubric:: 3 - WRF output files as input to WRF-Hydro:\n\nThis option allows for meteorological forcing data to be read directly from a\nWRF model output file “wrfout” file so long as the WRF model grid is the same as\nthat for WRF-Hydro. The WRF-Hydro code will not remap or spatially-subset the\ndata in any way. All necessary fields are available in a default WRF output\nfile but users should verify their existence if modifications have been made.\nThese files must be written with only a single time step per file and retain\nthe default filenames. The file naming convention for the wrfout file is\n:file:`wrfout_d0{x}_YYYY-MM-DD_HH:MM:SS`.\n\n.. rubric:: 4 - Idealized forcing:\n\nThis option requires no input files. Instead a simple rainfall event is\nprescribed (i.e. “hardcoded”) in the model. This event is a spatially uniform\n25.4 `mm/hr` (1 `in/hr`) for 1 hour duration over the first hour of the model\nsimulation. The remainder of the forcing variables are set to have either\nconstant values (in space and time) or, in the case of temperature and\nradiation variables, a fixed diurnal cycle (see :ref:`Table 5.5 `).\nThis option is primarily used for simple testing of the model and is convenient\nfor checking whether or not components besides the forcing data are properly\nbeing read into the model and working. Future versions of WRF-Hydro will allow\nthe user to specify values for the precipitation event and the other meteorological\nvariables. Note that this forcing type requires the user-specified\n``FORCING_TIMESTEP`` namelist parameter to be set to 3600 (1 hr) in the\n:file:`namelist.hrldas` file.\n\n.. table:: **Table 5.5.** Description of idealized forcing\n :align: center\n :width: 90%\n :name: table-5.5\n\n +--------------+--------------------------+------------------------------+\n | **Variable | **Prescribed value or | **Timing** |\n | name** | range of values** | |\n +==============+==========================+==============================+\n | ``SWDOWN`` | 0 - 900 [`W/m^2`] | Diurnal cycle |\n +--------------+--------------------------+------------------------------+\n | ``LWDOWN`` | 375 - 425 | Diurnal cycle |\n | | [`W/m^2`] | |\n +--------------+--------------------------+------------------------------+\n | ``Q2D`` | 0.01 [`kg/kg`] | Constant |\n +--------------+--------------------------+------------------------------+\n | ``T2D`` | 287 - 293 [`K`] | Diurnal cycle |\n +--------------+--------------------------+------------------------------+\n | ``PSFC`` | 100,000 [`Pa`] | Constant |\n +--------------+--------------------------+------------------------------+\n | ``U2D`` | 1.0 [`m/s`] | Constant |\n +--------------+--------------------------+------------------------------+\n | ``V2D`` | 1.0 [`m/s`] | Constant |\n +--------------+--------------------------+------------------------------+\n | ``RAINRATE`` | 25.4 [`mm/s` or | For first hourly time step |\n | | `kg/m^2`] | and zero thereafter |\n +--------------+--------------------------+------------------------------+\n\n.. rubric:: 5 - Idealized forcing with specified precipitation:\n\nThis option is identical to forcing type 4 with the exception that the\nWRF-Hydro system will look for user provided supplementary precipitation\nfiles. These supplementary precipitation files are netCDF files containing a\nsingle gridded field with either the name ``precip`` and units of `mm` or\n``precip_rate`` with unit a unit of `mm/s`. When using this forcing type,\nthe WRF-Hydro system will look for a new precipitation input file based\non the user-specified ``FORCING_TIMESTEP`` namelist option set in the\n:file:`namelist.hrldas` file. Scripts provided on the WRF-Hydro website will\ngenerate files in this format (specifically the MRMS regridding\nscripts). Forcing files in this format can also be found in the example\ntest cases. Filenames for supplemental precipitation files must conform\nto this convention: :file:`{YYYYMMDDHHMM}.PRECIP_FORCING.nc`.\n\n.. rubric:: 6 - HRLDAS hourly format input files with specified\n precipitation:\n\nThis option is identical to forcing type 1 with the exception that the\nWRF-Hydro system will also look for user provided supplementary precipitation\nfiles. These supplementary precipitation files are netCDF files containing a\nsingle gridded field with either the name ``precip`` and units of `mm` or\n``precip_rate`` with unit a unit of `mm/s`. When using this forcing type, the\nWRF-Hydro system will look for a new precipitation input file based on the\nuser-specified ``FORCING_TIMESTEP`` namelist option set in the\n:file:`namelist.hrldas` file. Scripts provided on the WRF-Hydro website will\ngenerate files in this format (specifically the MRMS regridding scripts).\nForcing files in this format can also be found in the example test cases.\nFilenames for supplemental precipitation files must conform to this\nconvention: :file:`{YYYYMMDDHHMM}.PRECIP_FORCING.nc`.\n\nThis option is useful when combining atmospheric analyses from\nreanalysis products or other models with a separate analysis of\nprecipitation (e.g. a gridded gauge product, radar QPE, nowcasts,\nsatellite QPE, etc). The model reads in the meteorological forcing data\nfields on each hour and then holds those values constant for the entire\nhour. Precipitation can be read in more frequently based on the\nuser-specified ``FORCING_TIMESTEP`` namelist parameter in the\n:file:`namelist.hrldas` file. For example, the user can have 'hourly'\nmeteorology with '5-minute' precipitation analyses.\n\n.. rubric:: 7 - WRF output files as input to WRF-Hydro with specified\n precipitation:\n\nThis option is identical to forcing type 3 with the exception that the\nWRF-Hydro system will also look for user provided supplementary precipitation\nfiles. These supplementary precipitation files are netCDF files containing a\nsingle gridded field with either the name ``precip`` and units of `mm` or\n``precip_rate`` with unit a unit of `mm/s`. When using this forcing type, the\nWRF-Hydro system will look for a new precipitation input file based on the\nuser-specified ``FORCING_TIMESTEP`` namelist option set in the\n:file:`namelist.hrldas` file. Scripts provided on the WRF-Hydro website will\ngenerate files in this format (e.g., MRMS regridding scripts).\nForcing files in this format can also be found in the example test cases.\nFilenames for supplemental precipitation files must conform to this\nconvention: :file:`{YYYYMMDDHHMM}.PRECIP_FORCING.nc`.\n\nThis option is useful when combining forcing data from WRF with a\nseparate analysis of precipitation (e.g. a gridded gauge product, radar\nQPE, nowcasts, satellite QPE, etc). The model reads in the\nmeteorological forcing data fields from the WRF output file and then\nholds those values constant until the next file is available.\nPrecipitation can be read in more frequently based on the user-specified\n``FORCING_TIMESTEP`` namelist parameter in the :file:`namelist.hrldas` file. For\nexample, the user can have 'hourly' meteorology with '5-minute'\nprecipitation analyses.\n" }, { "path": "docs/userguide/model-outputs.rest", "content": ".. vim: syntax=rst\n.. include:: meta.rest\n\n.. _section-6.0:\n\n6. Description of Output Files from WRF-Hydro\n=============================================\n\nThis chapter describes the output files from Version 5.x of WRF-Hydro.\n\nThe user has several options to allow flexibility when outputting from\nthe WRF-Hydro modeling system. All of the options to control outputs are\nlocated in the hydro.namelist file that the user edits prior to running a\nsimulation. Prior to turning specific file options on, there are a few\nhigh-level namelist options (flags) that help control the quantity of\nvariables each file will produce, along with some flexibility on the level\nof compression files contain.\n\n .. rubric:: ``io_form_outputs``:\n\n This flag directs the output to utilize optional internal netCDF compression\n and the use of optional scale_factor/add_offset attributes to pack variables\n from floating point to integer. However, the user also has the flexibility\n to turn these optional features off. For additional information on these\n “packing” attributes, consult the netCDF documentation for a more in-depth\n explanation\n (http://www.unidata.ucar.edu/software/netcdf/docs/index.html). It should\n be noted that the use of internal compression adds time to output files\n being produced. This may become costly for large-scale modeling\n applications. Tests have indicated a cost of 15-25% additional time\n spent producing output variables when internal netCDF compression is\n utilized, depending on the number of output files being produced.\n However, without the use of compression, it is possible file sizes could\n become large depending on the application. It is also important to note\n that a value of ``0`` will result in the code deferring to old output\n routines used in version 3.0 of WRF-Hydro. For these outputs, the user\n is encouraged to read the documentation for that version of the code.\n The following values for the ``io_form_outputs`` option are available:\n\n ``0`` - Defer to old output routines for version 3.0 of WRF-Hydro\n (NOTE:this is the ONLY option that is supported when running with\n the Noah LSM)\n\n ``1`` - Utilize internal netCDF compression in conjunction with\n scale_factor/add_offset byte packing\n\n ``2`` - Utilize scale_factor/add_offset byte packing without internal\n netCDF compression\n\n ``3`` - Utilize internal netCDF compression without\n scale_factor/add_offset byte packing.\n\n ``4`` - No internal netCDF compression and no scale_factor/add_offset\n byte packing.\n\n .. rubric:: ``io_config_outputs``:\n\n This flag offers different sets of output variables for each file. This\n offers the user some flexibility to the number of output variables being\n produced. *NOTE*: This flag has no effect when ``io_form_outputs = 0``.\n\n .. rubric:: ``t0OutputFlag``:\n\n This flag controls if output files are produced on the initial timestep\n of the model simulation. It is important to note that some variables are\n initialized to missing values and may translate to missing values in the\n output files for the initial time step. However, these files may offer\n useful information to the user for diagnosing purposes.\n\n .. rubric:: ``output_channelBucket_influx``:\n\n This flag controls the creation of output variables specific to running\n a channel-only configuration of the model. These variables provide useful\n information on flow coming into channel links located in the simulation\n domain, which can be used for diagnosing purposes. *Note*: this value must\n be zero for running a gridded channel routing configuration of the model.\n\nAn overview of available model output files is shown in :ref:`Figure 6.1 `.\nFor a detailed table of each variable contained within each output file, see :ref:`A17 `.\nThere is no optimal combination of namelist options to use\nfor outputs. Flexibility was given to the user as end applications will\nvary from one user to another. While a combination of many output\nvariables with compression may work for a one-time model simulation,\nhaving fewer variables with less time spent on compression may be more\nsuitable for a user that is operations driven. Future code upgrades will\nallow further flexibility on the exact variables to output for each\nfile.\n\n.. figure:: media/wrfhydro-outputs.png\n :name: figure-6.1\n :figwidth: 90%\n :width: 90%\n :align: center\n\n **Figure 6.1** WRF-Hydro output files organized by model physics\n component. See the Key for files specific to a certain channel\n configuration.\n\nPlease note a proper land spatial metadata file is highly encouraged\nwhen producing land surface output from the simulations. This file is\nspecified by the ``LAND_SPATIAL_META_FLNM`` option in the hydro.namelist\nfile. This file contains several geospatial variables and attributes\nwhich are translated to output files that meet CF compliance\n(http://cfconventions.org/). This file can be created using the\n*WRF-Hydro GIS Pre-processing Toolkit* associated with this release. For\ngridded output files, coordinate variable data and attributes are used\nfrom the spatial metadata file for the output variables. Additionally,\ngeospatial attributes, which can help the user display data in GIS\napplications are located within the metadata file. These attributes\ntranslate to the output files during the output creation process. For\nthe 2D high resolution routing output files (``RT_DOMAIN``, ``CHRTOUT_GRID``),\ngeospatial attributes and coordinate variables are translated from the\nFulldom_hires.nc file if they are detected. For point output files\n(``CHRTOUT_GRID``, ``CHANOBS_DOMAIN``, ``LAKEOUT_DOMAIN``), the geospatial\nattributes and coordinate variables have been hard-coded to be latitude\nand longitude for this version of the code.\n\nEach output file will potentially contain some set of attributes and\nvariables that contain temporal and geospatial information useful to the\nuser. Again, it is worth noting that the lack of a land spatial metadata\nfile, or proper attributes in the :file:`Fulldom_hires.nc` file will result\nin a less comprehensive output file in terms of metadata. Each output file\nwill contain a time dimension and variable that specifies the number of\ntimesteps located in the output file, along with a numeric value for\neach timestep in the form of minutes since EPOCH. A ``reference_time``\ndimension (usually 1 in dimension size) and variable exist. This\nvariable will contain the model initialization in minutes since EPOCH.\n\nGridded output files will contain an `x` and `y` coordinate dimension and\nvariable that will contain the center-point coordinate values for either\nthe routing grid, or land surface grid in the model projected space. For\nexample, on a Lambert Conformal modeling domain, these values would be\nin meters. Gridded output files will also contain a ``CRS`` variable,\nwhich contains useful geospatial metadata attributes about the modeling\ndomain. Output files for points, river channel links, or lakes will\ncontain latitude, longitude, and elevation variables to offer metadata\nabout each location in the output file.\n\nAdditionally, output files at points will contain a feature_id variable\nthat will list either a global ID value associated with that point, or a\npredefined ID value extracted from an input file. For example, with 2D\ngridded channel routing, each channel pixel cell has an ID value that\nranges from `1-n` where `n` is the global number of channel pixel cells.\nHowever, with reach-based routing, each channel reach may have a\npredefined link ID value specified via the :file:`Route_Link.nc` file. All files\ncontain ``model_initialization_time`` and ``model_output_valid_time`` character\nattributes to offer additional time information about the output file.\nFor files that were produced with ``io_form_outputs`` options of ``1`` or ``2``,\nstandard netCDF variable attributes ``scale_factor`` and ``add_offset`` are\npresent to help users and netCDF APIs unpack integer data back to\nfloating point for visualization and analysis. For a more in-depth\ndescription of netCDF CF compliant output, please visit\nhttp://cfconventions.org.\n\nTwo output files that do not necessarily follow the above mentioned\nformat will be the groundwater output (``GWOUT_DOMAIN``) file and\n:file:`frxst_pts_out.txt` text file. Groundwater output are representative of a\nspatial region, as opposed to points or fixed pixel cells. Future code\nupgrades will attempt to incorporate additional spatial information\nabout groundwater buckets. The :file:`frxst_pts_out.txt` text file is a simple\nASCII text file, not netCDF.\n\nThe following output files are available to the user, depending on their\nrun configuration:\n\n 1. Land surface model output\n\n 2. Land surface diagnostic output\n\n 3. Streamflow output at all channel reaches/cells\n\n 4. Streamflow output at forecast points or gage reaches/cells\n\n 5. Streamflow on the 2D high resolution routing grid (gridded channel\n routing only)\n\n 6. Terrain routing variables on the 2D high resolution routing grid\n\n 7. Lake output variables\n\n 8. Ground water output variables\n\n 9. A text file of streamflow output at either forecast points or gage\n locations (:file:`frxst_pts_out.txt`)\n\nThe output files will be described below.\n\nFile naming convention of output files: ``YYYY`` = year, ``MM`` = month,\n``DD`` = day, ``HH`` = hour, ``MM`` = minutes, ``DOMAINX`` = the domain\nnumber that is specified in the hydro.namelist input file (also matches\nthe domain number of the geogrid input file)\n\n.. rubric:: 1. Land surface model output\n\n\\\n :file:`{YYYYMMDDHHMM}.LDASOUT_DOMAIN{X}`\n\n For this output file, land surface model variables are written to a\n multi-dimensional netCDF file. Output is produced on the land surface\n grid, most variables coming directly from the land surface model. The `x`\n and `y` dimensions of the output file match those of the geogrid input\n file and the land spatial metadata file. The ``soil_layers_stag`` and\n ``snow_layers`` dimensions specify the number of soil and snow layers\n being produced by the land surface model. The names and definitions for\n each output variable in the LSM output file are generally consistent\n with those output from standard Noah or Noah-MP LSM coupled to WRF. The\n output frequency of this file is dictated ``OUTPUT_TIMESTEP`` specified in\n :file:`namelist.hrldas`.\n\n.. rubric:: 2. Land surface diagnostic output\n\n\\\n :file:`{YYYYMMDDHHMM}.LSMOUT_DOMAIN{X}`\n\n Variables for this output file will not change with varying values of\n ``io_config_outputs`` as there is a limited set of land surface states\n produced for this output file. In general, the user will not desire this\n output file as the regular land surface output files contain a larger\n amount of land surface output. However, for examining model state and\n flux passing between the LSM and the routing routines, this file could\n contain potentially valuable information that would assist in those\n efforts. Some of these states include soil moisture, soil temperature,\n infiltration excess, and surface head. Like the land surface output\n files, output variables in this output file will match the land surface\n grid. The output frequency of this file is dictated by ``OUTPUT_TIMESTEP``\n specified in :file:`namelist.hrldas`.\n\n.. rubric:: 3. Streamflow output at all channel reaches/cells\n\n\\\n :file:`{YYYYMMDDHHMM}.CHRTOUT_DOMAIN{X}`\n\n The ``CHRTOUT_DOMAIN`` option in the :file:`hydro.namelist` is used to\n activate this output. This output file will produce a set of streamflow\n (and related) variables for each channel location in the modeling domain.\n For 2D gridded routing on the channel network, this is every pixel cell\n on the high-resolution modeling domain classified as a channel pixel cell.\n Forreach-based routing, this is every channel reach defined in the\n :file:`Route_Link.nc` file. If the user desires to limit the number of\n streamflow points, the ``order_to_write`` option in :file:`hydro.namelist`\n will reduce the number of points based on the Strahler order number.\n Otherwise, all points will be outputted to the file. Each file will\n contain a ``latitude``, ``longitude``, ``elevation``, and ``order`` variable\n to describe basic information on each channel point. The ``CRS`` projection\n variable has been hard-coded (as it is with all other point output\n files) as the coordinate variables for point files are in\n latitude/longitude.\n\n.. rubric:: 4. Streamflow output at forecast points or gage reaches/cells\n\n\\\n :file:`{YYYYMMDDHHMM}.CHANOBS_DOMAIN{X}`\n\n The ``CHANOBS_DOMAIN`` option in the hydro.namelist is used to activate this\n output. This output file is very similar to the regular streamflow\n output file format. The key difference is output only occurs at\n predefined forecast points or gage locations. For 2D gridded channel\n routing, the user defines forecast points during the setup of their\n modeling domain. Under this configuration, streamflow will be produced\n at those points. It is worth noting output points can be constrained by\n the ``order_to_write`` as they are in the regular streamflow output files.\n For reach-based routing, it is possible to create outputs at a set of\n predefined gage points in the :file:`Route_Link.nc` file. Within the\n :file:`Route_Link.nc` file, a variable called ``gages`` of type character will\n need to be created by the user containing a string for each channel\n reach that contains a gage. This variable is of length ``feature_id`` (see\n description of the Route_Link.nc file in Appendix :ref:`A9 `),\n and size 15. If a channel reach does not contain a gage, the string\n stays empty. For example, ``\" \"`` would represent a channel\n reach with no gage, and ``\" 07124000\"`` would contain a gage labeled\n “07124000”. It is up to the user to create this variable and populate it with\n character strings if there is a desire to connect gage locations to channel\n reaches. If no locations are found, the output code will simply bypass\n creating this output file. Like the other point files, similar\n geospatial information will be placed into the output files.\n\n.. rubric:: 5. Streamflow on the 2D high resolution routing grid\n\n\\\n :file:`{YYYYMMDDHHMM}.CHRTOUT_GRID{X}`\n\n The ``CHRTOUT_GRID`` option in the :file:`hydro.namelist` is used to activate this\n output. This output file is a 2D file created from streamflow with 2D gridded\n channel routing. Currently, this file is not available for reach-based\n routing as channel routing does not occur on the channel grid. Output\n occurs on the high resolution channel routing grid, which means file\n sizes may be large depending on the size of your domain. In addition to\n geospatial metadata and coordinate variables, an ``index`` variable is\n created on the 2D grid producing a global index value for each channel\n pixel cell on the grid. The main motivation behind creating this file is\n for easy spatial visualization of the streamflow occurring across the\n modeling domain.\n\n.. rubric:: 6. Terrain routing variables on the 2D high resolution routing grid\n\n\\\n :file:`{YYYYMMDDHHMM}.RTOUT_DOMAIN{X}`\n\n The ``RTOUT_DOMAIN`` option in the :file:`hydro.namelist` is used to activate this\n output. This output file is a 2D file created on the high resolution routing\n grid. The primary variables created for this file are overland and\n subsurface routing components that may be of interest to the user. The\n format is very similar to the 2D streamflow file. Due to the shear size\n of these data layers, care should be used in deciding when to output\n high-resolution terrain data.\n\n.. rubric:: 7. Lake output variables\n\n\\\n :file:`{YYYYMMDDHHMM}.LAKEOUT_DOMAIN{X}`\n\n The ``outlake`` option in the :file:`hydro.namelist` will activate this output.\n This file is a point output file containing lake/reservoir inflow,\n outflow and elevation values for each lake/reservoir object created in\n the modeling domain. The format follows that of the other point output\n files in terms of geospatial metadata. If no lake/reservoir objects were\n created in the modeling domain, no output will be created.\n\n.. rubric:: 8. Ground water output variables\n\n\\\n :file:`{YYYYMMDDHHMM}.GWOUT_DOMAIN{X}`\n\n The ``output_gw`` option in the :file:`hydro.namelist` will activate this output.\n When groundwater buckets are activated in the model simulations, it is\n possible to output bucket inflow/outflow/depth states via netCDF files.\n One important note to reiterate for these output files is that they will\n not contain the same geospatial metadata as other point files. Each\n element in the output array represents a spatial groundwater bucket that\n covers a region that is neither a single pixel cell or point on the\n modeling domain. For these reasons, this is the only netCDF output file\n that will not contain full geospatial metadata and coordinate variables.\n\n.. rubric:: 9. :file:`frxst_pts_out.txt`\n\n\\\n The ``frxst_pts_out`` option in the :file:`hydro.namelist` will activate this\n output. The forecast points text file is a unique output file that distills\n modeled streamflow and stage down to a simple text file with the\n following columns:\n\n - column 1 : time (in seconds) into simulation\n\n - column 2 : date and time as YYYY-MM-DD_HH:MM:SS\n\n - column 3 : station number index (same as ``feature_id`` in netCDF files)\n\n - column 4 : station longitude (in decimal degrees)\n\n - column 5 : station latitude (in decimal degrees)\n\n - column 6 : streamflow discharge (in cubic meters per second)\n\n - column 7 : streamflow discharge (in cubic feet per second)\n\n - column 8 : flow depth/river stage (in meters above channel bottom)\n\n *Note*: Column 8 is not active for reach-based routing.\n\n Each row in the text file is representative of a predefined forecast\n point (2D gridded channel routing only) or a gage point (reach-based\n routing). It is worth noting that the number of points will be reduced\n (as with CHANOBS and CHRTOUT) if the user specifies a higher\n ``order_to_write`` namelist option.\n\nOnce output files are generated, the user should inspect the files using\nthe :program:`ncdump` netCDF utility for displaying the contents of a netCDF\nfile. With the exception of groundwater output files, the forecast\npoints text file, and any files generated using ``io_form_outputs`` of 0,\nthe user should see some baseline variables and attributes. A ``crs``\nvariable will be present indicating the projection coordinate system for\nthe output files. If these files are missing in the 2D files, it is\npossible the Fulldom_hires.nc or land spatial metadata file does not\ncontain the necessary ``crs`` variable. The same logic can be applied to\nthe ``x`` and ``y`` coordinate variables in the 2D output files. The\nomission of these indicates they were not present in the input files\nprior to running the model. For additional help indicating potential\nissues with the output code, please inspect the standard output from the\nmodel. Specifically, look for any \":output:`WARNING`\" messages that may indicate\nwhy files have not appeared or metadata is missing. For example,\n\":output:`WARNING: Unable to locate the crs variable. No crs variable or \\\nattributes will be created.`\" would indicate the model was unable to locate\nthe ``crs`` variable in one of the input files.\n\n\n.. note::\n **Additional Notes:**\n\n - The output descriptions above may not be fully accurate when running\n with the Noah LSM, which is not actively in development and we\n therefore support only in a deprecated state. New and improved output\n routines (e.g., with CF compliance, scale/offset/compression options,\n augmented metadata) only work with the Noah-MP LSM, while the Noah\n LSM relies on deprecated output routines. See Appendix\n :ref:`A2 ` for more details on running with the Noah LSM.\n\n - For proper QGIS display of the 2D variables, the user will need to\n rename netCDF output files to include a “.nc” at the end as some\n versions of QGIS struggle to properly read in information from a\n netCDF file without this extension. Future upgrades will\n automatically add this file extension into the filenames.\n" }, { "path": "docs/userguide/model-physics.rest", "content": ".. vim: syntax=rst\n.. include:: meta.rest\n\n.. _section-3:\n\n3. Model Physics Description\n============================\n\nThis chapter describes the physics behind each of the modules in Version\n|version_short| of WRF-Hydro and the associated namelist options which are\nspecified at “run time”.\n\n3.1 Physics Overview\n--------------------\n\n.. _figure3.1:\n.. figure:: media/wrf-hydro-components.png\n :align: center\n\n **Figure 3.1.** Conceptual diagram of WRF-Hydro physics components and\n relative outputs.\n\nFirst, the 1-dimensional (1D) column land surface model calculates the\nvertical fluxes of energy (sensible and latent heat, net radiation) and\nmoisture (canopy interception, infiltration, infiltration-excess, deep\npercolation) and soil thermal and moisture states. Infiltration excess,\nponded water depth and soil moisture are subsequently disaggregated from\nthe 1D LSM grid, typically of 1-4 km spatial resolution, to a\nhigh-resolution, typically 30-100 m, routing grid using a time-step\nweighted method *(Gochis and Chen, 2003)* and are passed to the subsurface\nand overland flow terrain-routing modules. In typical U.S. applications,\nland cover classifications for the 1D LSMs are provided by the USGS\n24-type Land Use Land Cover product or MODIS Modified IGBP 20-category\nland cover product (see WRF/WPS documentation); soil classifications are\nprovided by the 1-km STATSGO database *(Miller and White, 1998)*; and soil\nhydraulic parameters that are mapped to the STATSGO soil classes are\nspecified by the soil analysis of *Cosby et al. (1984)*. Other land cover\nand soil type classification datasets can be used with WRF-Hydro but\nusers are responsible for mapping those categories back to the same\ncategories as used in the USGS or MODIS land cover and STATSGO soil type\ndatasets. The WRF model pre-processing system (WPS) also provides a\nfairly comprehensive database of land surface data that can be used to\nset up the Noah and Noah-MP land surface models. It is possible to use\nother land cover and soils datasets, and more recently, data from the USGS\nNational Land Cover Dataset (NLCD) and international soils datasets have\nbeen integrated into WRF-Hydro.\n\nThen, subsurface lateral flow in WRF-Hydro is calculated prior to the\nrouting of overland flow to allow exfiltration from fully saturated grid\ncells to be added to the infiltration excess calculated by the LSM. The\nmethod used to calculate the lateral flux of the saturated portion of\nthe soil column is that of *Wigmosta et al. (1994)* and *Wigmosta and\nLettenmaier (1999)*, implemented in the Distributed Hydrology Soil\nVegetation Model (DHSVM). It calculates a quasi-3D flow, which includes\nthe effects of topography, saturated soil depth, and depth-varying\nsaturated hydraulic conductivity values. Hydraulic gradients are\napproximated as the slope of the water table between adjacent grid cells\nin either the steepest descent or in both `x`- and `y`-directions. The flux\nof water from one cell to its down-gradient neighbor on each time-step\nis approximated as a steady-state solution. The subsurface flux occurs\non the coarse grid of the LSM while overland flow occurs on the fine\ngrid.\n\nNext, WRF-Hydro calculates the water table depth according to the depth\nof the top of the saturated soil layer that is nearest to the surface.\nTypically, a minimum of four soil layers are used in a 2-meter soil\ncolumn used in WRF-Hydro but this is not a strict requirement.\nAdditional discretization permits improved resolution of a time-varying\nwater table height and users may vary the number and thickness of soil\nlayers in the model namelist described in the Appendices :ref:`section-a3`,\n:ref:`section-a4`, and :ref:`section-a5`.\n\nThen, overland flow is defined. The fully unsteady, spatially explicit,\ndiffusive wave formulation of *Julien et al. (1995-CASC2D)* with later\nmodification by *Ogden (1997)* is the current option for representing\noverland flow, which is calculated when the depth of water on a model\ngrid cell exceeds a specified retention depth. The diffusive wave\nequation accounts for backwater effects and allows for flow on adverse\nslopes *(Ogden, 1997)*. As in *Julien et al. (1995)*, the continuity\nequation for an overland flood wave is combined with the diffusive wave\nformulation of the momentum equation. Manning's equation is used as the\nresistance formulation for momentum and requires specification of an\noverland flow roughness parameter. Values of the overland flow roughness\ncoefficient used in WRF-Hydro were obtained from *Vieux (2001)* and were\nmapped to the existing land cover classifications provided by the USGS\n24-type land-cover product of *Loveland et al. (1995)* and the MODIS\n20-type land cover product, which are the same land cover classification\ndatasets used in the 1D Noah/Noah-MP LSMs.\n\nAdditional modules have also been implemented to represent stream\nchannel flow processes, lakes and reservoirs, and stream baseflow. In\nWRF-Hydro v\\ |version_short| inflow into the stream network and lake and\nreservoir objects is a one-way process. Overland flow reaching grid cells\nidentified as 'channel' grid cells pass a portion of the surface water\nin excess of the local ponded water retention depth to the channel\nmodel. This current formulation implies that stream and lake inflow from\nthe land surface is always positive to the stream or lake element. There\nis an optional channel loss formulation *(Lahmers et al. 2019)* where water\ncan seep from the channel; note that this water becomes a sink term and is\nnot returned to the soil or baseflow. Currently there are no channel or\nlake loss functions where water can move\nfrom channels or lakes back to the landscape. Channel flow in WRF-Hydro\nis represented by one of a few different user-selected methodologies\ndescribed below. Water passing into and through lakes and reservoirs is\nrouted using a simple level pool routing scheme. Baseflow to the stream\nnetwork is represented using a conceptual catchment storage-discharge\nbucket model formulation (discussed below) which obtains “drainage” flow\nfrom the spatially-distributed landscape. Discharge from buckets is\ninput directly into the stream using an empirically-derived\nstorage-discharge relationship. If overland flow is active, the only\nwater flowing into the buckets comes from soil drainage. This is because\nthe overland flow scheme will pass water directly to the channel model.\nIf overland flow is switched off and channel routing is still active,\nthen surface infiltration excess water from the land model is collected\nover the pre-defined catchment and passed into the bucket as well. Each\nof these process options are enabled through the specification of\noptions in the model namelist file.\n\n3.2 Land model description: The community Noah and Noah-MP land surface models\n-------------------------------------------------------------------------------\n\n.. note::\n As of this writing, only the Noah and Noah-MP land surface\n models are supported within WRF-Hydro. CLM coupling is currently\n out-of-date and is not formally supported but is in the process of\n being updated. The NASA Land Information System (LIS) has been coupled\n with WRF-Hydro through the NUOPC framework and is supported under\n the `NASA Land Coupler `_.\n\n3.2.1 Noah Land Surface Model (deprecated support only)\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThe Noah land surface model is a community, 1-dimensional land surface\nmodel that simulates soil moisture (both liquid and frozen), soil\ntemperature, skin temperature, snowpack depth, snowpack water\nequivalent, canopy water content and the energy flux and water flux\nterms at the Earth's surface *(Mitchell et al., 2002; Ek et al., 2003)*.\nThe model has a long heritage, with legacy versions extensively tested\nand validated, most notably within the Project for Intercomparison of\nLand surface Parameterizations (PILPS), the Global Soil Wetness Project\n*(Dirmeyer et al. 1999)*, and the Distributed Model Intercomparison\nProject *(Smith, 2002)*. *Mahrt and Pan (1984)* and *Pan and Mahrt (1987)*\ndeveloped the earliest predecessor to Noah at Oregon State University\n(OSU) during the mid-1980's. The original OSU model calculated sensible\nand latent heat flux using a two-layer soil model and a simplified plant\ncanopy model. Development and implementation of the Noah land model\nhas been sustained through the community participation\nof various agency modeling groups and the university community (e.g.\n*Chen et al., 2005*). *Ek et al. (2003)* detail the numerous changes that\nhave evolved since its inception including, a four layer soil\nrepresentation (with soil layer thicknesses of 0.1, 0.3, 0.6 and 1.0 m),\nmodifications to the canopy conductance formulation *(Chen et al., 1996)*,\nbare soil evaporation and vegetation phenology *(Betts et al., 1997)*,\nsurface runoff and infiltration *(Schaake et al., 1996)*, thermal\nroughness length treatment in the surface layer exchange coefficients\n*(Chen et al., 1997a)* and frozen soil processes *(Koren et al., 1999)*.\nMore recently refinements to the snow-surface energy budget calculation\n*(Ek et al., 2003)* and seasonal variability of the surface emissivity\n*(Tewari et al., 2005)* have been implemented.\n\nThe Noah land surface model has been tested extensively in both offline\n(e.g., *Chen et al., 1996, 1997*; *Chen and Mitchell, 1999*; *Wood et al.,\n1998*; *Bowling et al., 2003*) and coupled (e.g. *Chen et el., 1997*, *Chen\nand Dudhia, 2001*, *Yucel et al., 1998*; *Angevine and Mitchell, 2001*; and\n*Marshall et al., 2002*) modes. The most recent version of Noah is\ncurrently one of the operational LSM's participating in the interagency\nNASA-NCEP real-time Land Data Assimilation System (LDAS, 2003, *Mitchell\net al., 2004* for details). Gridded versions of the Noah model are\ncurrently coupled to real-time weather forecasting models such as the\nNational Center for Environmental Prediction (NCEP) North American Model\n(NAM), and the community WRF model. Users are referred to *Ek et al.\n(2003)* and earlier works for more detailed descriptions of the\n1-dimensional land surface model physics of the Noah LSM.\n\n.. note::\n Support for the Noah Land Surface Model within WRF-Hydro is currently\n frozen at Noah version 3.6. Since the Noah LSM is not under active\n development by the community, WRF-Hydro is continuing to support Noah in\n deprecated mode only. Some new model features, such as the improved\n output routines, have not been setup to be backward compatible with Noah.\n Noah users should follow the guidelines in Appendix :ref:`A2 `\n for adapting the WRF-Hydro workflow to work with Noah.\n\n3.2.2 Noah-MP Land Surface Model (recommended)\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nNoah-MP is a land surface model (LSM) using multiple options for key\nland-atmosphere interaction processes (*Niu et al., 2011*). Noah-MP was\ndeveloped to improve upon some of the limitations of the Noah LSM (*Koren\net al., 1999; Ek et al., 2003*). Specifically, Noah-MP contains a\nseparate vegetation canopy defined by a canopy top and bottom, crown\nradius, and leaves with prescribed dimensions, orientation, density, and\nradiometric properties. The canopy employs a two-stream radiation\ntransfer approach along with shading effects necessary to achieve proper\nsurface energy and water transfer processes including under-canopy snow\nprocesses (*Dickinson, 1983; Niu and Yang, 2004*). Noah-MP contains a\nmulti-layer snow pack with liquid water storage and melt/refreeze\ncapability and a snow-interception model describing loading/unloading,\nmelt/refreeze capability, and sublimation of canopy-intercepted snow\n(*Yang and Niu 2003; Niu and Yang 2004*). Multiple options are available\nfor surface water infiltration and runoff and groundwater transfer and\nstorage including water table depth to an unconfined aquifer (*Niu et\nal., 2007*) as well as options for different snow processes such as snow\nalbedo.\n\nThe Noah-MP land surface model can be executed by prescribing both the\nhorizontal and vertical density of vegetation using either ground- or\nsatellite-based observations. Another available option is for prognostic\nvegetation growth that combines a Ball-Berry photosynthesis-based\nstomatal resistance (*Ball et al., 1987*) with a dynamic vegetation model\n(*Dickinson et al. 1998*) that allocates carbon to various parts of\nvegetation (leaf, stem, wood and root) and soil carbon pools (fast and\nslow). The model is capable of distinguishing between `C_3` and\n`C_4` photosynthesis pathways and defines vegetation-specific\nparameters for plant photosynthesis and respiration.\n\nIn addition to the three-layer snow model in NoahMP, WRF-Hydro also supports\noptionally running the Crocus snowpack model within NoahMP for glacial\nrepresentation. For details on using this option, please see\n:ref:`Appendix 16 `.\n\nThe Noah-MP version in WRF-Hydro also includes an option for adjusting\ninfiltration vs. surface runoff partitioning as a function of impervious\nsurface cover. The default Noah-MP behavior is to set a very narrow range\nof soil water holding capacity for cells classified as urban. This has the\neffect of generating more runoff, but also results in very wet cells\nthat may or may not be appropriate for your application. The new physics setting\n(``IMPERV_OPTION`` in :file:`namelist.hrldas`) includes 4 options:\n\n- Option 0 (no adjustment): Urban cells will be treated the same as all other\n cells and will use the provided soil and surface parameters to calculate partitoning\n between infiltration and surface runoff.\n\n- Option 1 (total): If spatially distributed parameters are active (``SPATIAL_SOIL=1`` on\n code compile), the model will expect an impervious fraction grid (``imperv``) to be\n included in the soil_properties.nc file. The model will use this fractional value\n to automatically partition that fraction (``imperv``) of effective precipitation\n reaching the surface to direct surface runoff. The rest (1-``imperv``) will be available\n for infiltration. If spatially distributed parameters are not active (``SPATIAL_SOIL=0``\n on code compile), the model will use the ``IMPERV_URBAN`` value from :file:`MPTABLE.TBL` for\n impervious fraction for all urban cells.\n\n- Option 2 (Alley&Veenhuis): Similar to Option 1, with the modification that the\n provided impervious fraction will be adjusted to account for local capture of some\n runoff to adjacent green spaces. This adjustment uses an empirical formulation\n derived in Alley & Veenhuis (1983, https://doi.org/10.1061/(ASCE)0733-9429(1983)109:2(313) ).\n In the future we plan to test options that derive an adjustment factor based on\n impervious connectivity or other local (sub-grid) conditions.\n\n- Option 9 (original formulation): This reverts back to the original Noah-MP configuration\n where soil water holding capacity is adjusted for urban cells and impervious fraction is not used.\n\n\n.. note::\n The Noah-MP code within WRF-Hydro has some additional features that were added\n specifically for WRF-Hydro hydrologic applications, such as spatially distributed\n parameters and impervious surface runoff treatment, so it does not exactly track\n the Noah-MP standalone code releases. Standalone Noah-MP model code was recently\n modernized for modularity and accessibility (*He et al. 2023*). Support for this\n refactored version of the Noah-MP model is currently in development and will be\n included in a future WRF-Hydro release.\n\n3.3 Spatial Transformations\n---------------------------\n\nThe WRF-Hydro system has the ability to execute a number of physical\nprocess executions (e.g. column physics, routing processes, reservoir\nfluxes) on different spatial frameworks (e.g. regular grids, catchments,\nriver channel vectors, reservoir polygons, etc). This means that spatial\ntransformations between differing spatial elements has become a critical\npart of the overall modeling process. Starting in v5.0 of WRF-Hydro,\nincreased support has been developed to aid in the mapping between\ndiffering spatial frameworks. Section 3.3.1 describes the spatial\ntransformation process which relies on regular, rectilinear grid-to-grid\nmapping using a simplified integer linear multiple\naggregation/disaggregation scheme. This basic scheme has been utilized\nin WRF-Hydro since its creation as it was described in *Gochis and Chen, 2003*.\n\nSection 3.3.2 describes new spatial transformation methods that have been\ndeveloped and are currently supported in v5.0 and beyond and, more\nspecifically, in the NOAA National Water Model (NWM). Those user-defined\ntransformations rely on the pre-processing development and specification\nof interpolation or mapping weights which must be read into the model.\nAs development continues future versions will provide more options and\nflexibility for spatial transformations using similar user-defined methodologies.\n\n.. _section-5:\n\n3.3.1 Subgrid disaggregation-aggregation\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThis section details the implementation of a subgrid\naggregation/disaggregation scheme in WRF-Hydro. The\ndisaggregation-aggregation routines are activated when routing of either\noverland flow or subsurface flow is active and the specified routing\ngrid increment is different from that of the land surface model grid.\nRouting in WRF-Hydro is “switch-activated” through the declaration of\nparameter options in the primary model namelist file hydro.namelist\nwhich are described in Appendix :ref:`section-a5`\n\nIn WRF-Hydro subgrid aggregation/disaggregation is used to represent\noverland and subsurface flow processes on grid scales much finer than\nthe native land surface model grid. Hence, only routing is represented\nwithin a subgrid framework. It is possible to run both the land surface\nmodel and the routing model components on the same grid. This\neffectively means that the aggregation factor between the grids has a\nvalue of 1.0. This following section describes the\naggregation/disaggregation methodology in the context of a “subgrid”\nrouting implementation.\n\nIn WRF-Hydro the routing portions of the code have been structured so\nthat it is simple to perform both surface and subsurface routing\ncalculations on grid cells that potentially differ from the native land\nsurface model grid sizes provided that each land surface model grid cell\nis divided into integer portions for routing. Hence routing calculations\ncan be performed on comparatively high-resolution land surfaces (e.g., a\n25 `m` digital elevation model) while the native land surface model can be\nrun at much larger (e.g., 1 `km`) grid sizes. (In this example, the\ninteger multiple of disaggregation in this example would be equal to\n40.) This capability adds considerable flexibility in the implementation\nof WRF-Hydro. However, it is well recognized that surface hydrological\nresponses exhibit strongly scale-dependent behavior such that\nsimulations at different scales, run with the same model forcing, may\nyield quite different results.\n\nThe aggregation/disaggregation routines are currently activated by\nspecifying either the overland flow or subsurface flow routing options\nin the model namelist file and prescribing terrain grid domain file\ndimensions (``IXRT``, ``JXRT``) which differ from the land surface model domain\nfile dimensions (``IX``, ``JX``). Additionally, the model sub-grid size (``DXRT``),\nthe routing time-step (``DTRT``), and the integer divisor (``AGGFACTRT``), which\ndetermines how the aggregation/disaggregation routines will divide up a\nnative model grid square, all need to be specified in the model\n`hydro.namelist` file.\n\nIf ``IXRT=IX``, ``JXRT=JX`` and ``AGGFACTRT=1`` the aggregation/disaggregation\nschemes will be activated but will not yield any effective changes in\nthe model resolution between the land surface model grid and the terrain\nrouting grid. Specifying different values for ``IXRT``, ``JXRT`` and ``AGGFACTRT≠1``\nwill yield effective changes in model resolution between the land model\nand terrain routing grids. As described in the Surface Overland Flow\nRouting section `3.5 <#surface-overland-flow-routing>`__, ``DXRT`` and ``DTRT``\nmust always be specified in accordance with the routing grid even if\nthey are the same as the native land surface model grid.\n\nThe disaggregation/aggregation routines are implemented in WRF-Hydro as\ntwo separate spatial loops that are executed after the main land surface\nmodel loop. The disaggregation loop is run prior to routing of saturated\nsubsurface and surface water. The main purpose of the disaggregation\nloop is to divide up specific hydrologic state variables from the land\nsurface model grid square into integer portions as specified by\n``AGGFACTRT``. An example disaggregation (where ``AGGFACTRT=4``) is given in\nFigure 3.2.\n\n.. _figure3.2:\n.. figure:: media/aggfactr.png\n :align: center\n :scale: 50%\n\n **Figure 3.2** Example of the routing sub-grid implementation within the\n regular land surface model grid for an aggregation factor = 4.\n\nFour model variables are required to be disaggregated for higher\nresolution routing calculations:\n\n `SMCMAX` - maximum soil moisture content for each soil type\n\n `SMCREF` - reference soil moisture content (field capacity) for each soil\n type\n\n `INFXS` - infiltration excess\n\n `LKSAT` - lateral saturated conductivity for each soil type\n\n `SMC` - soil moisture content for each soil layer\n\nIn the model code, fine-grid values bearing the same name as these with\nan “RT” extension are created for each native land surface model grid\ncell (e.g. ``INFXSRT`` vs ``INFXS``).\n\nTo preserve the structure of the spatial variability of soil moisture\ncontent on the sub-grid from one model time step to the next, simple,\nlinear sub-grid weighting factors are assigned. These values indicate\nthe fraction of the total land surface model grid value that is\npartitioned to each sub-grid pixel. After disaggregation, the routing\nschemes are executed using the fine-grid values.\n\nFollowing execution of the routing schemes the fine-grid values are\naggregated back to the native land surface model grid. The aggregation\nprocedure used is a simple linear average of the fine-grid components.\nFor example the aggregation of surface head (``SFHEAD``) from the fine grid\nto the native land surface model grid would be:\n\n.. rst-class:: center\n\n :math:`{SFHEAD}_{i,j}\\ = \\ \\frac{\\Sigma\\Sigma\\ {SFHEADRT}_{irt,jrt}}{AGGFACTRT^2}`\n (3.0)\n\nwhere, `i_{rt}` and `j_{rt}` are the indices of all of the grid\ncells residing within the native land model grid cell `i`,\\ `j`. The following\nvariables are aggregated and, where applicable, update land surface\nmodel variable values:\n\n | SFHEAD - surface head (or, equivalently, depth of ponded water)\n | SMC - soil moisture content for each soil layer\n\nThese updated values are then used on the next iteration of the land\nsurface model.\n\n3.3.2 User-Defined Mapping\n~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThe emergence of hydrologic models, like WRF-Hydro, that are capable of\nrunning on gridded as well as vector-based processing units requires\ngeneric tools for processing input and output data as well as methods\nfor transferring data between models. Such a spatial transformation is\ncurrently utilized when mapping between model grids and catchments in\nthe WRF-Hydro/National Water Model (NWM) system. In the NWM, selected\nmodel fluxes are mapped from WRF-Hydro model grids onto the NHDPlus\ncatchment polygon and river vector network framework. The GIS\npre-processing framework described here allows for fairly generalized\ngeometric relationships between features to be characterized and for\nparameters to be summarized for any discrete unit of geography.\n\n3.3.3 Data Remapping for Hydrological Applications\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nA common task in hydrologic modeling is to regrid or aggregate data from\none unit of analysis to another. Frequently, atmospheric model data\nvariables such as temperature and precipitation may be produced on a\nrectilinear model grid while the hydrologic unit of analysis may be a\ncatchment Hydrologic Response Unit (cHRU), defined using a closed\npolygon and derived from a hydrography dataset or terrain processing\napplication. Often, cHRU-level parameters must be derived from data on a\ngrid. Depending on the difference between the scale of the gridded and\nfeature data, simple interpolation schemes such as nearest neighbor may\nintroduce significant error when estimating data at the cHRU scale.\nOther GIS analysis methods such as zonal statistics require resampling\nof the gridded and/or feature data and limited control over the common\nanalysis grid resolution, which may also introduce significant error.\nArea-weighted grid statistics provide a robust and potentially\nconservative method for transferring data from one or multiple features\nto another. In the case of runoff calculated from a land surface model\ngrid, the runoff should be conservatively transferred between the grid\nand the cHRU, such that the runoff volume is conserved.\n\nThe correspondence between polygons and grid cells need only be\ngenerated once for any grid/polygon collection. The correspondence file\nthat is output from the tool stores all necessary information for\ntranslating data between the datasets in either direction.\n\nThere are a variety of useful regridding and spatial analysis tools\navailable for use in the hydrologic and atmospheric sciences. Many\nregridding utilities exist that are able to either characterize and\nstore the relationship between grid features and polygons or perform\nregridding from one grid to another. The Earth System Modeling Framework\n(ESMF) offers high performance computing (HPC) software for building and\ncoupling weather, climate, and related models. ESMF provides the\n:program:`ESMF_RegridWeightGen` utility for parallel generation of interpolation\nweights between two grid files in netCDF format. These utilities will\nwork for structured (rectilinear) and unstructured grids. The :program:`ESMF_RegridWeightGen`\ntool since can be accessed through python (through ESMPy) and the NCAR\nCommand Language (NCL, deprecated). Another commonly used tool in the atmospheric sciences\nare the Climate Data Operators (CDO), which offer 1\\ :sup:`st` and 2\\ :sup:`nd`\\-\norder conservative regridding (:program:`remapcon`, :program:`remapcon2`) and regrid weight\ngeneration (:program:`gencon`, :program:`gencon2`) based on the work of *Jones (1999)*. All of\nthe above-mentioned utilities require SCRIP grid description files to\nperform the remapping. The SCRIP standard format for correspondence\nstores geometry information for regridding, while the tools mentioned\nhere store just the spatial weights. Thus, WRF-Hydro spatial\ncorrespondence files are more generic, with compact file sizes, and may\nbe used for non-gridded data.\n\nThe WRF-Hydro geospatial pre-processing toolkit includes a script that\nquantifies the polygon to polygon correspondence between\ngeometries in two separate features (grid cells represented by polygons\nand basins represented by polygons). This correspondence is stored in a\nnetCDF format file that contains the spatial weights and identification\nof all polygons from one input shapefile that intersect each polygon in\nanother input shapefile. The storage of correspondence information\nbetween one dataset and another allows for many types of regridding and\nspatial interpolation between the spatial datasets. This file needs only\nto be derived once between any two sets of polygons, and the\ncorrespondence file can be used to regrid variables between those\nspatial datasets. This is useful if multiple variables must be\nregridded, or a single variable across many timesteps. As long as the\ngrids do not change in space or time, the relationship between all\nfeatures will remain constant, and the correspondence file may be used\nto regrid data between them.\n\nThere are uses for this utility that range outside of the hydrological\nsciences, and this utility may be of broader interest to the geospatial\ncommunity. Although interpolation packages exist, this method allows for\nstorage of the correspondence information for future use in a small-file\nsize. Users wanting to create custom spatial weight interpolation files\nfor WRF-Hydro need to refer to the *WRF-Hydro GIS Pre-processing\nToolkit* and documentation. For reference, variable descriptions of the\ncontents of the spatial weights file is located in :ref:`section-a13`.\n\n.. _figure3.3:\n.. figure:: media/user-defined-mapping.png\n :align: center\n :scale: 90%\n\n **Figure 3.3.** An illustration of implementing user-defined mapping to\n translate from gridded fluxes and states to aggregated catchment fluxes\n and states, which can be passed into, for example, vector-based channel\n routing modules.\n\n3.4 Subsurface Routing\n----------------------\n\nSubsurface lateral flow is calculated prior to the routing of overland\nflow. This is because exfiltration from a supersaturated soil column is\nadded to infiltration excess from the land surface model, which\nultimately updates the value of surface head prior to routing of\noverland flow. A supersaturated soil column is defined as a soil column\nthat possesses a positive subsurface moisture flux which when added to\nthe existing soil water content is in excess of the total soil water\nholding capacity of the entire soil column. Figure 3.4 illustrates the\nlateral flux and exfiltration processes in WRF-Hydro.\n\nIn the current default implementation of WRF-Hydro with the Noah and\nNoah-MP land surface models, there are four soil layers. The depth of\nthe soil layers in WRF-Hydro can be manually specified in the model\nnamelist file under the ``ZSOIL`` variable. Users must be aware that, in\nthe present version of WRF-Hydro, total soil column depth and individual\nsoil layer thicknesses are constant throughout the entire model domain.\nFuture versions under development are relaxing this constraint. However,\nthe model is capable of using a different distribution of soil column\nlayer depths and these simply need to be specified in the model namelist\nfile. Assuming a 2-m soil profile the default soil layer depths (and\nassociated water table depths) are specified in Table 3.1.\n\n.. table:: **Table 3.1: Depths of 4 soil layers in WRF-Hydro**\n :align: center\n\n +-------------+-------------------------+-----------------------------+\n | **Layer** | **Soil Thickness (mm)** | **Z (depth to top of layer) |\n | | | (mm)** |\n +=============+=========================+=============================+\n | 1 | 100 | 0 |\n +-------------+-------------------------+-----------------------------+\n | 2 | 300 | 100 |\n +-------------+-------------------------+-----------------------------+\n | 3 | 600 | 400 |\n +-------------+-------------------------+-----------------------------+\n | 4 | 1000 | 1000 |\n +-------------+-------------------------+-----------------------------+\n\n.. _figure3.4:\n.. figure:: media/subsurface-flow.png\n :align: center\n :scale: 50%\n\n **Figure 3.4** Conceptualization of saturated subsurface flow\n components.\n\nThe method used to calculate the lateral flow of saturated soil moisture\nemploys a quasi three-dimensional flow representation, which include the\neffects of topography, saturated soil depth (in this case layers), and\nsaturated hydraulic conductivity. Hydraulic gradients are approximated\nas the slope of the water table between adjacent grid cells in the x-\nand y-directions or in an eight direction (D8) steepest descent\nmethodology that is specified by the user in the model namelist. In each\ncell, the flux of water from one cell to its down-gradient neighbor on\neach timestep is approximated as a steady-state solution. The looping\nstructure through the model grid performs flux calculations separately\nin the x- and y-directions for the 2-dimensional routing option or\nsimply along the steepest D8 pathway.\n\nUsing Dupuit-Forchheimer assumptions the rate of saturated subsurface\nflow at time `t` can be calculated as:\n\n.. _eqn3.1:\n.. rst-class:: center\n.. math::\n\n {q}_{i,j} &= - T_{i,j}\\beta_{i,j}w_{i,j}\\ when\\ \\beta_{i,j}\\ < \\ 0 \\\\\n &= 0\\ when\\ \\beta_{i,j} > = 0\n\n (3.1)\n\nwhere, `q_{i,j}` is the flow rate from cell `(i,j)`, `T_{i,j}` is the\ntransmissivity of cell `(i,j)`, `\\beta_{i,j}` is the water table slope and\n`w_{i,j}` is the width of the cell which is fixed for a regular grid.\n`\\beta_{i,j}` is calculated as the difference in water table depths between\ntwo adjacent grid cells divided by the grid spacing. The method by which\nthe water table depth is determined is provided below. Transmissivity is\na power law function of saturated hydraulic conductivity (`Ksat_{i,j}`)\nand soil thickness (`D_{i,j}`) given by:\n\n.. _eqn3.2:\n.. rst-class:: center\n.. math::\n\n T_{i,j} &= \\frac{{Ksat}_{i,j}D_{i,j}} {n_{i,j}} \\left( 1 - \\frac{z_{i,j}}{D_{i,j}} \\right)^{n_{i,j}}\\ when\\ z_{i,j} < = D_{i,j} \\\\\n &= 0\\ when\\ z_{i,j} > D_{i,j}\n\n (3.2)\n\nwhere, `z_{i,j}` is the depth to the water table. `n_{i,j}` in :ref:`Eq. (3.2) `\nis defined as the local power law exponent and is a tunable parameter that\ndictates the rate of decay of `Ksat_{i,j}` with depth (`n_{i,j}` has a default value of 1.0\nor can be specified as \"NEXP\" in hydro2dtbl.nc). When :ref:`Eq. (3.2) ` is\nsubstituted into :ref:`Eq. (3.1) ` the flow rate from cell `(i,j)`\nto its neighbor in the `x`-direction can be expressed as:\n\n.. _eqn3.3:\n.. rst-class:: center\n.. math::\n\n q_{x(i,j)} = \\gamma_{x(i,j)} h_{i,j}\\ when\\ \\beta_{x(i,j)} < 0\n\n (3.3)\n\nwhere,\n\n.. _eqn3.4:\n.. rst-class:: center\n.. math::\n\n \\gamma_{x(i,j)} = - \\left( \\frac{w_{i,j}{Ksat}_{i,j}D_{i,j}}{n_{i,j}} \\right)\\beta_{x(i,j)}\n\n (3.4)\n\n.. _eqn3.5:\n.. rst-class:: center\n.. math::\n\n h_{i,j} = \\left( 1-\\frac{z_{i,j}}{D_{i,j}} \\right)\n\n (3.5)\n\nThis calculation is repeated for the y-direction when using the\ntwo-dimensional routing method. The net lateral flow of saturated\nsubsurface moisture (`Q_{net}`) for cell `(i,j)` then becomes:\n\n.. _eqn3.6:\n.. rst-class:: center\n.. math::\n\n Q_{net(i,j)} = h_{i,j} \\sum_x{\\gamma_{x(i,j)}} + h_{i,j} \\sum_y{\\gamma_{y(i,j)}}\n\n (3.6)\n\nThe mass balance for each cell on a model time step (`\\Delta t`) can then be\ncalculated in terms of the change in depth to the water table (`\\Delta z`):\n\n.. _eqn3.7:\n.. rst-class:: center\n.. math::\n\n \\Delta z = \\frac{1}{\\phi_{(i,j)}} \\left[ \\frac{Q_{net(i,j)}}{A} - R_{(i,j)} \\right] \\Delta t\n\n (3.7)\n\nwhere, `\\phi` is the soil porosity, `R` is the soil column recharge rate\nfrom infiltration or deep subsurface injection and *A* is the grid cell\narea. In WRF-Hydro, `R`, is implicitly accounted for during the land\nsurface model integration as infiltration and subsequent soil moisture\nincrease. Assuming there is no deep soil injection of moisture (i.e.\npressure driven flow from below the lowest soil layer), `R`, in\nWRF-Hydro is set equal to 0.\n\nThe methodology outlined in Equations :ref:`3.2 ` thru :ref:`3.7 `\nhas no explicit information on soil layer structure, as the method treats\nthe soil as a single homogeneous column (with an assumed exponential decay of\nsaturated hydraulic conductivity). Therefore, changes in water table\ndepth (`\\Delta z`) need to be remapped to the land surface model soil layers.\nWRF-Hydro specifies the water table depth according to the depth of the\ntop of the highest (i.e. nearest to the surface) saturated layer. The\nresidual saturated water above the uppermost, saturated soil layer is\nthen added to the overall soil water content of the overlying\nunsaturated layer. This computational structure requires accounting\nsteps to be performed prior to calculating `Q_{net}`.\n\nGiven the timescale for groundwater movement and limitations in the\nmodel structure there is significant uncertainty in the time it takes to\nproperly spin-up groundwater systems. The main things to consider\ninclude 1) the specified depth of soil and number and thickness of the\nsoil vertical layers and 2) the prescription of the model bottom\nboundary condition. Typically, for simulations with deep soil profiles\n(e.g. > 10 `m`) the bottom boundary condition is set to a ‘no-flow’\nboundary (``SLOPE_DATA = 0.0`` in the :file:`GENPARM.TBL` parameter file\nor ``slope = 0.0`` in the :file:`soil_properties.nc` spatially distributed\nparameter file). See Appendices :ref:`section-a6` and :ref:`section-a7` for a\ndescription of :file:`GENPARM.TBL` and :file:`soil_properties.nc`.\n\n.. note::\n Currently subsurface routing is only supported in the steepest slope (D8) formulation.\n The 2-dimensional solution will be reactivated in a future release.\n\n.. rubric:: Relevant code modules:\n\n:file:`Routing/Noah_distr_routing_subsurface.F90`\n\n.. rubric:: Relevant namelist options:\n\n:file:`hydro.namelist`:\n\n- ``SUBRTSWCRT`` - Switch to activate subsurface flow routing.\n\n- ``DXRT`` - Specification of the routing grid cell spacing\n\n- ``AGGFACTR`` - Subgrid aggregation factor, defined as the ratio of the\n subgrid resolution to the native land model resolution\n\n:file:`namelist.hrldas`:\n\n- ``NOAH_TIMESTEP`` - Subsurface routing operates on the LSM timestep\n\n.. rubric:: Relevant domain and parameter files/variables:\n\n- ``TOPOGRAPHY`` in :file:`Fulldom_hires.nc` - Terrain grid or Digital Elevation\n Model (DEM). Note: this grid may be provided at resolutions equal to\n or finer than the native land model resolution.\n\n- ``LKSATFAC`` in :file:`Fulldom_hires.nc` - Multiplier on saturated hydraulic\n conductivity in lateral flow direction.\n\n- ``SATDK``, ``SMCMAX``, ``SMCREF`` in :file:`HYDRO.TBL` or :file:`hydro2dtbl.nc` - Soil properties\n (saturated hydraulic conductivity, porosity, field capacity) used in\n lateral flow routing.\n\n- ``NEXP`` in :file:`hydro2dtbl.nc` - Local power law exponent that\n dictates the rate of decay of saturated hydraulic conductivity with depth.\n\n.. _section-3.5:\n\n3.5 Surface Overland Flow Routing\n---------------------------------\n\nOverland flow in WRF-Hydro is calculated using a fully-unsteady,\nexplicit, finite-difference, diffusive wave formulation similar to that\nof *Julien et al. (1995)* and *Ogden et al. (1997)*. The diffusive wave\nequation, while slightly more complicated, is, under some conditions,\nsuperior to the simpler and more traditionally used kinematic wave\nequation, because it accounts for backwater effects and allows for flow\non adverse slopes. The overland flow routine described below can be\nimplemented in either a 2-dimensional (x and y direction) or 1-dimension\n(steepest descent or “D8”) method. While the 2-dimensional method may\nprovide a more accurate depiction of water movement across some complex\nsurfaces it is more expensive in terms of computational time compared\nwith the 1-dimensional method. While the physics of both methods are\nidentical we have presented the formulation of the flow in equation form\nbelow using the 2-dimensional methodology.\n\n.. figure:: media/overland-flow.png\n :align: center\n :scale: 50%\n\n **Figure 3.5:** Conceptual representation of terrain elements. Flow is\n routed across terrain elements until it intersects a “channel” grid cell\n indicated by the blue line where it becomes “in-flow” to the stream\n channel network.\n\nThe diffusive wave formulation is a simplification of the more general\nSt. Venant equations of continuity and momentum for a shallow water\nwave. The two-dimensional continuity equation for a flood wave flowing\nover the land surface is:\n\n.. _eqn3.8:\n.. rst-class:: center\n.. math::\n\n \\frac{\\partial h}{\\partial t} + \\frac{\\partial q_x}{\\partial x} + \\frac{\\partial q_y}{\\partial x} = i_e\n\n (3.8)\n\nwhere, `h` is the surface flow depth; `q_x` and `q_y` are the unit\ndischarges in the `x`- and `y`-directions, respectively; and `i_e` is the\ninfiltration excess. The momentum equation used in the diffusive wave\nformulation for the `x`-dimension is:\n\n.. _eqn3.9:\n.. rst-class:: center\n.. math::\n\n S_{fx} = S_{ox} - \\frac{\\partial h}{\\partial x}\n\n (3.9)\n\nwhere, `S_fx` is the friction slope (or slope of the energy grade line)\nin the x-direction, `S_ox` is the terrain slope in the `x`-direction and\n`\\partial h/\\partial x` is the change in depth of the water surface above the land\nsurface in the `x`-direction.\n\nIn the 2-dimensional option, flow across the terrain grid is calculated\nfirst in the `x`- then in the `y`-direction. In order to solve :ref:`Eq. 3.8 `\nvalues for `q_x` and `q_y` are required. In most hydrological models\nthey are typically calculated by the use of a resistance equation such\nas Manning's equation or the Chezy equation, which incorporates the\nexpression for momentum losses given in :ref:`Eq. 3.9 `.\nIn WRF-Hydro, a form of Manning's equation is implemented:\n\n.. _eqn3.10:\n.. rst-class:: center\n.. math::\n\n q_x = \\alpha_x h^\\beta\n\n (3.10)\n\nwhere,\n\n.. _eqn3.11:\n.. rst-class:: center\n.. math::\n\n \\alpha_x = \\frac{S_{fx}^{1/2}}{n_{OV}}; \\qquad \\beta = \\frac{5}{3}\n\n (3.11)\n\nwhere, `n_{OV}` is the roughness coefficient of the land surface and is a\ntunable parameter and `\\beta` is a unit-dependent coefficient expressed here\nfor SI units.\n\nThe overland flow formulation has been used effectively at fine terrain\nscales ranging from 30-300 `m`. There has not been rigorous testing to\ndate, in WRF-Hydro, at larger length-scales (> 300 `m`). This is due to\nthe fact that typical overland flood waves possess length scales much\nsmaller than 1 `km`. Micro-topography can also influence the behavior of a\nflood wave. Correspondingly, at larger grid sizes (e.g. > 300 `m`) there\nwill be poor resolution of the flood wave and the small-scale features\nthat affect it. Also, at coarser resolutions, terrain slopes between\ngrid cells are lower due to an effective smoothing of topography as grid\nsize resolution is decreased. Each of these features will degrade the\nperformance of dynamic flood wave models to accurately simulate overland\nflow processes. Hence, it is generally considered that finer resolutions\nyield superior results.\n\nThe selected model time step is directly tied to the grid resolution. In\norder to prevent numerical diffusion of a simulated flood wave (where\nnumerical diffusion is the artificial dissipation and dispersion of a\nflood wave) a proper time step must be selected to match the selected\ngrid size. This match is dependent upon the assumed wave speed or\ncelerity (`c`). The Courant Number, `C_n = c(\\Delta t/\\Delta x)`, should be\nclose to 1.0 in order to prevent numerical diffusion. The value of the\n`C_n` also affects the stability of the routing routine such that\nvalues of `C_n` should always be less than 1.0. Therefore the\nfollowing model time steps are suggested as a function of model grid\nsize as shown in Table 3.2.\n\n.. table::\n **Table 3.2:** Suggested routing time steps for various grid spacings\n :align: center\n :width: 50%\n\n +---------+---------+\n | X (`m`) | T (`s`) |\n +=========+=========+\n | 30 | 2 |\n +---------+---------+\n | 100 | 6 |\n +---------+---------+\n | 250 | 15 |\n +---------+---------+\n | 500 | 30 |\n +---------+---------+\n\n\nWRF-Hydro also includes an impervious surface adjustment option for overland routing. If this\nscheme is activated (``imperv_adj = 0`` in :file:`hydro.namelist`) then the overland roughness\nManning's coefficient and maximum retention depth are adjusted based on the impervious fraction\nprovided as ``IMPERVFRAC`` in :file:`Fulldom_hires.nc`. Specifically, maximum retention depth\nis multiplied by (1 - ``IMPERVFRAC``) (so smaller values for higher imperviousness). Manning's\nroughness for overland routing is scaled based on a linear weighting of smoothness\n(1/roughness, see Liong et al. 1989) and assuming a roughness of 0.02 for impervious and native\ncell roughness for pervious:\n\nOVROUGHRT = 1 / ((1/0.02)*impervfrac + (1/OVROUGHRT)*(1-impervfrac))\n\n\n.. rubric:: Relevant code modules:\n\n:file:`Routing/Noah_distr_routing_overland.F90`\n\n.. rubric:: Relevant namelist options:\n\n`hydro.namelist`:\n\n- ``OVRTSWCRT`` - Switch to activate overland flow routing.\n\n- ``DXRT`` - Specification of the routing grid cell spacing\n\n- ``AGGFACTR`` - Subgrid aggregation factor, defined as the ratio of the\n subgrid resolution to the native land model resolution\n\n- ``DTRT_TER`` - Overland routing grid time step\n\n- ``rt_option`` - Overland flow routing option (steepest descent or 2-dimensional)\n\n.. rubric:: Relevant domain and parameter files/variables:\n\n- ``TOPOGRAPHY`` in :file:`Fulldom_hires.nc` - Terrain grid or Digital Elevation\n Model (DEM). Note: this grid may be provided at resolutions equal to\n or finer than the native land model resolution.\n\n- ``RETDEPRTFAC`` in :file:`Fulldom_hires.nc` - Multiplier on maximum retention\n depth before flow is routed as overland flow.\n\n- ``OVROUGHRTFAC`` in :file:`Fulldom_hires.nc` - Multiplier on Manning's roughness\n for overland flow.\n\n- ``OV_ROUGH`` in :file:`HYDRO.TBL` or ``OV_ROUGH2D`` in\n :file:`hydro2dtbl.nc` - Manning's roughness for overland flow (by\n default a function of land use type).\n\n\n.. _section-3.6:\n\n3.6 Channel Routing\n----------------------------\n\nThere are multiple channel routing algorithms available in version |version_short|\nof WRF-Hydro. These algorithms operate either on the resolution of the\nfine grid (gridded routing) or on a vectorized network of channel\nreaches (linked routing, also referred to as reach-based routing), which\nmaps the fine grid to the vector network (:ref:`Figure 3.6 `).\nThe following section describes the routing methods and their\nimplementation in the WRF-Hydro model code.\n\nIn general, inflow to the channel is based on a mass balance\ncalculation, where the channel routes water when the ponded water depth\n(or surface head, `SFCHEADRT`) of the channel grid cells exceeds a\npredefined retention depth (`RETDEPRT`). As described in `Section\n3.5 <#surface-overland-flow-routing>`__, the depth of surface head on\nany grid cell is a combination of the local infiltration excess, the\namount of water flowing onto the grid cell from overland flow, and\nexfiltration from groundwater flow. The quantity of surface head in\nexcess of the retention depth is accumulated as stream channel inflow\nand is effectively “discharged” to the channel routing routine\n(described below). In the current code, `RETDEPRT` is hard-coded to\n5mm for channel pixels to encourage more local infiltration near the\nriver channel leading to wetter soils that better emulate riparian\nconditions. Values of “channel inflow” are accumulated on the channel\ngrid and can be output for visualization and analysis\n(see :ref:`Section 6 ` for a description of model outputs).\n\n.. _figure3.6:\n.. figure:: media/channel-routing-grid-link.png\n :align: center\n\n **Figure 3.6** Channel routing via the high resolution grid (left) or on\n a vector/link network (right).\n\nThe channel routing module :file:`module_channel_routing.F90` allows for the\none-dimensional, distributed routing of streamflow across the domain. An\noptional, switch-activated, level-pool lake/reservoir algorithm is also\navailable and is described below in Sections :ref:`3.7 `\nand :ref:`3.8 `. Within each channel grid cell there is an\nassumed channel reach of trapezoidal geometry as depicted in Figure 3.7.\nChannel parameters side slope (`z`), bottom width (`B_w`) and roughness (`n`)\nare currently prescribed as functions of Strahler stream order for defaults.\nDetails on how each routing method reads these parameters are specified\nin the subsections below.\n\n.. _figure3.7:\n.. figure:: media/channel-terms.png\n :align: center\n :figwidth: image\n\n **Figure 3.7** Schematic of Channel Routing Terms\n\n.. table::\n :align: center\n\n +---------------------------------+------------------+\n | Channel Slope | `S_o` |\n +---------------------------------+------------------+\n | Channel Length | `\\Delta x` (`m`) |\n +---------------------------------+------------------+\n | Channel side slope | `z` (`m`) |\n +---------------------------------+------------------+\n | Constant bottom width | `B_w` (`m`) |\n +---------------------------------+------------------+\n | Manning's roughness coefficient | (`n`) |\n +---------------------------------+------------------+\n\nAs discussed above, channel elements receive lateral inflow from\noverland flow. There is currently no overbank flow back to the\nfine-grid, so flow into the channel model is effectively one-way.\nTherefore, WRF-Hydro does not explicitly represent inundation areas from\noverbank flow from the channel back to the terrain. This will be an\nupcoming enhancement, though currently there are methods for\npost-processing an inundation surface. Uncertainties in channel geometry\nparameters and the lack of an overbank flow representation result in a\nmeasure of uncertainty for users wishing to compare model flood\ninundation versus those from observations. It is strongly recommended\nthat users compare model versus observed streamflow discharge values and\nuse observed stage-discharge relationships or “rating curves” when\nwishing to relate modeled/predicted streamflow values to actual river\nlevels and potential inundation areas.\n\n.. rubric:: Relevant code modules:\n\n:file:`Routing/module_channel_routing.F90`\n\n.. rubric:: Relevant namelist options for gridded and reach-based routing:\n\n`hydro.namelist`:\n\n- ``CHANRTSWCRT`` - Switch to activate channel routing.\n\n- ``channel_option`` - Specification of the type of channel routing to\n activate\n\n- ``DTRT_CH`` - Channel routing time step, applies to both gridded and\n reach-based channel routing methods\n\n- ``route_link_f`` (optional) - a :file:`Route_Link.nc` file is required for\n reach-based routing methods. Example header in :ref:`Appendix A9 `.\n\n3.6.1. Gridded Routing using Diffusive Wave\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nChannel flow down through the gridded channel network is performed using\nan explicit, one-dimensional, variable time-stepping diffusive wave\nformulation. As mentioned above the diffusive wave formulation is a\nsimplification of the more general St. Venant equations for shallow\nwater wave flow. Similarly, for channel routing, the mass and momentum\ncontinuity equations are given as:\n\n Continuity:\n\n.. math::\n \\frac{\\partial A}{\\partial t} + \\frac{\\partial Q}{\\partial x} = q_{lat}\n \\qquad (3.12)\n\n\\\n Momentum:\n\n.. math::\n \\frac{\\partial Q}{\\partial t} + \\frac{\\partial(\\beta Q^2 / A)}{\\partial x} +\n gA\\frac{\\partial Z}{\\partial x} = -gAS_f\n \\qquad (3.13)\n\nWhere `t` is the time, `x` is the streamwise coordinate, `A` is\nin the flow area of the cross section, and `q_{lat}` is the lateral\ninflow rate into the channel. In the momentum equation, `Q` is the flow\nrate, `\\beta` is a momentum correction coefficient, `Z` is the water surface\nelevation, `g` is gravity and `S_f` is the friction slope which is\ncomputed as:\n\n.. math::\n S_f = \\left( \\frac{Q}{K} \\right)^2\n \\qquad (3.14)\n\nwhere `K` is the conveyance, computed from the Manning's equation:\n\n.. math::\n K = \\frac{C_m}{n} AR^{2/3}\n \\qquad (3.15)\n\nwhere `n` is the Manning's roughness coefficient, `A` is the\ncross-sectional area, `R` is the hydraulic radius (`A/P`), `P` is the\nwetted perimeter, and `C_m` is dimensional constant (1.486 for English\nunits or 1.0 for SI units).\n\nIgnoring the convective term, the second term in the momentum equation\ngives the diffusive wave approximation of open channel flow. The\nmomentum equation then simplifies to:\n\n.. math::\n Q = -SIGN \\left( \\frac{\\partial Z}{\\partial x} \\right) K \\sqrt{\\left| \\frac{\\partial z}{\\partial x}\\right |}\n \\qquad (3.16)\n\nwhere the substitution for friction slope has been made and the `SIGN`\nfunction is `1` for `\\partial Z / \\partial x > 0` and `-1` for `\\partial Z / \\partial x < 0`.\n\nThe numerical solution is obtained by discretizing the continuity\nequation over a raster cell as:\n\n.. math::\n A^{n+1} - A^n = \\frac{\\Delta t}{\\Delta x} \\left( Q^n_{i+\\frac{1}{2}} - Q^n_{i-\\frac{1}{2}} \\right)\n + \\Delta tq^n_{lat}\n \\qquad (3.17)\n\nwhere `Q^n_{i+\\frac{1}{2}}` is the flux across the cell face between point `i` and\n`i+1`, and is computed as:\n\n.. math::\n Q^n_{i+\\frac{1}{2}} = -SIGN\\left(\\Delta Z^n_{i+1}\\right) K_{i+\\frac{1}{2}}\n \\sqrt{\\frac{\\left|\\Delta Z^n_{i+1}\\right|}{\\Delta x}}\n \\qquad (3.18)\n\nwhere:\n\n.. math::\n \\Delta Z^n_{i+1} = Z^n_{i+1} - Z^i &\\qquad (3.19) \\\\\n K^n_{i+\\frac{1}{2}} = \\frac{1}{2} \\left( 1 + SIGN\\left(\\Delta Z^n_{i+1}\\right)\\right) K_i\n + \\left( 1- SIGN\\left( \\Delta Z^n_{i+1} \\right)\\right) K_{i+1} &\\qquad (3.20)\n\nA first-order, Newton-Raphson (N-R) solver is used to integrate the\ndiffusive wave flow equations. Under certain streamflow conditions (e.g.\ntypically low gradient channel reaches) the first-order solver method\ncan produce some instabilities resulting in numerical oscillations in\ncalculated streamflow values. To address this issue, higher order solver\nmethods will be implemented in future versions of WRF-Hydro.\n\nUnlike typical overland flow flood waves which have very shallow flow\ndepths, on the order of millimeters or less, channel flood waves have\nappreciably greater flow depths and wave amplitudes, which can\npotentially result in strong momentum gradients and strong accelerations\nof the propagating wave. To properly characterize the dynamic\npropagation of such highly variable flood waves it is often necessary to\ndecrease model time-steps in order to satisfy Courant conditions.\nTherefore WRF-Hydro utilizes variable time-stepping in the diffusive\nwave channel routing module in order to satisfy Courant constraints and\navoid numerical dispersion and instabilities in the solutions. The\ninitial value of the channel routing time-step is set equal to ``DTRT_CH``\n(which should be estimated based on the grid cell size, as for overland routing).\nIf, during model integration the N-R convergence criteria for\nupstream-downstream streamflow discharge values is not met, the channel\nrouting time-step is decreased by a factor of one-half and the N-R\nsolver is called again.\n\nIt is important to note that the use of variable time-stepping can\naffect model computational performance resulting in slower solution\ntimes for rapidly evolving streamflow conditions such as those occurring\nduring significant flood events. Therefore, selection of the time-step\ndecrease factor (default value set to 0.5) and the N-R convergence\ncriteria can each affect model computational performance.\n\nUncertainty in channel routing parameters can also impact the accuracy\nof the model solution which implies that model calibration is often\nrequired upon implementation in a new domain. Presently, all of the\nchannel routing parameters are prescribed as functions of stream order\nin a channel routing parameter table :file:`CHANPARM.TBL`. The structure of this\nfile is described in detail in Appendix :ref:`A9 `.\nIt should be noted that prescription of channel flow parameters as\nfunctions of stream order is likely to be a valid assumption over\nrelatively small catchments and not over large regions.\n\n.. _section-3.6.2:\n\n3.6.2. Reach Routing using Muskingum and Muskingum-Cunge\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThe gridded catchment and drainage network of the land surface model\n(Noah/Noah-MP LSM) are mapped to the one-dimensional vectorized channel\nnetwork, with a unique set of channel properties defined as constant for\neach reach. The flow out of each channel reach is determined based on\nflow hydraulics, channel storage and the lateral inflow contribution\nfrom each grid cell that is mapped to the individual reach element. Since\nreach lengths are not constant, the number of contributing grid cells to\nthe reach depend on the reach length (:ref:`Figure 3.6 `).\nFlow is assumed always upstream-to-downstream, and channel junctions\naccommodate the merging of flows through the reach network. The simultaneous\ntransformation of the often complex drainage network, source areas, and\nchannel flow hydrographs in these large, complex networks necessitates\na practical and efficient solution to the routing problem (*Brunner and\nGorbrecht, 1991*).\n\nOn the reach network, WRF-Hydro makes use of a fairly standard\nimplementation of the Muskingum-Cunge (MC) method of hydrograph routing\nwhich makes use of time varying parameter estimates. The scheme is a\npractical approach to characterize watershed runoff characteristics over\nlarge network, large watershed flow integration. But as a\none-dimensional explicit scheme, it does not allow for backwater or\nlocalized effects. Channel flows are routed upstream to downstream in a\ncascade routing manner (*Gunner and Gorbetch, 1991*) with the assumption\nthat there are negligible backwater effects. The MC routing scheme\nrelates inflow and outflow using a storage relationship, where:\n\n.. math::\n S = K[XI + (1-X) Q] \\qquad (3.21)\n\nwhere X is a weighting factor with a range of` 0 ≤ X ≤ 0.5`, where `X`\nrange from `0` for reservoir-type storage, while an advancing floodwave\nproduces a wedge of storage and thus a value of `X` greater than `0` (*Chow\net al., 1982*). The finite difference formulation of the storage\nrelationship results in the Muskingum Equation,\n\n.. math::\n Q_{d}^{c} = \\ C1{\\ Q}_{u}^{p}\\ + \\ C2\\ Q_{u}^{c}\\ + \\ {C3Q}_{d}^{p}\\ + \\left( \\frac{\\ q_{l}\\ dt}{D} \\right)\n \\qquad (3.22)\n\nwhere `D = K(1-X)+ dt/2` and is the wedge storage contribution from\nlateral inflow in the reach. The subscript are `u` and `d` are the\nupstream and downstream nodes of each reach, respectively; and the `p`\nand `c` superscript are the previous and current time step,\nrespectively.\n\n.. _figure3.8:\n.. figure:: media/channel-props.svg\n :align: center\n :scale: 150%\n\n **Figure 3.8** Channel Properties\n\nStatic hydraulic properties are used to describe the properties of each\nchannel reach, with each being assumed trapezoidal and include bottom\nwidth (`B_w``), channel length (`dx`), channel top width before bankfull\n(`Tw`), Manning's roughness coefficient (`n`), channel side slope (`z`,\nin meters), and the longitudinal slope of the channel (`So`). If a user\nis running the model with reach-based routing (``channel_option`` =\n``1`` or ``2``), the `B_w` , `n`, and `z` parameters can be modified\nthrough the :file:`Route_Link.nc` file. Note: the :file:`CHANPARM.TBL`\nfile will not be used in this configuration.\n\nSimulated state variables include estimate of mean water depth in the\nchannel (`h`), steady-state velocity (`v`) and flow rate (`q`) in the\nreach at the current timestep. An initial depth estimate is made based\non the depth from the previous time step. Time varying properties\ninclude the hydraulic area, `Area = (B_w*h*z)*h; (3.23)`, the wetted\nperimeter `W_p= (B_w + 2 * \\sqrt{1+z^2}); (3.24)`, and the hydraulic radius,\n`R=Area/W_p; (3.25)`. With an initial estimate of water depth in the channel,\nthe wave celerity for the trapezoidal channel is estimated as:\n\n.. math::\n Ck = \\sqrt{\\frac{So}{n}} \\frac{5}{3}R^{\\frac{2}{3}} -\n \\frac{2}{3}R^{\\frac{5}{3}}*\\left(2*\\sqrt{\\frac{1+z^2}{B_w + 2hz}}\\right)\n \\qquad (3.26)\n\nWave celerity is used to estimate the MC routing parameters, where *K=*\n*dx/c\\ k* (3.27) is the time required for an incremental flood wave to\npropagate through the channel reach, and the storage shape weighting\nfactor is given as, *X* =\n:math:`\\frac{1}{2}\\left( 1 - \\frac{Q}{(Tw{\\ c}_{k}\\ So\\ dx} \\right)` ,\n(3.28) where *Q* is the estimated discharge, *T\\ w* is the water surface\nwidth, *S\\ o* is the channel slope and *dx* is the channel length.\n\n.. rubric:: Relevant domain and parameter files/variables:\n\n- ``TOPOGRAPHY`` in :file:`Fulldom_hires.nc` - Terrain grid or Digital Elevation\n Model (DEM). Note: this grid may be provided at resolutions equal to\n or finer than the native land model resolution.\n\n- ``CHANNELGRID`` in :file:`Fulldom_hires.nc` - Channel network grid identifying\n the location of stream channel grid cells\n\n- ``STREAMORDER`` in :file:`Fulldom_hires.nc` - Strahler stream order grid\n identifying the stream order for all channel pixels within the\n channel network.\n\n- ``FLOWDIRECTION`` in :file:`Fulldom_hires.nc` - Flow direction grid, which\n explicitly defines flow directions along the channel network in\n gridded routing. This variable dictates where water flows into\n channels from the land surface as well as in the channel. This should\n not be modified independently because it is tied to the DEM.\n\n- ``frxst_pts`` (optional) in :file:`Fulldom_hires.nc` - Forecast point grid, which\n specified selected channel pixels for which channel discharge and\n flow depth are to be output within a netcdf point file (CHANOBS)\n and/or an ASCII timeseries file (frxstpts_out.txt).\n\n- :file:`CHANPARM.TBL` text or :file:`Route_Link.nc` netcdf file - Specifies channel\n parameters by stream order (:file:`CHANPARM.TBL`, for gridded channel\n routing) or individual reaches (``route_link_f``, for reach-based routing\n methods)\n\n.. note:: Reach-based routing is highly sensitive to time step.\n\n3.6.3 Compound Channel (limited configuration)\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nIn order to represent a simplification of the behavior of a flood wave\nwhen it exceeds the channel bank, a compound channel formulation was\nadded to WRF-Hydro. This option is currently only available when\n``channel_option=2`` and ``udmp=1`` (so using user-defined mapping with\nthe Muskingum-Cunge reach-based channel routing scheme).\nA visual representation is shown in Figure 3.9. When the depth of the\nflow exceeds bankfull (`d > d_b`), then the wave celerity is given\nas the weighted celerity of the trapezoidal flow and the overbank\nportion of flow. This weighting is based on the cross-sectional area of\neach, and allows water to enter the conceptual compound channel, where\nthe Manning's coefficient of the compound channel portion, `n_{cc}`,\nis assumed rougher than the channel `n` by an unknown factor,\n`n_{cc}`. Based on a set of sensitivity experiments described in\n*Read et al., (2023)*, the default value is\n`n_{cc}=2n`, such that the floodplain roughness is twice that of\nthe channel. The introduction of compound channel requires values for\nthree more parameters: bankfull depth (`d_b`), top widths of the\ntrapezoid and the compound channel, `T_w` and `T_{w\\_cc},`\nrespectively. These parameters, in addition to `n_{cc}`, are defined\nin the Route_Link.nc file. The default values were\ndetermined using a published equation from\n*Blackburn-Lynch et al., 2017*, who gathered regional USGS estimations of\nchannel parameters and developed coefficients to describe the\nrelationship of drainage area (`DA`) to `T_w` and to channel area\n(`A`). The aggregated CONUS equation is: `T_w = 2.44(DA)^{0.34}`\nand `A = 0.75(DA)^{0.53}`. Given these, `d_b` is determined\nusing the standard equation for a trapezoid. As a default value,\n`T_{w\\_cc}` is a multiplier on `T_w`. Sensitivity experiments\npresented in *Read et al. (2023)* found that `T_{w\\_cc}=3*T_w`\nyielded the best streamflow performance, all else being equal.\n\n.. _figure3.9:\n.. figure:: media/trapezoid-compound-channel.png\n :align: center\n :scale: 50%\n\n **Figure 3.9** Cross-sectional schematic of trapezoidal channel and compound\n channel in National Water Model, where the dashed lines represent roughness\n of the channel n, and of the compound channel, `n_{cc}`\n\n.. note:: The compound channel option is currently only available when\n ``channel_option=2`` and ``udmp=1`` (so using user-defined mapping with\n the Muskingum-Cunge reach-based channel routing scheme).\n\n.. _section-3.7:\n\n3.7 Lake and Reservoir Routing Description\n------------------------------------------\n\nA simple mass balance, level-pool lake/reservoir routing module allows\nfor an estimate of the inline impact of small and large reservoirs on\nhydrologic response. A lake/reservoir or series of lakes/reservoirs are\nidentified in the channel routing network, and lake/reservoir storage\nand outflow are estimated using a level-pool routing scheme. The only\nconceptual difference between lakes and reservoirs as represented in\nWRF-Hydro is that reservoirs contain both orifice and weir outlets for\nreservoir discharge while lakes only contain weirs. Note that the user\nmust adjust these parameters accordingly - the model makes no other\ndistinction between a reservoir and a lake.\n\nFluxes into a lake/reservoir object occur through the channel network\nand when surface overland flow intersects a lake object (in the gridded\nchannel routing configuration only). Fluxes from\nlake/reservoir objects are made only through the channel network and no\nfluxes from lake/reservoir objects to the atmosphere or the land surface\nare currently represented (i.e. there is currently no lake evaporation\nor subsurface exchange between the land surface and lakes and\nreservoirs). The Level Pool scheme tracks water elevation changes over\ntime, `h(t)` where water from the reservoir can exit either through weir\noverflow (`Q_w`) and/or a gate-controlled flow (`Q_o`), where\nthese outflows are functions of the water elevation and spillway\nparameters. Weir flow is given as `Q_w(t) = C_wLh^{\\frac{3}{2}}; (3.29)`\nwhen `h>h_{max}` or `Q_w(t) = 0.0` when `h≤h_{max}` where, `h_{max}` is\nthe maximum height before the weir begins to spill (`m`), `C_w` is a weir\ncoefficient, and `L` is the length of the weir (`m`). Orifice flow is\ngiven as `Q_o(t) = C_oO_a\\sqrt{2gh}; (3.30)` where `C_o` is the orifice\ncoefficient, `O_a` is the orifice area (`m^2`), and `g` is the\nacceleration of gravity (`m/s^2`). In addition, the level pool scheme\nis designed to track each reservoir's surface area, `S_a` (`km^2`) as\na function of water depth and the area at full storage, `A_s`\n(`km^2`). Presently, a lake/reservoir object is assumed to have\nvertical side walls, such that the surface area is always constant.\n\n.. _figure-3.10:\n.. figure:: media/level-pool.png\n :align: center\n :scale: 40%\n.. rst-class:: center\n.. math::\n\n S_a(t) &= f(h, A_s) \\\\\n Q_t(t) &= f(h)\n\n.. rst-class:: center\n\n **Figure 3.10** Schematic of Level Pool Routing\n\nThe lake/reservoir parameters listed below are required for level-pool\nrouting and are defined in the :file:`LAKEPARM.nc` parameter file. The GIS\npre-processing tool can make this file and the model will\nread it as specified in the :file:`hydro.namelist` file.\n\n - Weir and Orifice Coefficients, `Cw`, `Co` in equations above or ``WeirC``, ``OrificeC`` in :file:`LAKEPARM.nc`\n - Weir Length (`m`), `L` in equations above or ``WeirL`` in :file:`LAKEPARM.nc`\n - Weir Elevation (`m`), ``WeirE`` in :file:`LAKEPARM.nc`\n - Orifice Area (`m^2`), `O_a` in equations above or ``OrificeA`` in :file:`LAKEPARM.nc`\n - Orifice Elevation (`m`), ``OrificeE`` in :file:`LAKEPARM.nc`\n - Reservoir Area (`km^2`), `A_s` in equations above or ``LkArea`` in :file:`LAKEPARM.nc`\n - Maximum reservoir height at full storage (`m`), `h_{max}` in equations above or ``LkMxE`` in :file:`LAKEPARM.nc`\n - Dam length specified as a multiplier on weir length (`dimensionless`), `Dam_Length` in :file:`LAKEPARM.nc`\n\nFor the gridded channel routing option, the lake/reservoir routing options\nrequire lake objects to be defined and properly indexed as a data\nfield in the high resolution terrain routing :file:`Fulldom_hires.nc`\nfile. If lake/reservoir objects are present in the\nlake grid (and also within the channel network) then level-pool routing through\nthose objects will occur if ``CHANRTSWCRT = 1`` (channel is active), ``channel_option\n= 3`` (gridded routing), and ``lake_option = 1`` (level pool) in :file:`hydro.namelist`.\n\nFor reach-based channel routing options, the lake/reservoir routing options\nrequire lake objects to be defined and properly indexed as waterbody objects\nin the :file:`Route_Link.nc` file.\nIf lake/reservoir objects are present in the\n:file:`Route_Link.nc` file then level-pool routing through\nthose objects will occur if ``CHANRTSWCRT = 1`` (channel is active), ``channel_option\n= 1 or 2`` (reach routing), and ``lake_option = 1`` (level pool) in :file:`hydro.namelist`.\n\nThe ``lake_option`` in :file:`hydro.namelist` can also be used to turn off lake/reservoir\nrouting completely (``lake_option = 0``), set the waterbodies to simply pass water through\nfrom inflow to outflow with no storage or delay (``lake_option = 2``), or activate data\nassimilation (specific to the NOAA National Water Model and not currently\nsupported outside of that configuration).\n\nThere are several special requirements for the\nlake and channel files when lakes/reservoirs are to be\nrepresented and these are discussed in Sections :ref:`5.4 `\nand :ref:`5.6 `.\n\n.. rubric:: Relevant code modules:\n\n:file:`Routing/module_channel_routing.F90`\n\n:file:`Routing/Reservoirs/Level_Pool/module_levelpool.F90`\n\n.. rubric:: Relevant namelist options:\n\n:file:`hydro.namelist`:\n\n- ``lake_option`` - Option to specify lake/reservoir routing behavior\n (0=lakes off, 1=level pool, 2=passthrough, 3=reservoir DA).\n- ``route_lake_f`` - Path to lake parameter file to support\n level-pool reservoir routing methods.\n\n.. note:: As mentioned in the paragraph above, if in the\n GIS-Preprocessing the user created a “gridded” routing stack for\n ``channel_option = 3`` (i.e. did *not* select to create a\n Route_Link.nc file for ``channel_option=1`` or ``=2``) AND specified\n a lake file (user provided a reservoir/lake input file), then\n the :file:`Fulldom_hires.nc` file will populate the ``LAKEGRID`` variable.\n For this case, the user **must** specify the route_lake_f file.\n To turn lakes “off” with ``channel_option=3``, create another set\n of :file:`Fulldom_hires.nc` (“domain”) files without a reservoir input\n file specified.\n\n.. rubric:: Relevant domain and parameter files/variables:\n\n- ``CHANNELGRID`` in :file:`Fulldom_hires.nc` - Channel network grid identifying\n the location of stream channel grid cells\n\n- ``LAKEGRID`` in :file:`Fulldom_hires.nc` (optional) - Specifies lake locations on\n the channel grid (for gridded channel routing methods, i.e.\n ``channel_option=3``).\n\n- :file:`Route_Link.nc` netCDF file (optional) - Specifies lake associations\n with channel reaches.\n\n- :file:`LAKEPARM.nc` netCDF file - Specifies lake parameters for each lake\n object specified.\n\n.. _section-3.8:\n\n3.8 Conceptual base flow model description\n------------------------------------------\n\nAquifer processes contributing baseflow often operate at depths well\nbelow ground surface. As such, there are often conceptual shortcomings\nin current land surface models in their representation of groundwater\nprocesses. Because these processes contribute to streamflow (typically\nas “baseflow”) a parameterization is often used in order to simulate\ntotal streamflow values that are comparable with observed streamflow\nfrom gauging stations. Therefore, a switch-activated baseflow module\n:file:`Routing/module_GW_baseflow.F90` has been created which conceptually\n(i.e. *not* physically-explicit) represents baseflow contributions to\nstreamflow. This model option is particularly useful when WRF-Hydro is\nused for long-term streamflow simulation/prediction and baseflow or\n“low flow” processes must be properly accounted for. Besides potential\ncalibration of the land surface model parameters the conceptual baseflow\nmodel does not directly impact the performance of the land surface model\nscheme. The new baseflow module is linked to WRF-Hydro through the\ndischarge of “deep drainage” from the land surface soil column (sometimes\nreferred to as “underground runoff”).\n\nThe baseflow parameterization in WRF-Hydro uses spatially-aggregated\ndrainage from the soil profile as recharge to a conceptual groundwater\nreservoir (:ref:`Fig. 3.10 `). The unit of spatial\naggregation is often taken to be that of a catchment or sub-basin within\na watershed. Each sub-basin has a groundwater reservoir “bucket” with a\nconceptual depth and associated conceptual volumetric capacity. The\nreservoir operates as a simple bucket where outflow (= “baseflow” or\n“stream inflow”) is estimated using an empirically-derived function of\nrecharge. The functional type and parameters are determined empirically\nfrom offline tests using an estimation of baseflow from stream gauge\nobservations and model-derived estimates of bucket recharge provided by\nWRF-Hydro. Presently, WRF-Hydro uses either a direct output-equals-input\n(\"pass-through\") relationship or an exponential storage-discharge function\nfor estimating the bucket discharge as a function of a conceptual depth\nof water in the bucket (\"exponential bucket\"). Note that, because this is\na highly conceptualized formulation, the depth of water in the bucket in\nno way infers the actual depth of water in a real aquifer system.\nHowever, the volume of water that exists in the bucket needs to be\ntracked in order to maintain mass conservation. Estimated baseflow\ndischarged from the bucket model is then combined with lateral inflow\nfrom overland routing (if active) and input directly into the stream\nnetwork as channel inflow, as referred to above in Section\n:ref:`3.5 `. Presently, the total basin\nbaseflow flux to the stream network is equally distributed among all\nchannel pixels within a basin for gridded channel routing options or\ndumped into the top of the reach to be routed downstream for reach-based\nmethods. Lacking more specific information on regional groundwater\nbasins, the groundwater/baseflow basins in WRF-Hydro are often assumed\nto match those of the surface topography. However, this is not a strict\nrequirement. Buckets can be derived in a number of ways such as where\ntrue aquifers are defined or from a third-party hydrographic\ndataset such as the USGS NHDPlus or Hydrosheds.\n\n.. _figure-3.11:\n.. figure:: media/groundwater.svg\n :align: center\n :width: 70%\n\n **Figure 3.11** Hypothetical map of groundwater/baseflow sub-basins\n within a watershed and conceptualization of baseflow “bucket”\n parameterization in WRF-Hydro.\n\n\\\n | `z = z_{previous} + \\frac{Q_{in}*dt}{A}; \\qquad (3.40)`\n |\n | **if** `z > z_{max}` :\n | `z_{spill} = z - z_{max}`\n | `z = z_{max}`\n | `Q_{spill} = \\frac{A*z_{spill}}{dt}`\n |\n | **else** :\n | `Q_{spill} = 0`\n |\n | `Q_{exp} = C(e^{E\\frac{z}{zmax}}-1)`\n | `Q_{out} = Q_{spill} + Q_{exp}`\n | `z = z - \\frac{Q_{exp}*dt}{A}`\n |\n | **where** :\n | `Q_{in}` is the inflow to the bucket aggregated from the bottom of the LSM in `m^3/s`\n | `z` is the height of the water level in the bucket in `mm`\n | `z_{max}` is the total height of the bucket in `mm`\n | `A` is the area of the catchment or groundwater basin in `m^2`\n | `E` is a unitless parameter\n | `C` is a parameter with units of `m^3/s`\n\nA groundwater/baseflow bucket model parameter file (:file:`GWBUCKPARM.nc`)\nspecifies the empirical parameters governing the behavior of the bucket\nmodel parameterization for each groundwater/baseflow basin specified\nwithin the model domain. These files are created by the WRF-Hydro GIS\nPreprocessing System and documented in :ref:`Appendix 10 `.\nThe parameters include: the bucket model coefficient, the bucket model\nexponent, the initial depth of water in the bucket model, and the maximum\nstorage in the bucket before \"spilling\" occurs.\n\nIt is important to remember that a simple bucket model is a highly\nabstracted and conceptualized representation of groundwater processes\nand therefore the depth of water values in the bucket and the parameters\nthemselves have no real physical basis. As mentioned above, initial\nvalues of the groundwater bucket model parameters are typically derived\nanalytically or \\'offline\\' from WRF-Hydro and then are fine-tuned through\nmodel calibration.\n\nThere are 4 options available for the conceptual baseflow model, as specified\nin ``GWBASESWCRT`` in :file:`hydro.namelist`. The conceptual baseflow model\ncan be turned off (``GWBASESWCRT = 0``), which means water draining from the soil column in the land\nsurface model will become a sink term (this water will not be returned to the channel\nand will be a loss from the system). The exponential bucket model can be activated\n(``GWBASESWCRT = 1``), as described above. Water draining from the land model soil\ncolumn can be placed directly into the channel with no additional storage/attenuation\n(``GWBASESWCRT = 2``). For configurations using user-defined mapping to specify\ncatchment boundaries (``UDMP_OPT = 1``), there is a modified version of the\nexponential bucket model (``GWBASESWCRT = 4``) that adjusts the `C` parameter above\nbased on the area of the catchment.\n\n.. rubric:: Relevant code modules:\n\n:file:`Routing/module_GW_baseflow.F90`\n\n.. rubric:: Relevant namelist options:\n\n:file:`hydro.namelist`:\n\n- ``GWBASESWCRT`` - Switch to activate groundwater bucket module.\n\n- ``GWBUCKPARM_file`` - Path to groundwater bucket parameter file.\n\n- ``gwbasmskfil`` (optional) - Path to netcdf groundwater basin mask file\n if using an explicit groundwater basin 2d grid.\n\n- ``UDMP_OPT`` (optional) - Switch to activate user-defined mapping between\n land surface model grid and conceptual basins.\n\n- ``udmap_file`` (optional) - If user-defined mapping is active, path to\n spatial-weights file.\n\n.. rubric:: Relevant domain and parameter files/variables:\n\n- :file:`GWBUCKPARM.nc` netCDF file - Specifies the parameters for each\n groundwater bucket/basin. More information regarding the groundwater\n bucket model parameters is provided in :ref:`Section 5.5 ` and\n :ref:`Appendix 10 `.\n\n- :file:`GWBASINS.nc` netCDF file - The 2d grid of groundwater basin IDs.\n\n- :file:`spatialweights.nc` - netCDF file specifying the weights to map\n between the land surface grid and the pre-defined groundwater basin\n boundaries.\n" }, { "path": "docs/userguide/nudging.rest", "content": ".. vim: syntax=rst\n.. include:: meta.rest\n\n4. Streamflow Nudging Data Assimilation\n=======================================\n\nThis chapter describes streamflow nudging and data assimilation in\nVersion 5.0 and beyond of WRF-Hydro. Streamflow nudging was introduced\nin v1.1 of the National Water Model (NWM). The community WRF-Hydro model\nsource code and the NWM source code have merged as of Version 5.0 of\nWRF-Hydro. See Appendix :ref:`A14 ` for more\ninformation on the NWM.\n\n4.1 Streamflow Nudging Data Assimilation Overview\n-------------------------------------------------\n\nFor the National Water Model (NWM), a simple nudging data assimilation\n(DA) scheme has been developed to correct modeled stream flows to (or\ntowards) observed values. The capability is only currently supported\nunder the NWM configuration, but could be extended to NCAR reach-based\nrouting, and potentially other kinds of routing, in the future.\nSpecifically, the nudging capability introduces an interface for stream\ndischarge observations to be applied to the Muskingum-Cunge streamflow\nrouting solution.\n\n.. _section-4.2:\n\n4.2 Nudging Formulation\n-----------------------\n\nThere are several motivations for performing DA. For the NWM analysis\nand assimilation cycle, the motivation is to improve model simulation\nand forecast initial conditions. Nudging is a simple and computationally\ninexpensive method of data assimilation where an observed state is\ninserted into the model with some uncertainty. When the observed value\nis inserted into the model without uncertainty, the method is referred\nto as “direct insertion”.\n\nNudging works well locally to observations, both in space and time. Away\nfrom observations, in space and time, the method has limited success.\nFor example, our application applies nudging data assimilation on a\nchannel network with the advantage that the corrections are propagated\ndownstream with the network flow. However, if no spatial or temporal\nsmoothing of the corrections are included with the nudging method,\nupstream errors soon propagate past observed points when in the forecast\n(away from the observations, into the future). Various assumptions can\nbe made to smooth the nudge (or correction) in space and/or time but\nthese are highly parameterized and require tuning. In the NWM we have\navoided spatial smoothing and have opted to pursue a very limited\ntemporal-interpolation approach.\n\nThe basic nudging equation solves `e_j`, the nudge, `e`, on a spatial\nelement `j`,\n\n.. _equation-4.1:\n.. rst-class:: center\n.. math::\n e_{j} = \\frac{\\sum_{n=1}^{N_j} q_{n}*w_{n}^{2}(j,t)*(Q_{n} - {\\widehat{Q}}_{n})}{\\sum_{n=1}^{N_j} w_{n}^{2}(j,t)}\n \\qquad (4.1)\n\nThe numerator is the sum, over the `N_j` observations affecting element\n`j`, of the product of each observations' quality coefficient, `q_n`,\nthe model error, :math:`Q_{n} - {\\widehat{Q}}_{n}`, and the squared\nweights. The weights is where most of the action happens.\n\nThe weights determine how the nudge is interpolated in both space and\ntime (`j,t`). The weights term `w_n(j,t)` in the above equation is\nsolved for observation `n` as a function of both space, `j`, and time,\n`t`. It is expressed as the product of separate spatial and temporal\nweight terms:\n\n.. _equation-4.2:\n.. rst-class:: center\n.. math::\n w_{n}(j,t) = w_{n_{s}}(j)\\ *\\ w_{n_{t}}(t,j)\n \\qquad (4.2)\n\nThe temporal weight term takes the following piecewise form in our\napplication:\n\n.. _equation-4.3:\n.. rst-class:: center\n.. math::\n w_{n_t}(t,j) = \\begin{cases}\n 10^{10} * (1/10)^{\\frac{\\left| t-\\widehat{t} \\right|}{tau_j / 10}} &:\\text{if} \\ \\left| t-\\widehat{t} \\right| \\leq tau_j \\\\\n e^{-a_j*(t-\\widehat{t})} &:\\text{if} \\ \\left| t-\\widehat{t} \\right| \\gt tau_j\n \\end{cases} \\qquad (4.3)\n\nThe spatial weight term is of the following form:\n\n.. _equation-4.4:\n.. rst-class:: center\n.. math::\n w_{n_s} = \\begin{cases}\n \\frac{R_{n}^2 - d_{jn}^{2}}{R_{n}^2 + d_{jn}^2} &: \\text{if} R_n > d_{jn} \\\\\n 0 &: \\text{otherwise}\n \\end{cases} \\qquad (4.4)\n\n\nThe parameters specified in version 1.2 of the NWM (equivalent to this\nWRF-Hydro version 5) are:\n\n.. rst-class:: center\n\n | *tau = 15 minutes*\n | *a = 120 minutes*\n | *R = 0.25 meters*\n\nfor all gages (all `j`) in CONUS (the parameter files are discussed\nbelow). The very short `R` means that nudging is applied locally, only\nto the reach where the observation is associated. There is currently no\nspatial smoothing. This is partly because spatial smoothing is assumed\nto be computationally intensive and has not been completely implemented.\nThe `tau = 15` means that within 15 minutes of an observation we are\nheavily weighting the observation and `a = 120` means that nudging to\nthe observation relaxes with e-folding time of two hours moving away\nfrom the observation.\n\nThe Muskingum-Cunge equation in :ref:`Section 3.6.2 ` has the form:\n\n.. _equation-4.5:\n.. rst-class:: center\n.. math::\n Q_{d}^{c} = C1{\\,Q}_{u}^{p} + C2\\,Q_{u}^{c} + {C3\\,Q}_{d}^{p} + \\left( \\frac{q_{l}\\,dt}{D} \\right)\n \\qquad (4.5)\n\nIn v1.0 of the NWM, nudging was applied into this equation in the\nfollowing manner\n\n.. _equation-4.6:\n.. rst-class:: center\n.. math::\n Q_{d}^{c} = C1{\\,Q}_{u}^{p} + C2\\,Q_{u}^{c} + {C3\\,(Q}_{d}^{p} + N_{d}^{p}) + \\left( \\frac{q_{l}\\,dt}{D} \\right)\n \\qquad (4.6)\n\nwhere the discharge solution (`Q`) at the current time (`c`) at the\ndownstream (`d`) reach was solved by applying the nudge from the\nprevious timestep (`N_{d}^{p}`) to adjust the discharge of\ndownstream reach at the previous (`p`) time. Experiments indicated\nundesirable side effects of introducing a discontinuity (the previous\nnudge) in discharge between the upstream (`u`) link and the downstream\n(`d`) link in this solution. With v1.2 of the NWM (equivalent to v5.0\nWRF-Hydro), the equation was modified to include the nudge in the\nupstream terms of the solution as well, at both the previous and current\ntimes:\n\n.. _equation-4.7:\n.. rst-class:: center\n.. math::\n Q_{d}^{c} = C1{(Q}_{u}^{p} + N_{d}^{p}) + C2{(Q}_{u}^{c} + N_{d}^{p}) + {C3(Q}_{d}^{p} + N_{d}^{p}) + \\left( \\frac{q_{l}\\,dt}{D} \\right)\n \\qquad (4.7)\n\nThis is the form of the equation currently used for nudging which aims\nto reduce the discontinuity in space between the upstream and downstream\nreaches. Experiments revealed that this formulation, significantly\nreduced the difference between modeled and observed discharge and hence\nthe nudging magnitudes (over long time series of assimilated\nobservations). Note that the nudge is only applied to the upstream reach\nduring the solution of the downstream reach and is not applied in the\noutput values of the upstream reach.\n\nThis change in the nudging formulation also promotes the previous\ndownstream nudge to a prognostic variable. Whereas\n`Q_{d}^{p} + N_{d}^{p}` was simply the previous downstream\nstreamflow value after the nudge (already a prognostic model variable),\nadding the previous downstream nudge to the upstream solutions requires\nhaving the previous nudge available. Therefore, the previous downstream\nnudge values gets written to the nudgingLastObs files (described in\n:ref:`Section 4.3 `), which are the restart files for\nthe nudging routine.\n\nThere are a variety of experimental nudging options and features in the\nnudging section of the :file:`hydro.namelist` which are incomplete or unused at\nthis time. There are also nudging features used in a limited capacity by\nthe NWM which are not described here. As development of these options\nevolves, they will be documented in future versions of WRF-Hydro.\n\n.. _section-4.3:\n\n4.3 Nudging Workflow\n--------------------\n\nFigure 4.1 provides an overview of the nuding workflow at the file\nlevel. Descriptions are provided for each of the files shown in the\ndiagram.\n\n.. figure:: media/nudging-workflow.svg\n :align: center\n :scale: 125%\n\n **Figure 4.1:** The nudging workflow at the file level.\n\n4.3.1 Input Files\n~~~~~~~~~~~~~~~~~\n\n.. rubric:: Discharge observations and :file:`nudgingTimeSliceObs/` :\n\nDischarge observations from the real world enter the WRF-Hydro system through the\n:file:`nugingTimeSliceObs/` directory.\n\nThe individual observation files used for streamflow nudging are stored\nin this directory, each with the the following naming convention\n:file:`YYYY-mm-dd_HH:MM:SS.RRmin.usgsTimeSlice.ncdf`.\n\nThe first part of the filename, ``YYYY-mm-dd_HH:MM:SS``, identifies the\ncenter of the “slice of time” in which observations are found (from year\ndown to second). ``RR`` indicates the resolution, or total width of the time\nslice. Currently this resolution is a **hard-coded** parameter in the model.\nIt is set to 15 minutes as this is the most common reporting frequency\nfor USGS gages in the USA. The ``usgsTimeSlice`` part of the filename is\nfixed and is legacy of the fact that these files were originally\ndesigned for USGS observations. However, any discharge observations can\nbe placed into this format.\n\nThe format of a an example timeslice observation file is given by an\n:program:`ncdump -h` in :ref:`Appendix A14 `. Of the three-dimensional variables,\ntwo are character lengths and only the ``stationIdInd`` dimension is\nvariable (unlimited). The ``stationIdInd`` variable has dimensions of the\nnumber of individual stream gages contained in the file by the fixed\nwidth of the strings (``stationIdStrLen=15``). The variable metadata\ndescribes the contents. The ``stationId`` variable is the “USGS station\nidentifier of length 15”. While the character type of the variable and\nthe length of 15 are both fixed, identifiers are not limited to those\nused by the USGS. Custom identifiers can be used and are described later\nin this section when the gages variable in the :file:`Route_Link.nc` file is\ndescribed. The variable ``discharge_quality`` is simply a multiplier. This\nvalue is stored as a short integer for space concerns and only takes\nvalues from zero to one hundred. Internally in the model, this variable\nis scaled by 100 and used as a floating point variable between zero and\none. The ``queryTime`` variable is not used by the model and is optional. It\nmay be useful in situations when the files are updated in real-time.\nSimilarly, the metadata field ``fileUpdateTimeUTC`` can be useful but is not\nrequired by the model. The remaining two metadata fields are both\nrequired by the model: ``sliceCenterTimeUTC`` and ``sliceTimeResolutionMinutes``\nensure that the file and the model are operating under the same time\nlocation and resolution assumptions. An example of generating timeslice\nfiles from USGS observations using the R language is given in the help\nfor the rwrfhydro function :command:`WriteNcTimeSlice`.\n\n.. rubric:: :file:`hydro.namelist`:\n\nWhen WRF-Hydro is compiled with nudging on, the :file:`hydro.namelist`\nfile is required to contain ``&NUDGING_nlist``. The nudging namelist is\nfound at the bottom of the :file:`hydro.namelist` file either in the :file:`Run/`\ndirectory after compilation or in the :file:`template/HYDRO/` directory.\nThe namelist governs the run-time options to the nudging code. These run-time\noptions are detailed in :ref:`Section 4.5 ` below and in\n:ref:`Appendix A5 `.\n\n.. rubric:: :file:`Route_Link.nc`:\n\nCollocation of streamflow gages and reach elements is achieved\nby the gages field in the :file:`Route_Link.nc` file (see Sections\n:ref:`3.6 ` and :ref:`5.4 `). Each reach\nelement may have a single gage identified with it as specific by a\nfixed-width 15 character string in the gages field. A blank entry\nindicates no gage is present on the reach. The gages field in\n:file:`Route_Link.nc` tells the nudging module where to apply the observed\nvalues to the stream network. Gages which appear in the observation\nfiles but not in the :file:`Route_Link.nc` file do not cause a problem, they are\nsimply skipped and their identifiers collected and printed to the file\n:file:`NWIS_gages_not_in_RLAndParams.txt` file, described later. The number of\nnon-blank routelink gages must match the number of gages supplied in the\nnudging parameters file, described next.\n\n.. rubric:: :file:`nudgingParams.nc`:\n\nAppendix :ref:`A14 ` shows\nthe structure of the :file:`nudgingParams.nc` file for a small domain. Some\nof the parameters in the file are explained in detail in Section\n:ref:`4.2 ` and some are placeholders for capabilities\nwhich have not been developed.\n\n4.3.2 Output Files\n~~~~~~~~~~~~~~~~~~\n\nWhen the code is compiled with the nudging compile-time option on (see\nnext section), four types of output files contain nudging information.\nSome files are different than when compiled without nudging while other\nfiles are unique outputs for the nuding option.\n\n.. rubric:: :file:`YYYYmmddHHMM.CHRTOUT_DOMAIN1`:\n\nThe nudging code affects the values written to the “CHRTOUT” files.\nIf valid observations are available, the (modeled) streamflow variable is\nchanged by the assimilated observations. When the model is compiled to enable\nnudging, the variable ``nudge`` also appears in the file. The nudge value is\ncalculated as in Section :ref:`4.2 `.\n\n.. rubric:: :file:`nudgingLastObs.YYYY-mm-dd_HH:MM:SS.nc`:\n\nThese files are unique to the nudging compile and are the restart files\nfor the nudging component of the model. A restart file is not required,\nnudging can be run from a cold start. This file can contain multiple variables,\nonly the ``nudge`` variable is described in this documentation.\n\n.. rubric:: :file:`NWIS_gages_not_in_RLAndParams.txt`:\n\nThese files are unique to nudging and report the unique gages found in the\nobservation time slice files which were not present in the :file:`Route_Link.nc`\nfile. These are gages which may have the opportunity to be assimilated (provided\nthey could be located in the domain). There is only one such file per run, written\nat the end of the run.\n\n.. rubric:: Standard output and :file:`hydro_diag.*` files:\n\nThe nudging routines write various messages. The ultimate destination of these\ncan be compiler dependent. The nudging code aims to preface all its messages with ``Ndg:``\nand all its warnings with ``Ndg: WARNING:``.\n\n4.4 Nudging compile-time option\n-------------------------------\n\nThe nuding capability is only available when the code is compiled with\nthe environment variable set:\n\n``WRF_HYDRO_NUDGING=1``\n\n.. _section-4.5:\n\n4.5 Nudging run-time options\n----------------------------\n\n:ref:`Appendix A5 ` presents an annotated :file:`hydro.namelist`\nfile. There are two Fortran namelists contained within that file. The nudging\nrun-time options are contained the ``NUDGING_nlist`` which is the second namelist\nin the document. Only some run time options listed in the namelist are\ndocumented at this time.\n\n+-----------------------------------+---------------------------------------+\n| **Documented/Supported Options** | **Undocumented/Unsupported Options** |\n+===================================+=======================================+\n| ``timeSlicePath`` | ``nLastObs`` |\n| | |\n| ``nudgingParamFile`` | ``persistBias`` |\n| | |\n| ``nudgingLastObsFile`` | ``biasWindowBeforeT0`` |\n| | |\n| ``readTimesliceParallel`` | ``maxAgePairsBiasPersist`` |\n| | |\n| ``temporalPersistence`` | ``minNumPairsBiasPersist`` |\n| | |\n| | ``invDistTimeWeightBias`` |\n| | |\n| | ``noConstInterfBias`` |\n+-----------------------------------+---------------------------------------+\n\nDetails on the meaning and usage of the options are given in\n:ref:`Appendix A5 `, in both the comments which are part of the namelist\nitself and by the blue annotations added to the namelists. The supported options\nare fairly straight forward in their usage. It is worth noting that the\nspecfication of the :file:`nudgingLastObsFile` does not behave the same way as\nthe specification of the LSM or hydro restart files. The unsupported\nnudging options have to do with mostly experimental methods for forecast\nbias correction which have been investigated.\n" }, { "path": "docs/userguide/output-tables/CHANOBS_DOMAIN.csv", "content": "Variable Name,Long Name,Description,Units,IO_ConfigOutputs_0,IO_ConfigOutputs_1,IO_ConfigOutputs_2,IO_ConfigOutputs_3,IO_ConfigOutputs_4,IO_ConfigOutputs_5,IO_ConfigOutputs_6,Min,Max,Scale,Offset,Fill\r\ntime,valid output time,Valid output time,minutes since 1970-01-01 00:00:00 UTC,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nreference_time,model initialization time,Model initialization time,minutes since 1970-01-01 00:00:00 UTC,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nfeature_id,Reach ID,Unique reach or channel cell ID,-,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nlatitude,Feature latitude,Station latitude,decimal degrees,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nlongitude,Feature longitude,Station longitude,decimal degrees,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\norder,Streamflow Order,Strahler stream order for output reach or cell,-,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nelevation,Feature Elevation,Elevation for output reach or cell,m,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nstreamflow,River Flow,Streamflow,m3 s-1,Yes,Yes,Yes,Yes,Yes,Yes,Yes,0,500000,0.01,0,-9999\r\n" }, { "path": "docs/userguide/output-tables/CHRTOUT_DOMAIN.csv", "content": "Variable Name,Long Name,Description,Units,IO_ConfigOutputs_0,IO_ConfigOutputs_1,IO_ConfigOutputs_2,IO_ConfigOutputs_3,IO_ConfigOutputs_4,IO_ConfigOutputs_5,IO_ConfigOutputs_6,Min,Max,Scale,Offset,Fill,Special Notes\r\ntime,valid output time,Valid output time,minutes since 1970-01-01 00:00:00 UTC,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A,\r\nreference_time,model initialization time,Model initialization time,minutes since 1970-01-01 00:00:00 UTC,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A,\r\nfeature_id,Reach ID,Unique reach or channel cell ID,-,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A,\r\nlatitude,Feature latitude,Station latitude,decimal degrees,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A,\r\nlongitude,Feature Longitude,Station longitude,decimal degrees,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A,\r\norder,Streamflow order,Strahler stream order for output reach or cell,-,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A,\r\nelevation,Feature Elevation,Elevation for output reach or cell,m,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A,\r\nstreamflow,River Flow,Streamflow,m3 s-1,Yes,Yes,Yes,Yes,Yes,Yes,Yes,0,500000,0.01,0,-9999,\r\nnudge,Amount of stream flow alteration,Streamflow nudge value (only if nudging DA is active),m3 s-1,No,No,No,No,No,No,No,-500000,500000,0.01,0,-9999,Values only when nudging DA is active\r\nq_lateral,Runoff into channel reach,Lateral flow into channel reach or cell,m3 s-1,Yes,No,No,No,No,Yes,Yes,0,500000,0.1,0,-9999,\r\nvelocity,River Velocity,Channel velocity,m s-1,Yes,Yes,Yes,Yes,Yes,Yes,Yes,0,500000,0.01,0,-9999,\r\nhead,River Stage,River stage (gridded channel only),m,Yes,No,No,No,No,No,No,0,500000,0.01,0,-9999,\r\nqSfcLatRunoff,Runoff from terrain routing,Flux from terrain routing,m3 s-1,No,No,No,No,No,No,No,0,500000,0.001,0,-9999,Only available for UDMP_OPT=1\r\nqBucket,Flux from gw bucket,Flux from groundwater buckets,m3 s-1,No,No,No,No,No,No,No,0,500000,0.001,0,-9999,Only available for UDMP_OPT=1\r\nqBtmVertRunoff,Runoff from bottom of soil to bucket,Flux from bottom of soil column into groundwater buckets,m3,No,No,No,No,No,No,No,0,500000,0.001,0,-9999,Only available for UDMP_OPT=1\r\nAccSfcLatRunoff,Accumulated runoff from terrain routing,Accumulated flux from terrain routing,m3,No,No,No,No,No,No,No,0,500000,0.01,0,-9999,Only available for UDMP_OPT=1\r\naccBucket,Accumulated runoff from gw bucket,Accumulated flux from groundwater buckets,m3,No,No,No,No,No,No,No,0,500000,0.01,0,-9999,Only available for UDMP_OPT=1\r\n" }, { "path": "docs/userguide/output-tables/CHRTOUT_GRID.csv", "content": "Variable Name,Long Name,Description,Units,IO_ConfigOutputs_0,IO_ConfigOutputs_1,IO_ConfigOutputs_2,IO_ConfigOutputs_3,IO_ConfigOutputs_4,IO_ConfigOutputs_5,IO_ConfigOutputs_6,Min,Max,Scale,Offset,Fill\r\ntime,valid output time,Valid output time,minutes since 1970-01-01 00:00:00 UTC,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nreference_time,model initialization time,Model initialization time,minutes since 1970-01-01 00:00:00 UTC,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nx,x coordinate of projection,x coordinate (in native projection),native projection units,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\ny,y coordinate of projection,y coordinate (in native projection),native projection units,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nIndex,Stream cell index value,Stream cell index value,-,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nstreamflow,River Flow,Streamflow,m3 s-1,Yes,Yes,Yes,Yes,Yes,Yes,Yes,0,500000,0.1,0,-9999\r\n" }, { "path": "docs/userguide/output-tables/GWOUT_DOMAIN.csv", "content": "Variable Name,Long Name,Description,Units,IO_ConfigOutputs_0,IO_ConfigOutputs_1,IO_ConfigOutputs_2,IO_ConfigOutputs_3,IO_ConfigOutputs_4,IO_ConfigOutputs_5,IO_ConfigOutputs_6,Min,Max,Scale,Offset,Fill\r\ntime,valid output time,Valid output time,minutes since 1970-01-01 00:00:00 UTC,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nreference_time,model initialization time,Model initialization time,minutes since 1970-01-01 00:00:00 UTC,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nfeature_id,Groundwater Bucket ID,Unique groundwater bucket ID,-,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\ninflow,Bucket Inflow,Total groundwater bucket inflow,m3 s-1,Yes,Yes,Yes,Yes,Yes,Yes,Yes,-10000,10000,0.01,0,-9999\r\noutflow,Bucket Outflow,Total groundwater bucket outflow,m3 s-1,Yes,Yes,Yes,Yes,Yes,Yes,Yes,-10000,10000,0.01,0,-9999\r\ndepth,Bucket Depth,Groundwater bucket water level,mm,Yes,Yes,Yes,Yes,Yes,Yes,Yes,-10000,10000,0.1,0,-9999\r\n" }, { "path": "docs/userguide/output-tables/LAKEOUT_DOMAIN.csv", "content": "Variable Name,Long Name,Description,Units,IO_ConfigOutputs_0,IO_ConfigOutputs_1,IO_ConfigOutputs_2,IO_ConfigOutputs_3,IO_ConfigOutputs_4,IO_ConfigOutputs_5,IO_ConfigOutputs_6,Min,Max,Scale,Offset,Fill\r\ntime,valid output time,Valid output time,minutes since 1970-01-01 00:00:00 UTC,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nreference_time,model initialization time,Model initialization time,minutes since 1970-01-01 00:00:00 UTC,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nfeature_id,Lake COMMON ID,Unique lake ID,-,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nlatitude,Lake latitude,Lake latitude,decimal degrees,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nlongitude,Lake longitude,Lake longitude,decimal degrees,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nwater_sfc_elev,Water Surface Elevation,Water surface elevation above sea level,m,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\ninflow,Lake Inflow,Total inflow into waterbody,m3 s-1,Yes,Yes,Yes,Yes,Yes,Yes,Yes,-10000,10000,0.01,0,-9999\r\noutflow,Lake Outflow,Outflow from waterbody outlet,m3 s-1,Yes,Yes,Yes,Yes,Yes,Yes,Yes,-10000,10000,0.01,0,-9999\r\n" }, { "path": "docs/userguide/output-tables/LDASOUT_DOMAIN.csv", "content": "Variable Name,Long Name,Description,Units,IO_ConfigOutputs_0,IO_ConfigOutputs_1,IO_ConfigOutputs_2,IO_ConfigOutputs_3,IO_ConfigOutputs_4,IO_ConfigOutputs_5,IO_ConfigOutputs_6,Min,Max,Scale,Offset,Fill\r\ntime,valid output time,Valid output time,minutes since 1970-01-01 00:00:00 UTC,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nreference_time,model initialization time,Model initialization time,minutes since 1970-01-01 00:00:00 UTC,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nx,x coordinate of projection,x coordinate (in native projection),native projection units,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\ny,y coordinate of projection,x coordinate (in native projection),native projection units,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nIVGTYP,Dominant vegetation category,Dominant vegetation category,category,Yes,No,No,No,No,No,No,0,100,1,0,-9999\r\nISLTYP,Dominant soil category,Dominant soil category,category,Yes,No,No,No,No,No,No,0,100,1,0,-9999\r\nFVEG,Green Vegetation Fraction,Fraction of surface covered by vegetation,fraction,Yes,No,No,No,No,No,No,0,1,0.01,0,-9999\r\nLAI,Leaf area index,Leaf area index,m2 m-2,Yes,No,No,No,No,No,No,0,20,0.1,0,-9999\r\nSAI,Stem area index,Stem area index,m2 m-2,Yes,No,No,No,No,No,No,0,20,0.1,0,-9999\r\nSWFORC,Shortwave forcing,Shortwave radiation forcing,W m-2,Yes,No,No,No,No,No,No,-1000,3000,0.1,0,-9999\r\nCOSZ,Cosine of zenith angle,Cosine of zenith angle,-,Yes,No,No,No,No,No,No,-1,1,0.01,0,-9999\r\nLWFORC,Longwave forcing,Longwave radiation forcing,W m-2,Yes,No,No,No,No,No,No,-1500,1500,0.1,0,-9999\r\nRAINRATE,Precipitation rate,Precipitation in model timestep,mm s-1,Yes,No,No,No,No,No,No,0,100,0.000001,0,-9999\r\nEMISS,Grid emissivity,Emissivity: grid-average,-,Yes,No,No,No,No,No,No,0,1,0.01,0,-9999\r\nFSA,Total absorbed SW radiation,Total absorbed SW radiation,W m-2,Yes,No,No,Yes,No,Yes,Yes,-1500,1500,0.1,0,-9999\r\nFIRA,Total net LW radiation to atmosphere,Total net LW radiation (+ to atmosphere),W m-2,Yes,No,No,Yes,No,Yes,Yes,-1500,1500,0.1,0,-9999\r\nGRDFLX,Heat flux into the soil,Ground heat flux: grid-average (+ to soil),W m-2,Yes,No,No,Yes,No,No,Yes,-1500,1500,0.1,0,-9999\r\nHFX,Total sensible heat to the atmosphere,Sensible heat flux: grid-average (+ to atmosphere),W m-2,Yes,No,No,Yes,No,Yes,Yes,-1500,1500,0.1,0,-9999\r\nLH,Total latent heat to the atmosphere,Latent heat flux: grid-average (+ to atmosphere),W m-2,Yes,No,No,Yes,No,Yes,Yes,-1500,1500,0.1,0,-9999\r\nECAN,Canopy water evaporation rate,Canopy water evaporation rate,kg m-2 s-1,Yes,No,No,No,No,No,No,-100,100,0.000001,0,-9999\r\nEDIR,Direct from soil evaporation rate,Direct soil evaporation rate,kg m-2 s-1,Yes,No,No,No,No,No,No,-100,100,0.000001,0,-9999\r\nALBEDO,Surface albedo,Total-grid surface albedo,-,Yes,No,No,No,No,No,No,0,1,0.01,0,-9999\r\nETRAN,Transpiration rate,Transpiration rate,kg m-2 s-1,Yes,No,No,No,No,No,No,-100,100,0.000001,0,-9999\r\nUGDRNOFF,Accumulated underground runoff,Underground runoff: accumulated,mm,Yes,No,No,Yes,Yes,Yes,Yes,-100,100000,0.01,0,-9999\r\nSFCRNOFF,Accumulated surface runoff,Surface runoff: accumulated,mm,Yes,No,No,No,Yes,Yes,Yes,0,100000,0.001,0,-9999\r\nCANLIQ,Canopy liquid water content,Canopy liquid water content,mm,Yes,No,No,No,No,No,No,-5,30000,0.01,0,-9999\r\nCANICE,Canopy ice water content,Canopy ice water content,mm,Yes,No,No,No,No,No,No,-5,30000,0.01,0,-9999\r\nZWT,Depth to the water table,Depth to water table,m,Yes,No,No,No,No,No,No,0,10,0.00001,0,-9999\r\nWA,Water in aquifer,Water in aquifer relative to reference level,kg m-2,Yes,No,No,No,No,No,No,0,10000,0.01,0,-9999\r\nWT,Water in aquifer and saturated soil,Water in aquifer and saturated soil,kg m-2,Yes,No,No,No,No,No,No,0,10000,0.01,0,-9999\r\nACCPRCP,Accumulated precip,Accumulated precipitation,mm,Yes,No,No,No,No,No,No,0,1000000,0.01,0,-9999\r\nACCECAN,Accumulated canopy water,Accumulated canopy evaporation,mm,Yes,No,No,Yes,No,No,Yes,-100,1000000,0.01,0,-9999\r\nACCEDIR,Accumulated direct soil evap,Accumulated direct soil evaporation,mm,Yes,No,No,Yes,No,No,Yes,-100,1000000,0.01,0,-9999\r\nACCETRAN,Accumulated transpiration,Accumulated transpiration,mm,Yes,No,No,Yes,No,No,Yes,-100,1000000,0.01,0,-9999\r\nSAV,Solar radiative heat flux aborbed by vegetation,Solar radiation absorbed: vegetation canopy,W m-2,Yes,No,No,No,No,No,No,-1500,1500,0.1,0,-9999\r\nTR,Transpiration heat,Transpiration heat flux,W m-2,Yes,No,No,No,No,No,No,-1500,1500,0.1,0,-9999\r\nEVC,Canopy evap heat,Latent heat flux: leaf to canopy air,W m-2,Yes,No,No,No,No,No,No,-1500,1500,0.1,0,-9999\r\nIRC,Canopy net LW rad,Net emitted LW radiation: canopy,W m-2,Yes,No,No,No,No,No,No,-1500,1500,0.1,0,-9999\r\nSHC,Canopy sensible heat,Sensible heat flux: leaf to canopy air,W m-2,Yes,No,No,No,No,No,No,-1500,1500,0.1,0,-9999\r\nIRG,Ground net LW rad,Net emitted LW radiation: below-canopy ground,W m-2,Yes,No,No,No,No,No,No,-1500,1500,0.1,0,-9999\r\nSHG,Ground sensible heat,Sensible heat flux: below-canopy ground to canopy air,W m-2,Yes,No,No,No,No,No,No,-1500,1500,0.1,0,-9999\r\nEVG,Ground evap heat,Latent heat flux: below-canopy ground to canopy air,W m-2,Yes,No,No,No,No,No,No,-1500,1500,0.1,0,-9999\r\nGHV,Ground heat flux + to soil vegetated,Ground heat flux: vegetated fraction (+ to soil),W m-2,Yes,No,No,No,No,No,No,-1500,1500,0.1,0,-9999\r\nSAG,Solar radiative heat flux absorved by ground,Solar radiation absorbed: ground surface,W m-2,Yes,No,No,No,No,No,No,-1500,1500,0.1,0,-9999\r\nIRB,Net LW rad to atm bare,Net emitted LW radiation: bare ground,W m-2,Yes,No,No,No,No,No,No,-1500,1500,0.1,0,-9999\r\nSHB,Sensible heat atm bare,Sensible heat flux: bare ground to atmosphere,W m-2,Yes,No,No,No,No,No,No,-1500,1500,0.1,0,-9999\r\nEVB,Evaporation heat to atm bare,Latent heat flux: bare ground to atmosphere,W m-2,Yes,No,No,No,No,No,No,-1500,1500,0.1,0,-9999\r\nGHB,Ground heat flux + to soil bare,Ground heat flux: bare ground fraction (+ to soil),W m-2,Yes,No,No,No,No,No,No,-1500,1500,0.1,0,-9999\r\nTRAD,Surface radiative temperature,Surface radiative temperature: grid,K,Yes,No,No,Yes,No,Yes,Yes,0,400,0.1,0,-9999\r\nTG,Ground temperature,Ground temperature: grid-average,K,Yes,No,No,No,No,No,No,0,400,0.1,0,-9999\r\nTV,Vegetation temperature,Vegetation leaf temperature,K,Yes,No,No,No,No,No,No,0,400,0.1,0,-9999\r\nTAH,Canopy air temperature,Canopy air temperature,K,Yes,No,No,No,No,No,No,0,400,0.1,0,-9999\r\nTGV,Ground surface Temp vegetated,Ground temperature: vegetated ground,K,Yes,No,No,No,No,No,No,0,400,0.1,0,-9999\r\nTGB,Ground surface Temp bare,Ground temperature: bare ground,K,Yes,No,No,No,No,No,No,0,400,0.1,0,-9999\r\nT2MV,2m Air Temp vegetated,Air temperature @ 2m: vegetated ground,K,Yes,No,No,No,No,No,No,0,400,0.1,0,-9999\r\nT2MB,2m Air Temp bare,Air temperature @ 2m: bare ground,K,Yes,No,No,No,No,No,No,0,400,0.1,0,-9999\r\nQ2MV,2m mixing ratio vegetated,Mixing ratio @ 2m: vegetated ground,kg/kg,Yes,No,No,No,No,No,No,0,1,0.0001,0,-9999\r\nQ2MB,2m mixing ratio bare,Mixing ratio @ 2m: bare ground,kg/kg,Yes,No,No,No,No,No,No,0,1,0.0001,0,-9999\r\nEAH,Canopy air vapor pressure,Canopy air vapor pressure,Pa,Yes,No,No,No,No,No,No,-1000,100000,0.1,0,-9999\r\nFWET,Wetted or snowed fraction of canopy,Fraction of canopy covered by liquid or frozen water,fraction,Yes,No,No,No,No,No,No,0,1,0.01,0,-9999\r\nZSNSO_SN,Snow layer depths from snow surface,Snow and soil interface depths (from snow surface),m,Yes,No,No,No,No,No,No,-100,100,0.00001,0,-9999\r\nSNICE,Snow layer ice,Snow layer ice,mm,Yes,No,No,No,No,No,No,0,100000,0.01,0,-9999\r\nSNLIQ,Snow layer liquid water,Snow layer liquid water,mm,Yes,No,No,Yes,No,No,Yes,0,100000,0.01,0,-9999\r\nSOIL_T,soil temperature,Soil temperature,K,Yes,No,No,Yes,No,No,Yes,0,400,0.1,0,-9999\r\nSOIL_W,liquid volumetric soil moisture,Volumetric soil moisture: liquid,m3 m-3,Yes,No,No,No,No,Yes,Yes,0,1,0.01,0,-9999\r\nSNOW_T,snow temperature,Snow temperature,K,Yes,No,No,No,No,No,No,0,400,0.1,0,-9999\r\nSOIL_M,volumetric soil moisture,Volumetric soil moisture,m3 m-3,Yes,No,No,Yes,No,Yes,Yes,0,1,0.01,0,-9999\r\nSNOWH,Snow depth,Snow depth,m,Yes,Yes,Yes,Yes,No,Yes,Yes,0,100,0.0001,0,-9999\r\nSNEQV,Snow water equivalent,Snow water equivalent,kg m-2,Yes,Yes,Yes,Yes,Yes,Yes,Yes,0,100000,0.1,0,-9999\r\nQSNOW,Snowfall rate,Snowfall rate at ground surface,mm s-1,Yes,No,No,No,No,No,No,0,100,0.000001,0,-9999\r\nISNOW,Number of snow layers,Number of active snow layers,count,Yes,No,No,Yes,No,No,Yes,0,10,1,0,-9999\r\nFSNO,Snow-cover fraction on the ground,Fraction of surface covered by snow,fraction,Yes,Yes,Yes,Yes,No,Yes,Yes,0,1,0.001,0,-9999\r\nACSNOW,accumulated snow fall,Accumulated snow fall,mm,Yes,No,No,No,No,No,No,0,100000,0.01,0,-9999\r\nACSNOM,accumulated melting water out of snow bottom,Accumulated melting water out of snow bottom,mm,Yes,No,No,Yes,Yes,No,Yes,0,100000,0.01,0,-9999\r\nCM,Momentum drag coefficient,Exchange coefficient: grid-average,-,Yes,No,No,No,No,No,No,-5,5,0.00001,0,-9999\r\nCH,Sensible heat exchange coefficient,Exchange coefficient: grid-average,-,Yes,No,No,No,No,No,No,-5,5,0.00001,0,-9999\r\nCHV,Exchange coefficient vegetated,Exchange coefficient: vegetation-atmosphere,m s-1,Yes,No,No,No,No,No,No,-5,5,0.00001,0,-9999\r\nCHB,Exchange coefficient bare,Exchange coefficient: bare ground,m s-1,Yes,No,No,No,No,No,No,-5,5,0.00001,0,-9999\r\nCHLEAF,Exchange coefficient leaf,Exchange coefficient: leaf surface,m s-1,Yes,No,No,No,No,No,No,-5,5,0.00001,0,-9999\r\nCHUC,Exchange coefficient bare,Exchange coefficient: below-canopy,m s-1,Yes,No,No,No,No,No,No,-5,5,0.00001,0,-9999\r\nCHV2,Exchange coefficient 2-meter vegetated,Exchange coefficient: vegetation-atmosphere @ 2-meters,m s-1,Yes,No,No,No,No,No,No,-5,5,0.00001,0,-9999\r\nCHB2,Exchange coefficient 2-meter bare,Exchange coefficient: bare ground @ 2-meters,m s-1,Yes,No,No,No,No,No,No,-5,5,0.00001,0,-9999\r\nLFMASS,Leaf mass,Leaf carbon mass,g C m-2,Yes,No,No,No,No,No,No,0,1000,0.01,0,-9999\r\nRTMASS,Mass of fine roots,Root carbon mass,g C m-2,Yes,No,No,No,No,No,No,0,1000,0.01,0,-9999\r\nSTMASS,Stem mass,Stem carbon mass,g C m-2,Yes,No,No,No,No,No,No,0,1000,0.01,0,-9999\r\nWOOD,Mass of wood and woody roots,Wood and woody roots carbon mass,g C m-2,Yes,No,No,No,No,No,No,0,1000,0.01,0,-9999\r\nSTBLCP,Stable carbon in deep soil,Stable carbon in deep soil,g C m-2,Yes,No,No,No,No,No,No,0,5000,0.01,0,-9999\r\nFASTCP,Short-lived carbon in shallow soil,Short-lived carbon in shallow soil,g C m-2,Yes,No,No,No,No,No,No,0,5000,0.01,0,-9999\r\nNEE,Net ecosystem exchange,Net ecosystem exchange,g m-2 s-1 CO2,Yes,No,No,No,No,No,No,0,1000,0.01,0,-9999\r\nGPP,Net instantaneous assimilation,Net instantaneous carbon assimilation,g m-2 s-1 C,Yes,No,No,No,No,No,No,0,1000,0.01,0,-9999\r\nNPP,Net primary productivity,Net primary productivity,g m-2 s-1 C,Yes,No,No,No,No,No,No,0,1000,0.01,0,-9999\r\nPSN,Total photosynthesis,Total photosynthesis,umol CO2 m-2 s-1,Yes,No,No,No,No,No,No,0,1000,0.01,0,-9999\r\nAPAR,Photosynthesis active energy by canopy,Absorbed photosynthetically active radiation,W m-2,Yes,No,No,No,No,No,No,0,1000,0.01,0,-9999\r\nACCET,Accumulated total ET,Accumulated total evapotranspiration,mm,Yes,Yes,Yes,Yes,Yes,Yes,Yes,-1000,1000000,0.01,0,-9999\r\nCANWAT,Total canopy water (liquid + ice),Total canopy water (liquid + ice),mm,Yes,No,No,Yes,Yes,No,Yes,-5,30000,0.01,0,-9999\r\nSOILICE,fraction of soil moisture that is ice,Fraction of soil moisture that is ice,fraction,Yes,No,No,Yes,No,No,Yes,0,1,0.01,0,-9999\r\nSOILSAT_TOP,fraction of soil saturation (top 2 layers),Fraction of soil saturation (top 2 layers),fraction,Yes,Yes,Yes,Yes,Yes,No,Yes,0,1,0.001,0,-9999\r\nSOILSAT,fraction of soil saturation (column integrated),Fraction of soil saturation (column integrated),fraction,Yes,No,No,No,Yes,No,Yes,0,1,0.001,0,-9999\r\nSNOWT_AVG,average snow temperature (by layer mass),Average snow temperature (by layer mass),K,Yes,Yes,Yes,Yes,No,No,Yes,0,400,0.1,0,-9999\r\nALBSND,snowpack albedo (direct),Snowpack albedo (direct),-,Yes,No,No ,No,No,Yes,Yes,0,1,0.01,0,-9999\r\nALBSNI,snowpack albedo (diffuse),Snowpack albedo (diffuse),-,Yes,No,No,No,No ,Yes,Yes,0,1,0.01,0,-9999\r\n" }, { "path": "docs/userguide/output-tables/LSMOUT.csv", "content": "Variable Name,Long Name,Description,Units,IO_ConfigOutputs_0,IO_ConfigOutputs_1,IO_ConfigOutputs_2,IO_ConfigOutputs_3,IO_ConfigOutputs_4,IO_ConfigOutputs_5,IO_ConfigOutputs_6,,\r\ntime,valid output time,Valid output time,minutes since 1970-01-01 00:00:00 UTC,Yes,Yes,Yes,Yes,Yes,Yes,Yes,,\r\nreference_time,model initialization time,Model initialization time,minutes since 1970-01-01 00:00:00 UTC,Yes,Yes,Yes,Yes,Yes,Yes,Yes,,\r\nx,x coordinate of projection,x coordinate (in native projection),native projection units,Yes,Yes,Yes,Yes,Yes,Yes,Yes,,\r\ny,y coordinate of projection,x coordinate (in native projection),native projection units,Yes,Yes,Yes,Yes,Yes,Yes,Yes,,\r\nstc1,Soil temperature in the top layer,Soil temperature in the top layer,K,Yes,Yes,Yes,Yes,Yes,Yes,Yes,,\r\nsmc1,Soil moisture in the top layer,Volumetric soil moisture in the top layer,m3 m-3,Yes,Yes,Yes,Yes,Yes,Yes,Yes,,\r\nsh2ox1,Volumetric soil moisture in the top layer,Liquid water in the top layer,m3 m-3,Yes,Yes,Yes,Yes,Yes,Yes,Yes,,\r\nstc2,Soil temperature in the second layer,Soil temperature in the second layer,K,Yes,Yes,Yes,Yes,Yes,Yes,Yes,,\r\nsmc2,Soil moisture in the second layer,Volumetric soil moisture in the second layer,m3 m-3,Yes,Yes,Yes,Yes,Yes,Yes,Yes,,\r\nsh2ox2,Volumetric soil moisture in the second layer,Liquid water in the second layer,m3 m-3,Yes,Yes,Yes,Yes,Yes,Yes,Yes,,\r\nstc3,Soil temperature in the third layer,Soil temperature in the third layer,K,Yes,Yes,Yes,Yes,Yes,Yes,Yes,,\r\nsmc3,Soil moisture in the third layer,Volumetric soil moisture in the third layer,m3 m-3,Yes,Yes,Yes,Yes,Yes,Yes,Yes,,\r\nsh2ox3,Volumetric soil moisture in the third layer,Liquid water in the third layer,m3 m-3,Yes,Yes,Yes,Yes,Yes,Yes,Yes,,\r\nstc4,Soil temperature in the fourth layer,Soil temperature in the bottom layer,K,Yes,Yes,Yes,Yes,Yes,Yes,Yes,,\r\nsmc4,Soil moisture content in the fourth layer,Volumetric soil moisture in the bottom layer,m3 m-3,Yes,Yes,Yes,Yes,Yes,Yes,Yes,,\r\nsh2ox4,Volumetric soil moisture in the fourth layer,Liquid water in the bottom layer,m3 m-3,Yes,Yes,Yes,Yes,Yes,Yes,Yes,,\r\ninfxsrt,Infiltration excess,Infiltration excess (from LSM),mm,Yes,Yes,Yes,Yes,Yes,Yes,Yes,,\r\nsfcheadrt,Surface head,Surface head (from HYDRO),mm,Yes,Yes,Yes,Yes,Yes,Yes,Yes,,\r\n" }, { "path": "docs/userguide/output-tables/RTOUT_DOMAIN.csv", "content": "Variable Name,Long Name,Description,Units,IO_ConfigOutputs_0,IO_ConfigOutputs_1,IO_ConfigOutputs_2,IO_ConfigOutputs_3,IO_ConfigOutputs_4,IO_ConfigOutputs_5,IO_ConfigOutputs_6,Min,Max,Scale,Offset,Fill\r\ntime,valid output time,Valid output time,minutes since 1970-01-01 00:00:00 UTC,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nreference_time,model initialization time,Model initialization time,minutes since 1970-01-01 00:00:00 UTC,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nx,x coordinate of projection,x coordinate (in native projection),native projection units,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\ny,y coordinate of projection,x coordinate (in native projection),native projection units,Yes,Yes,Yes,Yes,Yes,Yes,Yes,N/A,N/A,N/A,N/A,N/A\r\nSOIL_M,volumetric soil moisture,Volumetric soil moisture,m3 m-3,Yes,No,No,No,No,No,No,0,1,0.01,0,-9999\r\nzwattablrt,water table depth,Depth to saturated layers (=2m when no saturation; =0 when fully saturated),m,Yes,Yes,Yes,Yes,Yes,Yes,Yes,0,10,0.1,0,-9999\r\nsfcheadsubrt,surface head,Instantaneous value of depth of ponded water on surface,mm,Yes,Yes,Yes,Yes,Yes,Yes,Yes,0,1000000,1,0,-9999\r\nQSTRMVOLRT,channel inflow,Accumulated depth of stream channel inflow,mm,Yes,No,No,No,No,No,No,0,1000,1,0,-9999\r\nQBDRYRT,accumulated value of the boundary flux,Accumulated flow volume routed outside of the domain from the boundary cells,mm,Yes,No,No,No,No,No,No,0,1000,1,0,-9999\r\n" }, { "path": "docs/userguide/references.rest", "content": ".. vim: syntax=rst\n\nREFERENCES\n==========\n\nBelow are cited references in an alphabetical listing by author.\n\nBall, J. T., I. E. Woodrow, and J. A. Berry (1987), A model predicting\nstomatal conductance and its contribution to the control of\nphotosynthesis under different environmental conditions, in Process in\nPhotosynthesis Research, vol. 1, edited by J. Biggins, pp. 221–234,\nMartinus Nijhoff, Dordrecht, Netherlands.\n\nBowling, L.C., D.P. Lettenmaier, B. Nijssen, L.P. Graham and\nco-authors, 2003: Simulation of high latitude hydrological processes in\nthe Torne-Kalix basin: PILPS Phase 2(c) 1: Experiment description and\nsummary intercomparisons. Global and Planet. Change\n\nBrun, E., Martin, E., Simon, V., Gendre, C., and Coléou, C.: An energy and\nmass model of snow cover suitable for operational avalanche forecasting, J.\nGlaciol., 35, 333-342, https://doi.org/10.3189/S0022143000009254, 1989.\n\nBrun, E., David, P., Sudul, M., and Brunot, G.: A numer- ical model to simulate\nsnow-cover stratigraphy for operational avalanche forecasting, J. Glaciol., 38,\n13-22, https://doi.org/10.3189/S0022143000009552, 1992.\n\nBrun, E., Martin, E., and Spiridonov, V.: Coupling a multi- layered snow model\nwith a GCM, Ann. Glaciol., 25, 66-72,\nhttps://doi.org/10.3189/S0260305500013811, 1997.\n\nBryan, F. O., B. G. Kauffman, W. G. Large, and P. R. Gent (1996). The\nNCAR CSM flux coupler, NCAR Tech. Note 424, 50 pp. [Available from NCAR,\nBoulder, CO 80307]\n\nChen, F., K.E. Mitchell, J. Schaake, Y. Xue, H.-L. Pan, V. Koren,\nQ.Y. Duan, M. Ek and A. Betts, 1996: Modeling of land-surface\nevaporation by four schemes and comparison with FIFE observations. J.\nGeophys. Res., 101, 7251-7268.\n\nChen, F., Z. Janic and K.E. Mitchell, 1997: Impact of atmospheric\nsurface-layer parameterizations in the new land-surface scheme of the\nNCEP mesoscale Eta model. Bound.-Layer Meteorol., 85, 391-421.\n\nChen, F. and K.E. Mitchell, 1999: Using the GEWEX/ISLSCP forcing\ndata to simulate global soil moisture fields and hydrological cycle for\n1987-1988, J. Meteorol. Soc. Japan, 77, 167-182.\n\nDickinson, R. E., M. Shaikh, R. Bryant, and L. Graumlich (1998),\nInteractive canopies for a climate model, J. Clim., 11, 2823-2836,\ndoi:10.1175/1520-0442.\n\nDirmeyer, P.A., A.J. Dolman, N. Sato, 1999: The pilot phase of\nthe Global Soil Wetness Project. Bull. Am. Meteorol. Soc., 80(5),\n851-878.\n\nEidhammer, T., A. Booth, S. Decker, L. Li, M. Barlage., D. Gochis., R.\nRasmussen, K. Melvold., A. Nesje and S Sobolowski (2021), Mass balance and\nhydrological modeling of the Hardangerjøkulen ice cap in south-central Norway,\nHydrol. Earth Syst. Sci. 25, 4275-4297,\nhttps://doi.org/10.5194/hess-25-4275-2021.\n\nEk, M.B., K.E. Mitchell, Y. Lin, E. Rogers, P. Grunmann, V.\nKoren, G. Gayno, and J.D. Tarpley, 2003: Implementation of Noah land\nsurface model advances in the NCEP operational mesoscale Eta model.\nSubmitted to J. Geophys. Res., Aug., 2003.\n\nGerbaux, M., Genthon, C., Etchevers, P., Vincent, C., and Dedieu, J.: Surface\nmass balance of glacier in the French Alps: Dis- tributed modeling sensitivity\nto climate change, J. Glaciol., 175, 561-572,\nhttps://doi.org/10.3189/172756505781829133, 2005.\n\nGochis, D.J. and F. Chen, 2003: Hydrological enhancements to the\ncommunity Noah land surface model. NCAR Technical Note, NCAR/TN-454+STR,\n68 pgs.\n\nJones, P. W. (1999). First- and Second-Order Conservative Remapping\nSchemes for Grids in Spherical Coordinates, Monthly Weather Review,\nVolume 127, 2204-2210.\n\nJulien, P.Y., B. Saghafian and F.L. Ogden, 1995: Raster-based\nhydrological modeling of spatially-varied surface runoff. Water Resour.\nBull., AWRA, 31(3), 523-536.\n\nKoren, V., J.C. Schaake, K.E. Mitchell, Q.Y. Duan, F. Chen and J.\nBaker, 1999: A parameterization of snowpack and frozen ground intended for\nNCEP weather and climate models. J. Geophys. Res., 104(D16),\n19,569-19,585.\n\nLDAS, 2003: Land Data Assimilation Systems (LDAS). World Wide Web\nHomepage. Available online at: http://ldas.gsfc.nasa.gov/\n\nMahrt, L. and H.-L. Pan, 1984: A two-layer model of soil\nhydrology. Bound.-Layer Meteorol., 29, 1-20, 1984.\n\nNiu, G.-Y., et al. (2011), The community Noah land surface model with\nmultiparameterization options (Noah-MP): 1. Model description and\nevaluation with local-scale measurements, J. Geophys. Res. 116, D12109,\ndoi: 10.1029/2010JD015139.\n\nNiu, G.-Y., and Z.-L. Yang (2004), The effects of canopy processes on\nsnow surface energy and mass balances, J. Geophys. Res., 109, D23111,\ndoi:10.1029/2004JD004884.\n\nNiu, G.-Y., Z.-L. Yang, R. E. Dickinson, L. E. Gulden, and H. Su (2007),\nDevelopment of a simple groundwater model for use in climate models and\nevaluation with Gravity Recovery and Climate Experiment data, J.\nGeophys. Res., 112, D07103, doi:10.1029/2006JD007522.\n\nOgden, F.L., 1997: CASC2D Reference Manual. Dept. of Civil and\nEvniron. Eng. U-37, U. Connecticut, 106 pp.\n\nPan, H.-L. and L. Mahrt, 1987: Interaction between soil hydrology\nand boundary-layer development, Bound.-Layer Meteorol., 38, 185-202.\n\nSkamarock, W. C., J. B. Klemp, J. Dudhia, D. O. Gill, D. M.\nBarker, W. Wang, and J. G. Powers, 2005: A Description of the Advanced\nResearch WRF Version 2. NCAR Technical Note NCAR/TN-468+STR,\ndoi:10.5065/D6DZ069T.\n\nVionnet, V., Brun, E., Morin, S., Boone, A., Faroux, S., Le Moigne, P., Martin,\nE., and Willemet, J.-M.: The detailed snowpack scheme Crocus and its\nimplementation in SURFEX v7.2, Geosci. Model Dev., 5, 773-791,\nhttps://doi.org/10.5194/gmd-5-773- 2012, 2012.\n\nWigmosta, M.S. L.W. Vail and D.P. Lettenmaier, 1994: A\ndistributed hydrology-vegetation model for complex terrain. Water\nResour. Res., 30(6), 1665-1679.\n\nWigmosta, M.S. and D.P. Lettenmaier, 1999: A comparison of\nsimplified methods for routing topographically driven subsurface flow.\nWater Resour. Res., 35(1), 255-264.\n\nWood, E.F., D.P. Lettenmaier, X. Kian, D. Lohmann, A. Boone, S.\nChang, F.Chen, Y. Dai, R.E. Dickinson, Q. Duan, M. Ek, Y.M. Gusev, F.\nHabets, P. Irannejad, R. Koster, K.E. Mitchell, O.N. Nasonova, J.\nNoilhan, J. Schaake, A. Schlosser, Y. Shao, A.B. Shmakin, D. Verseghy,\nK. Warrach, P. Wetzel, Y. Xue, Z.-L. Yang, and Q.-C. Zeng, 1998: The\nproject for intercomparison of land-surface parameterization schemes\n(PILPS) phase 2(c) Red-Arkansas river basin experiment: 1. Experiment\ndescription and summary intercomparisons, Global Planet. Change, 19,\n115-135.\n\nYang, Z.-L., and G.-Y. Niu (2003), The versatile integrator of surface\nand atmosphere processes (VISA) part I: Model description, Global\nPlanet. Change, 38, 175–189, doi:10.1016/S0921-8181(03)00028-6.\n\nESMF (Earth System Modeling Framework)\nhttps://www.earthsystemcog.org/projects/esmf/\n\nUSGS Global Land Cover Characterization\nhttps://www.usgs.gov/centers/eros/science/usgs-eros-archive-landcover-products-global-land-cover-characterization-glcc-0?qt-science_center_objects=0#qt-science_center_objectsTableLegend:Appendix3\nhttps://edcftp.cr.usgs.gov/project/glcc/globdoc2_0.html#app3\n\nIGBP_MODIS_BU+tundra Landcover Class Legend\n\nftp://ftp.emc.ncep.noaa.gov/mmb/gcp/ldas/noahlsm/README\n\nNCL (NCAR Command Language) https://www.ncl.ucar.edu/\n\nCDO (Climate Data Operators) https://code.mpimet.mpg.de/projects/cdo/\n" }, { "path": "src/.nwm_version", "content": "v3.1\n" }, { "path": "src/.version", "content": "v5.4.0\n" }, { "path": "src/CMakeLists.txt", "content": "if(${PROJECT_NAME} STREQUAL \"WRF\")\n # additions that WRF-Hydro's top CMakeLists.txt handles\n add_compile_options( \"${PROJECT_COMPILE_OPTIONS}\" )\n add_compile_definitions( \"${PROJECT_COMPILE_DEFINITIONS}\" )\n set(CMAKE_Fortran_MODULE_DIRECTORY ${PROJECT_BINARY_DIR}/hydro/mods)\n add_definitions(-DMPP_LAND)\n if (WRF_HYDRO_NUDGING STREQUAL \"1\")\n add_definitions(-DWRF_HYDRO_NUDGING=1)\n endif()\nendif()\n\n\n# build the various sup-projects\nadd_subdirectory(\"MPP\")\nadd_subdirectory(\"utils\")\nadd_subdirectory(\"IO\")\nadd_subdirectory(\"OrchestratorLayer\")\nadd_subdirectory(\"Debug_Utilities\")\nadd_subdirectory(\"Routing/Overland\")\nadd_subdirectory(\"Routing/Subsurface\")\nadd_subdirectory(\"Routing/Reservoirs\")\nadd_subdirectory(\"Routing/Diversions\")\nadd_subdirectory(\"Data_Rec\")\nadd_subdirectory(\"Routing\")\nadd_subdirectory(\"HYDRO_drv\")\nif(${PROJECT_NAME} STREQUAL \"WRF\")\n add_subdirectory(\"CPL/WRF_cpl\")\nendif()\n\nif (WRF_HYDRO_NUDGING_IO STREQUAL \"1\" OR\n WRF_HYDRO_NUDGING STREQUAL \"1\")\n add_subdirectory(\"nudging/io\")\n add_dependencies(hydro_routing hydro_nudging_io)\nendif()\n\nif (WRF_HYDRO_NUDGING STREQUAL \"1\")\n add_subdirectory(\"nudging\")\n add_dependencies(hydro_routing hydro_nudging)\n add_dependencies(hydro_driver hydro_nudging)\nendif()\n\nif (WRF_HYDRO_NUOPC STREQUAL \"1\")\n add_subdirectory(\"CPL/NUOPC_cpl\")\nendif()\n\n# add module dependencies\nadd_dependencies(hydro_debug_utils hydro_mpp)\nadd_dependencies(hydro_utils hydro_mpp)\nadd_dependencies(hydro_orchestrator hydro_netcdf_layer)\n\nadd_dependencies(hydro_routing\n hydro_mpp\n hydro_routing_overland\n hydro_routing_subsurface\n hydro_routing_reservoirs\n hydro_routing_reservoirs_levelpool\n hydro_routing_reservoirs_hybrid\n hydro_utils\n)\n\nadd_dependencies(hydro_routing_reservoirs_hybrid hydro_routing_reservoirs_levelpool)\nadd_dependencies(hydro_routing_overland hydro_mpp)\n\n# currently unused Routing/Groundwater directory\n# add_subdirectory(\"Routing/Groundwater\")\n# add_dependencies(hydro_routing\n# hydro_routing_groundwater\n# hydro_routing_groundwater_bucket\n# hydro_routing_groundwater_nhd\n# hydro_routing_groundwater_simple\n# )\n# add_dependencies(hydro_routing_groundwater hydro_mpp)\n# add_dependencies(hydro_routing_groundwater_bucket hydro_routing_groundwater)\n# add_dependencies(hydro_routing_groundwater_simple\n# hydro_routing_groundwater\n# hydro_routing_groundwater_bucket\n# )\n# add_dependencies(hydro_routing_groundwater_nhd\n# hydro_routing_groundwater\n# hydro_routing_groundwater_bucket\n# )\n\nadd_dependencies(hydro_driver\n hydro_routing\n hydro_debug_utils\n)\n\nadd_dependencies(hydro_data_rec\n hydro_routing_overland\n hydro_routing_subsurface\n hydro_routing_reservoirs\n)\n\nif (HYDRO_LSM MATCHES \"NoahMP\")\n message(\"-- Building NoahMP LSM\")\n add_subdirectory(\"Land_models/NoahMP\")\n\n add_subdirectory(\"CPL/NoahMP_cpl\")\n add_dependencies(hydro_noahmp_cpl hydro_routing)\n add_dependencies(hydro_noahmp_cpl hydro_mpp )\n add_dependencies(hydro_noahmp_cpl hydro_driver )\n\n add_executable(wrfhydro\n Land_models/NoahMP/IO_code/main_hrldas_driver.F\n Land_models/NoahMP/IO_code/module_hrldas_netcdf_io.F\n Land_models/NoahMP/IO_code/module_NoahMP_hrldas_driver.F\n )\n\n target_include_directories(wrfhydro BEFORE PUBLIC ${PROJECT_BINARY_DIR}/mods)\n\n target_link_libraries(wrfhydro\n hydro_utils\n hydro_mpp\n hydro_debug_utils\n hydro_routing_overland\n hydro_routing_subsurface\n hydro_data_rec\n hydro_routing\n hydro_routing_reservoirs_levelpool\n hydro_routing_reservoirs_hybrid\n hydro_routing_reservoirs_rfc\n hydro_routing_reservoirs\n hydro_driver\n noahmp_util\n noahmp_phys\n noahmp_data\n hydro_noahmp_cpl\n ${NETCDF_LIBRARIES}\n # hydro_routing_groundwater\n # hydro_routing_groundwater_bucket\n # hydro_routing_groundwater_nhd\n # hydro_routing_groundwater_simple\n )\n\n if (WRF_HYDRO_NUDGING_IO STREQUAL \"1\")\n target_link_libraries(wrfhydro hydro_nudging_io)\n add_dependencies(wrfhydro hydro_nudging_io)\n endif()\n\n if (WRF_HYDRO_NUDGING STREQUAL \"1\")\n target_link_libraries(wrfhydro hydro_nudging)\n target_link_libraries(wrfhydro hydro_routing_diversions)\n add_dependencies(wrfhydro hydro_nudging)\n add_dependencies(wrfhydro hydro_routing_diversions)\n endif()\n\n # bash commands to copy namelists to the Run directory\n set(BASH_CP_HRLDAS_NML \"if [[ ! -f ${CMAKE_BINARY_DIR}/Run/namelist.hrldas ]]\\; then cp ${PROJECT_SOURCE_DIR}/src/template/NoahMP/namelist.hrldas ${CMAKE_BINARY_DIR}/Run \\; fi\\;\")\n set(BASH_CP_HYDRO_NML \"if [[ ! -f ${CMAKE_BINARY_DIR}/Run/hydro.namelist ]]\\; then cp ${PROJECT_SOURCE_DIR}/src/template/HYDRO/hydro.namelist ${CMAKE_BINARY_DIR}/Run \\; fi\\;\")\n\n add_custom_command(TARGET wrfhydro POST_BUILD\n COMMAND mkdir -p ${CMAKE_BINARY_DIR}/Run\n COMMAND cp ${PROJECT_SOURCE_DIR}/tests/ctests/run_dir_makefile.mk ${CMAKE_BINARY_DIR}/Run/Makefile\n # copy tables\n COMMAND cp ${PROJECT_SOURCE_DIR}/src/template/HYDRO/CHANPARM.TBL ${CMAKE_BINARY_DIR}/Run\n COMMAND cp ${PROJECT_SOURCE_DIR}/src/template/HYDRO/HYDRO.TBL ${CMAKE_BINARY_DIR}/Run\n COMMAND cp ${PROJECT_SOURCE_DIR}/src/Land_models/NoahMP/run/*.TBL ${CMAKE_BINARY_DIR}/Run\n # copy namelists\n COMMAND bash -c \"${BASH_CP_HRLDAS_NML}\"\n COMMAND bash -c \"${BASH_CP_HYDRO_NML}\"\n # copy and setup executables\n COMMAND rm -f ${CMAKE_BINARY_DIR}/Run/wrf_hydro\n COMMAND rm -f ${CMAKE_BINARY_DIR}/Run/wrf_hydro_NoahMP\n COMMAND cp ${PROJECT_BINARY_DIR}/src/wrfhydro ${CMAKE_BINARY_DIR}/Run/wrf_hydro\n COMMAND ln -sf ${CMAKE_BINARY_DIR}/Run/wrf_hydro ${CMAKE_BINARY_DIR}/Run/wrf_hydro_NoahMP\n COMMAND rm ${PROJECT_BINARY_DIR}/src/wrfhydro\n )\n if(WRF_HYDRO_CREATE_EXE_SYMLINK)\n add_custom_command(TARGET wrfhydro POST_BUILD\n COMMAND ${CMAKE_COMMAND} -E create_symlink ${CMAKE_BINARY_DIR}/Run/wrf_hydro ${CMAKE_BINARY_DIR}/Run/wrf_hydro.exe\n )\n endif()\n\nelseif (HYDRO_LSM MATCHES \"Noah\")\n message(\"-- Building Noah LSM\")\n add_subdirectory(\"Land_models/Noah\")\n add_subdirectory(\"CPL/Noah_cpl\")\n\n add_dependencies(hydro_noah_cpl hydro_routing)\n add_dependencies(hydro_noah_cpl hydro_mpp )\n add_dependencies(hydro_noah_cpl hydro_driver )\n\n add_executable(wrfhydro\n Land_models/Noah/IO_code/module_hrldas_netcdf_io.F\n Land_models/Noah/IO_code/Noah_hrldas_driver.F\n )\n\n target_include_directories(wrfhydro BEFORE PUBLIC ${PROJECT_BINARY_DIR}/mods)\n\n target_link_libraries(wrfhydro\n hydro_utils\n hydro_mpp\n hydro_debug_utils\n hydro_routing_overland\n hydro_routing_subsurface\n hydro_data_rec\n hydro_routing\n hydro_driver\n hydro_routing_reservoirs_levelpool\n hydro_routing_reservoirs_hybrid\n hydro_routing_reservoirs_rfc\n hydro_routing_reservoirs\n noah_util\n noah\n hydro_noah_cpl\n ${NETCDF_LIBRARIES}\n ${MPI_Fortran_LIBRARIES}\n # hydro_routing_groundwater\n # hydro_routing_groundwater_bucket\n # hydro_routing_groundwater_nhd\n # hydro_routing_groundwater_simple\n )\n\n if (WRF_HYDRO_NUDGING STREQUAL \"1\")\n target_link_libraries(wrfhydro hydro_nudging)\n add_dependencies(wrfhydro hydro_nudging)\n endif()\n\n add_custom_command(TARGET wrfhydro POST_BUILD\n COMMAND mkdir -p ${CMAKE_BINARY_DIR}/Run\n COMMAND rm -f ${CMAKE_BINARY_DIR}/Run/*\n COMMAND cp ${PROJECT_BINARY_DIR}/src/wrfhydro ${CMAKE_BINARY_DIR}/Run/wrf_hydro_Noah\n COMMAND cp ${PROJECT_SOURCE_DIR}/src/template/Noah/* ${CMAKE_BINARY_DIR}/Run\n COMMAND cp ${PROJECT_SOURCE_DIR}/src/template/HYDRO/CHANPARM.TBL ${CMAKE_BINARY_DIR}/Run\n COMMAND cp ${PROJECT_SOURCE_DIR}/src/template/HYDRO/hydro.namelist ${CMAKE_BINARY_DIR}/Run\n COMMAND cp ${PROJECT_SOURCE_DIR}/src/template/HYDRO/HYDRO.TBL ${CMAKE_BINARY_DIR}/Run\n COMMAND cp ${PROJECT_SOURCE_DIR}/src/Land_models/Noah/Run/*.TBL ${CMAKE_BINARY_DIR}/Run\n COMMAND ln -sf ${CMAKE_BINARY_DIR}/Run/wrf_hydro_Noah ${CMAKE_BINARY_DIR}/Run/wrf_hydro\n COMMAND ln -sf ${CMAKE_BINARY_DIR}/Run/wrf_hydro_Noah ${CMAKE_BINARY_DIR}/Run/wrf_hydro.exe\n COMMAND rm ${PROJECT_BINARY_DIR}/src/wrfhydro\n )\n\nelseif(${PROJECT_NAME} STREQUAL \"WRF\")\n add_library(wrfhydro INTERFACE)\n target_link_libraries(wrfhydro INTERFACE\n hydro_utils\n hydro_mpp\n hydro_debug_utils\n hydro_routing_overland\n hydro_routing_subsurface\n hydro_data_rec\n hydro_routing\n hydro_routing_reservoirs_levelpool\n hydro_routing_reservoirs_hybrid\n hydro_routing_reservoirs_rfc\n hydro_routing_reservoirs\n hydro_wrf_cpl\n hydro_orchestrator\n hydro_netcdf_layer\n hydro_driver\n )\nelse()\n message(\"Unknown land surface model:\" ${HYDRO_LSM} )\nendif()\n" }, { "path": "src/CPL/CLM_cpl/Makefile", "content": "# Makefile \n#\n.SUFFIXES:\n.SUFFIXES: .o .F\n\nCLMOBJPATH = /d1/weiyu/scratch/merra_boulder\n\nCLM_MOD = -I $(CLMOBJPATH)/lnd/obj -I $(CLMOBJPATH)/lib/include\n\ninclude ../../macros\n\nMODFLAG = -I./ -I ../../MPP -I ../../mod\n\nOBJS = \\\n\tmodule_clm_HYDRO.o \\\n\tclm_drv_HYDRO.o \nall:\t$(OBJS) \n\n.F.o:\n\t@echo \"\"\n\t$(COMPILER90) $(CPPINVOKE) $(CPPFLAGS) -I$(NETCDFINC) -o $(@) $(F90FLAGS) $(MODFLAG) -I ../../mod $(CLM_MOD) $(*).F\n\t@echo \"\"\n\tar -r ../../lib/libHYDRO.a $(@)\n\n#\n# Dependencies:\n#\n\nclean:\n\trm -f *.o *.mod *.stb *~ \n\tcd ../..; make -f Makefile.comm clean\n" }, { "path": "src/CPL/CLM_cpl/Makefile.cpl", "content": "# Makefile \n\nall:\n\t(cd ../../; make -f Makefile.comm)\n\t(make)\n\nclean:\n\t(cd ../../; make -f Makefile.comm clean)\n" }, { "path": "src/CPL/CLM_cpl/bat2.csh", "content": "#!/bin/csh -f\nmake -f Makefile.cpl\n\nrm -f /d1/weiyu/scratch/merra_boulder/run/ccsm.exe\ncd /d1/weiyu/scratch/merra_boulder/ccsm/obj\n\nmpif90 -o /d1/weiyu/scratch/merra_boulder/run/ccsm.exe ccsm_comp_mod.o ccsm_driver.o map_atmatm_mct.o map_atmice_mct.o map_atmlnd_mct.o map_atmocn_mct.o map_glcglc_mct.o map_iceice_mct.o map_iceocn_mct.o map_lndlnd_mct.o map_ocnocn_mct.o map_rofocn_mct.o map_rofrof_mct.o map_snoglc_mct.o map_snosno_mct.o mrg_x2a_mct.o mrg_x2g_mct.o mrg_x2i_mct.o mrg_x2l_mct.o mrg_x2o_mct.o mrg_x2s_mct.o seq_avdata_mod.o seq_diag_mct.o seq_domain_mct.o seq_flux_mct.o seq_frac_mct.o seq_hist_mod.o seq_rearr_mod.o seq_rest_mod.o -L/d1/weiyu/scratch/merra_boulder/lib -latm -llnd -lice -locn -lglc -L/d1/weiyu/scratch/merra_boulder/lib -lcsm_share -lmct -lmpeu -lpio -L/home/weiyu/netcdf/lib -lnetcdf -lnetcdff -L /raid/weiyu/LIS_trunk2/p61_NDHMS/routing/ndhms_wrf_hydro/src/lib -lHYDRO\n" }, { "path": "src/CPL/CLM_cpl/cesm_cpl_compiling.csh", "content": "#!/bin/csh -f\ncd /raid/weiyu/scratch/clm4_ndhms/ccsm/obj\n\nmpif90 -o /d1/weiyu/scratch/clm4_ndhms/run/ccsm.exe ccsm_comp_mod.o ccsm_driver.o map_atmatm_mct.o map_atmice_mct.o map_atmlnd_mct.o map_atmocn_mct.o map_glcglc_mct.o map_iceice_mct.o map_iceocn_mct.o map_lndlnd_mct.o map_ocnocn_mct.o map_rofocn_mct.o map_rofrof_mct.o map_snoglc_mct.o map_snosno_mct.o mrg_x2a_mct.o mrg_x2g_mct.o mrg_x2i_mct.o mrg_x2l_mct.o mrg_x2o_mct.o mrg_x2s_mct.o seq_avdata_mod.o seq_diag_mct.o seq_domain_mct.o seq_flux_mct.o seq_frac_mct.o seq_hist_mod.o seq_rearr_mod.o seq_rest_mod.o -L/d1/weiyu/scratch/clm4_ndhms/lib -latm -llnd -lice -locn -lglc -L/d1/weiyu/scratch/clm4_ndhms/lib -lcsm_share -lmct -lmpeu -lpio -L/home/weiyu/netcdf/lib -lnetcdf -lnetcdff -L /d1/weiyu/LISv6.1/src/routing/NCAR_router/lib -lland -lNDHMS\n" }, { "path": "src/CPL/CLM_cpl/clm_drv_HYDRO.F", "content": "subroutine clm_drv_HYDRO()\n use module_clm_HYDRO, only: clm_cpl_HYDRO\n implicit none\n call clm_cpl_HYDRO()\nend subroutine clm_drv_HYDRO\n" }, { "path": "src/CPL/CLM_cpl/module_clm_HYDRO.F", "content": "\nmodule module_CLM_HYDRO\n use domainMod , only : ldomain\n use clmtype , only : clm3\n use clm_varpar , only : nlevgrnd\n use decompMod , only : get_proc_bounds, get_proc_global\n use clm_varcon , only : zsoi\n use subgridAveMod, only: l2g_1d\n use subgridAveMod, only: c2g_1d, c2g_2d\n\n\n! NDHMS module\n use module_mpp_land, only: global_nx, global_ny, decompose_data_real, &\n write_io_real, my_id\n use module_hydro_stop, only: HYDRO_stop\n use module_HYDRO_drv, only: HYDRO_ini, HYDRO_exe\n\n implicit none\n integer begg, endg\n integer :: numg, numl, numc, nump\n INTEGER, PARAMETER :: double=8\n real(kind=double), pointer :: r2p(:,:) , r1p(:)\n\n integer :: begl, endl, begc, endc, begp, endp\n real(kind=double), allocatable, dimension(:) :: clm_g1d\n real(kind=double), allocatable, dimension(:,:) :: clm_g2d\n\n real, allocatable, dimension(:,:) :: vg_test\n\n\n\nCONTAINS\n\n subroutine clm_cpl_HYDRO()\n\n use module_rt_data, only: rt_domain\n use module_CPL_LAND, only: CPL_LAND_INIT, cpl_outdate\n use module_mpp_land\n use config_base, only: nlst\n\n implicit none\n integer k, ix,jx, nn\n\n integer :: did\n\n integer ntime, wrf_ix,wrf_jx\n real cpl_land_dt\n\n integer :: i,j\n integer clm_lev\n\n!output flux and state variable\n\n did = 1\n\n call get_cpl_date(cpl_land_dt)\n\n#ifdef HYDRO_D\n write(6,*) \"cpl_land_dt = \",cpl_land_dt\n#endif\n\n ntime = 1\n\n if(.not. RT_DOMAIN(did)%initialized) then\n\n\n\n\n call HYDRO_ini(ntime,did,1,1)\n\n if(nlst(did)%sys_cpl .ne. 4) then\n write(6,*) \"FATAL ERROR: sys_cpl should be 4.\"\n call hydro_stop(\"In module_clm_HYDRO.F clm_cpl_HYDRO() - \"// &\n \"sys_cpl should be 4. Check hydro.namelist file\")\n endif\n\n RT_DOMAIN(did)%initialized = .true.\n nlst(did)%dt = cpl_land_dt\n nlst(did)%startdate(1:19) = cpl_outdate(1:19)\n nlst(did)%olddate(1:19) = cpl_outdate(1:19)\n endif\n\n if(nlst(did)%rtFlag .eq. 0) return\n\n ix = rt_domain(did)%ix\n jx = rt_domain(did)%jx\n\n ! get the initial data from CLM\n call get_proc_global(numg, numl, numc, nump)\n\n call get_proc_bounds(begg, endg, begl, endl, begc, endc, begp, endp)\n#ifdef HYDRO_D\n write(6,*) \"begg, endg, \", begg, endg\n write(6,*) \"begl, endl, \", begl, endl\n write(6,*) \"begc, endc, \", begc, endc\n write(6,*) \"begp, endp, \", begp, endp\n#endif\n\n! call get_proc_bounds( begg=begg, endg=endg )\n nn = endg - begg + 1\n\n allocate(clm_g1d(endg-begg + 1))\n allocate(clm_g2d(endg-begg+1, nlevgrnd) )\n\n\n\n\n\n r1p => clm3%g%l%c%cwf%qflx_surf\n call c2g_1d(begc, endc, begl, endl, begg, endg, r1p(begc:endc), clm_g1d, &\n 'urbanf', 'unity')\n call clm2ND2d(clm_g1d,nn,RT_DOMAIN(did)%INFXSRT,ix,jx)\n\n#ifdef HYDRO_D\n write(6,*) \"finish qflx_surf\"\n\n#endif\n\n r1p => clm3%g%l%c%cwf%qflx_drain\n call c2g_1d(begc, endc, begl, endl, begg, endg, r1p(begc:endc), clm_g1d, &\n 'urbanf', 'unity')\n call clm2ND2d(clm_g1d,nn,RT_DOMAIN(did)%SOLDRAIN,ix,jx)\n\n\n#ifdef HYDRO_D\n write(6,*) \"finish qflx_drain \"\n#endif\n r2p =>clm3%g%l%c%ces%t_soisno\n call c2g_2d(begc, endc, begl, endl, begg, endg, nlevgrnd, r2p(begc:endc,1:nlevgrnd), clm_g2d, &\n 'urbanh', 'unity')\n call clm2ND3d (clm_g2d,nn,nlevgrnd,zsoi(1:nlevgrnd), &\n ix,jx, nlst(did)%nsoil,abs(rt_domain(did)%subsurface%properties%zsoil(1:nlst(did)%nsoil)),&\n RT_DOMAIN(did)%STC)\n\n#ifdef HYDRO_D\n write(6,*) \"finish t_soisno \"\n#endif\n\n r2p => clm3%g%l%c%cws%h2osoi_vol\n call c2g_2d(begc, endc, begl, endl, begg, endg, nlevgrnd, r2p(begc:endc,1:nlevgrnd), clm_g2d, &\n 'urbanh', 'unity')\n call clm2ND3d (clm_g2d,nn,nlevgrnd,zsoi(1:nlevgrnd), &\n ix,jx, nlst(did)%nsoil,abs(rt_domain(did)%subsurface%properties%zsoil(1:nlst(did)%nsoil)),&\n RT_DOMAIN(did)%SMC)\n#ifdef HYDRO_D\n write(6,*) \"finish h2osoi_vol \"\n\n#endif\n\n r2p => clm3%g%l%c%cws%h2osoi_liq\n call c2g_2d(begc, endc, begl, endl, begg, endg, nlevgrnd, r2p(begc:endc,1:nlevgrnd), clm_g2d, &\n 'urbanh', 'unity')\n call clm2ND3d (clm_g2d, nn,nlevgrnd,zsoi(1:nlevgrnd), &\n ix,jx, nlst(did)%nsoil,abs(rt_domain(did)%subsurface%properties%zsoil(1:nlst(did)%nsoil)),&\n RT_DOMAIN(did)%SH2OX)\n RT_DOMAIN(did)%SH2OX = RT_DOMAIN(did)%SH2OX /1000.\n #ifdef HYDRO_D\n write(6,*) \"finish h2osoi_liq \"\n\n write(6,*) \"before call HYDRO_exe\"\n\n#endif\n\n\n call HYDRO_exe(did)\n\n#ifdef HYDRO_D\n write(6,*) \"after call HYDRO_exe\"\n\n#endif\n! add for update the CLM state variable.\n\n clm_lev = 10\n\n r2p =>clm3%g%l%c%ces%t_soisno\n call Toclm3d (clm_g2d,nn,clm_lev,zsoi(1:clm_lev), &\n ix,jx, nlst(did)%nsoil,abs(rt_domain(did)%subsurface%properties%zsoil(1:nlst(did)%nsoil)),&\n RT_DOMAIN(did)%STC)\n call g2c_2d(begc, endc, begl, endl, begg, endg,clm_lev,r2p(begc:endc,1:clm_lev), clm_g2d, &\n 'urbanh', 'unity')\n\n\n\n\n r2p => clm3%g%l%c%cws%h2osoi_vol\n call Toclm3d (clm_g2d,nn,clm_lev,zsoi(1:clm_lev), &\n ix,jx, nlst(did)%nsoil,abs(rt_domain(did)%subsurface%properties%zsoil(1:nlst(did)%nsoil)), &\n RT_DOMAIN(did)%SMC)\n call g2c_2d_tmp(begc, endc, begl, endl, begg, endg,clm_lev,r2p(begc:endc,1:clm_lev), clm_g2d, &\n 'urbanh', 'unity', 0.01, 10.)\n\n\n\n r2p => clm3%g%l%c%cws%h2osoi_liq\n call Toclm3d(clm_g2d,nn,clm_lev,zsoi(1:clm_lev), &\n ix,jx, nlst(did)%nsoil,abs(rt_domain(did)%subsurface%properties%zsoil(1:nlst(did)%nsoil)),&\n RT_DOMAIN(did)%SH2OX*1000)\n call g2c_2d_tmp(begc, endc, begl, endl, begg, endg,clm_lev,r2p(begc:endc,1:clm_lev), clm_g2d, &\n 'urbanh', 'unity',0.01, 10.)\n\n\n\n\n ! 2d variable\n ! t_soisno\n ! 3 d variable\n deallocate(clm_g1d)\n deallocate(clm_g2d)\n#ifdef HYDRO_D\n write(6,*) \"end of drive ndhms\"\n#endif\n\n end subroutine clm_cpl_HYDRO\n\n subroutine Toclm3d (v1d_out,nn,kk1,z1_in,ix,jx,kk2,z2,v2_in)\n implicit none\n integer :: nn,ix,jx, kk2, kk1\n integer :: k\n real:: v2_in(ix,jx,kk2)\n real:: v1(ix,jx,kk1)\n real, dimension(kk2) :: z2\n REAL (KIND=double),dimension(nn,kk1):: v1d_out\n REAL (KIND=double),dimension(kk1):: z1_in\n REAL ,dimension(kk1):: z1\n\n z1 = z1_in\n\n! v1 is the out from interp3D\n call Interp3D (z2,v2_in,kk2,z1,v1,ix,jx,kk1)\n\n\n\n do k = 1, kk1\n call Toclm2d(v1(:,:,k),ix,jx,v1d_out(:,k),nn)\n end do\n\n end subroutine Toclm3d\n\n subroutine Toclm2d(v1,ix,jx,v1d_out,nn)\n use module_mpp_land, only: my_id,IO_id,mpp_land_bcast_real\n implicit none\n integer ix,jx, nn\n real v1(ix,jx)\n REAL (KIND=double),dimension(nn) :: v1d_out\n real, dimension(global_nx*global_ny)::vg\n real, dimension(global_nx,global_ny)::vg2d\n\n\n call write_io_real(v1,vg2d)\n\n vg = 0.0\n if(my_id .eq. IO_id) then\n call TO1d(vg2d,vg,global_nx,global_ny)\n end if\n\n#ifdef HYDRO_D\n write(6,*) \"before scatter_1d_r\"\n\n#endif\n\n call scatter_1d_r(v1d_out,nn,vg,global_nx*global_ny)\n\n#ifdef HYDRO_D\n write(6,*) \"after scatter_1d_r\"\n\n#endif\n end subroutine Toclm2d\n\n subroutine TO1d(vg2d,v1d,nx,ny)\n implicit none\n integer nx,ny, n, i,j\n real vg2d(nx,ny)\n real v1d(nx*ny)\n do j = 1,ny\n do i = 1,nx\n n = (j-1)*nx + i\n v1d(n) = vg2d(i,j)\n enddo\n enddo\n end subroutine TO1d\n\n subroutine clm2ND3d (v1d_in,nn,kk1,z1_in,ix,jx,kk2,z2,vout)\n implicit none\n integer :: nn,kk1,ix,jx,kk2\n integer :: k\n real:: vout(ix,jx,kk2)\n real:: v1(ix,jx,kk1)\n real(kind=double),dimension(nn,kk1):: v1d_in\n real(kind=double), dimension(kk1) :: z1_in\n real, dimension(kk1) :: z1\n real, dimension(kk2) :: z2\n\n\n z1 = z1_in\n\n do k = 1, kk1\n call clm2ND2d(v1d_in(:,k),nn,v1(:,:,k),ix,jx)\n end do\n call Interp3D (z1(1:kk1),v1,kk1,z2(1:kk2),vout,ix,jx,kk2)\n\n end subroutine clm2ND3d\n\n subroutine clm2ND2d (v1d_in,nn,vout,ix,jx)\n use clmtype, only: grlnd\n use module_mpp_land, only: my_id,IO_id,mpp_land_bcast_real\n implicit none\n integer :: ix,jx,nn, n\n real vout(ix,jx)\n integer :: i,j,gni,gnj\n! ! real, allocatable, dimension(:) :: g1d\n real(kind=double), dimension(global_nx*global_ny) :: g1d\n real v2d_g(global_nx,global_ny)\n real(kind=double),dimension(nn) :: v1d_in\n\n\n gni = global_nx\n gnj = global_ny\n! gather 1d global array\n\n if(endg .gt. gni*gnj) then\n write(6,*) \"WARNING: endg > gni*gnj\", endg, gni*gnj\n ! need to stop\n endif\n call gather_1d_real(v1d_in,nn,g1d,gni*gnj)\n! transfer 1d to 2d\n\n if(my_id.eq.IO_id) then\n do j = 1,gnj\n do i = 1,gni\n n = (j-1)*gni + i\n v2d_g(i,j) = g1d(n)\n enddo\n enddo\n endif\n\n! if(my_id .eq. 0) then\n! call output_nc(v2d_g,gni,gnj, \"test\", \"test.nc\")\n! endif\n\n! domain decomposition\n call decompose_data_real(v2d_g,vout)\n\n end subroutine clm2ND2d\n\n subroutine Interp3D (z1,v1,kk1,z,vout,ix,jx,kk)\n! input: z1,v1,kk1,z,ix,jx,kk\n! output: vout\n! interpolate based on soil layer: z1 and z\n! z : soil layer of output variable.\n! z1: array of soil layers of input variable.\n implicit none\n integer:: i,j,k\n integer:: kk1, ix,jx,kk\n real :: z1(kk1), z(kk), v1(ix,jx,kk1),vout(ix,jx,kk)\n\n! write(6,*) \"k, kk1 \", k, kk1\n! write(6,*) \"z1(kk1), z(k) \", z1(kk1), z(k)\n\n do j = 1, jx\n do i = 1, ix\n do k = 1, kk\n! call interpLayer(abs(Z1),v1(i,j,1:kk1),kk1,abs( Z(k) ),vout(i,j,k))\n call interpLayer(Z1(1:kk1),v1(i,j,1:kk1),kk1,Z(k),vout(i,j,k))\n end do\n end do\n end do\n end subroutine Interp3D\n\n subroutine interpLayer(inZ,inV,inK,outZ,outV)\n implicit none\n integer:: k, k1, k2\n integer :: inK\n real:: inV(inK),inZ(inK)\n real:: outV, outZ, w1, w2\n\n if(outZ .le. inZ(1)) then\n if(inZ(2) .eq. inZ(1)) then\n write(6,*) \"FATAL ERROR: inZ(2)=inZ(1) \", inZ(2),inZ(1)\n !stop 99\n stop(\"In module_clm_HYDRO.F interpLayer() - inZ(2)=inZ(1)\")\n end if\n w1 = (inZ(2)-outZ)/(inZ(2)-inZ(1))\n w2 = (inZ(1)-outZ)/(inZ(2)-inZ(1))\n outV = inV(1)*w1-inV(2)*w2\n return\n elseif(outZ .ge. inZ(inK)) then\n if(inZ(inK-1) .eq. inZ(inK)) then\n write(6,*) \"FATAL ERROR: inZ(inK-1)=inZ(inK) \", inZ(inK-1),inZ(inK)\n !stop 99\n stop(\"FATAL ERROR: In module_clm_HYDRO.F interpLayer() - inZ(inK-1)=inZ(inK)\")\n end if\n w1 = (outZ-inZ(inK-1))/(inZ(inK)-inZ(inK-1))\n w2 = (outZ-inZ(inK)) /(inZ(inK)-inZ(inK-1))\n outV = inV(inK)*w1 -inV(inK-1)* w2\n return\n else\n do k = 2, inK\n if((inZ(k) .ge. outZ).and.(inZ(k-1) .le. outZ) ) then\n k1 = k-1\n k2 = k\n if(inZ(k1) .eq. inZ(k2)) then\n write(6,*) \"FATAL ERROR: inZ(k1)=inZ(k2) \", inZ(k1),inZ(k2)\n !stop 99\n stop(\"FATAL ERROR: In module_clm_HYDRO.F interpLayer()- inZ(k1)=inZ(k2)\")\n end if\n w1 = (outZ-inZ(k1))/(inZ(k2)-inZ(k1))\n w2 = (inZ(k2)-outZ)/(inZ(k2)-inZ(k1))\n outV = inV(k2)*w1 + inV(k1)*w2\n return\n end if\n end do\n endif\n end subroutine interpLayer\n\n subroutine get_cpl_date(cpl_land_dt)\n use clm_time_manager, only : get_step_size, get_curr_date\n use module_CPL_LAND, only: cpl_outdate\n implicit none\n integer :: yr, mo, da, hr, mn, ss , sec\n real :: cpl_land_dt\n integer cmdate\n\n cpl_land_dt = 1.0* get_step_size()\n\n call get_curr_date(yr, mo, da, sec)\n\n\n hr = sec/3600\n\n sec = mod(sec,3600)\n mn = sec/60\n\n ss = mod(sec,60)\n\n if(yr .lt. 1000) yr = 2000+yr\n write(cpl_outdate(1:4),'(I4)') yr\n\n if(mo .lt. 10 ) then\n write(cpl_outdate(5:7),'(\"-0\",I1)') mo\n else\n write(cpl_outdate(5:7),'(\"-\",I2)') mo\n endif\n\n if(da .lt. 10 ) then\n write(cpl_outdate(8:10),'(\"-0\",I1)') da\n else\n write(cpl_outdate(8:10),'(\"-\",I2)') da\n endif\n\n if(hr .lt. 10 ) then\n write(cpl_outdate(11:13),'(\"_0\",I1)') hr\n else\n write(cpl_outdate(11:13),'(\"_\",I2)') hr\n endif\n\n if(mn .lt. 10 ) then\n write(cpl_outdate(14:16),'(\":0\",I1)') mn\n else\n write(cpl_outdate(14:16),'(\":\",I2)') mn\n endif\n\n if(ss .lt. 10 ) then\n write(cpl_outdate(17:19),'(\":0\",I1)') ss\n else\n write(cpl_outdate(17:19),'(\":\",I2)') ss\n endif\n\n\n\n! write(cpl_outdate,'(I4,\"-\",I2,\"-\",I2,\"_\",I2,\":\",I2,\":\",I2)' ) &\n! yr, mo, da, hr, mn, ss\n\n#ifdef HYDRO_D\n write(6,*) \"cpl_outdate = \",cpl_outdate\n\n#endif\n end subroutine get_cpl_date\n\n! transfer the grid column to gridcell.\n subroutine g2c_1d(lbc, ubc, lbl, ubl, lbg, ubg, carr, garr, &\n c2l_scale_type, l2g_scale_type)\n!\n! !DESCRIPTION:\n! Perfrom subgrid-average from columns to gridcells.\n! Averaging is only done for points that are not equal to \"spval\".\n!\n! !ARGUMENTS:\n use clm_varcon, only : spval, isturb, icol_roof, icol_sunwall, icol_shadewall, &\n icol_road_perv, icol_road_imperv\n use clm_varctl, only : iulog\n\n\n implicit none\n integer , intent(in) :: lbc, ubc ! beginning and ending column indices\n integer , intent(in) :: lbl, ubl ! beginning and ending landunit indices\n integer , intent(in) :: lbg, ubg ! beginning and ending landunit indices\n real(kind=double), intent(out) :: carr(lbc:ubc) ! output column array\n real(kind=double), intent(in) :: garr(lbg:ubg) ! input gridcell array\n character(len=*), intent(in) :: c2l_scale_type ! scale factor type for averaging\n character(len=*), intent(in) :: l2g_scale_type ! scale factor type for averaging\n!\n! !REVISION HISTORY:\n! Created by Mariana Vertenstein 12/03\n!\n!\n! !LOCAL VARIABLES:\n!EOP\n integer :: ci,c,l,g,index ! indices\n integer :: max_col_per_gcell ! max columns per gridcell; on the fly\n logical :: found ! temporary for error check\n real(kind=double) :: scale_c2l(lbc:ubc) ! scale factor\n real(kind=double) :: scale_l2g(lbl:ubl) ! scale factor\n real(kind=double) :: sumwt(lbg:ubg) ! sum of weights\n real(kind=double), pointer :: wtgcell(:) ! weight of columns relative to gridcells\n integer , pointer :: clandunit(:) ! landunit of corresponding column\n integer , pointer :: cgridcell(:) ! gridcell of corresponding column\n integer , pointer :: ncolumns(:) ! number of columns in gridcell\n integer , pointer :: coli(:) ! initial column index in gridcell\n integer , pointer :: ctype(:) ! column type\n integer , pointer :: ltype(:) ! landunit type\n real(kind=double), pointer :: canyon_hwr(:) ! urban canyon height to width ratio\n integer :: gcount(lbg:ubg)\n!------------------------------------------------------------------------\n\n\n ctype => clm3%g%l%c%itype\n ltype => clm3%g%l%itype\n canyon_hwr => clm3%g%l%canyon_hwr\n wtgcell => clm3%g%l%c%wtgcell\n clandunit => clm3%g%l%c%landunit\n cgridcell => clm3%g%l%c%gridcell\n ncolumns => clm3%g%ncolumns\n coli => clm3%g%coli\n\n if (l2g_scale_type == 'unity') then\n do l = lbl,ubl\n scale_l2g(l) = 1.0\n end do\n end if\n\n if (c2l_scale_type == 'unity') then\n do c = lbc,ubc\n scale_c2l(c) = 1.0\n end do\n else if (c2l_scale_type == 'urbanf') then\n do c = lbc,ubc\n l = clandunit(c)\n if (ltype(l) == isturb) then\n if (ctype(c) == icol_sunwall) then\n scale_c2l(c) = 3.0 * canyon_hwr(l)\n else if (ctype(c) == icol_shadewall) then\n scale_c2l(c) = 3.0 * canyon_hwr(l)\n else if (ctype(c) == icol_road_perv .or. ctype(c) == icol_road_imperv) then\n scale_c2l(c) = 3.0\n else if (ctype(c) == icol_roof) then\n scale_c2l(c) = 1.0\n end if\n else\n scale_c2l(c) = 1.0\n end if\n end do\n else if (c2l_scale_type == 'urbans') then\n do c = lbc,ubc\n l = clandunit(c)\n if (ltype(l) == isturb) then\n if (ctype(c) == icol_sunwall) then\n scale_c2l(c) = (3.0 * canyon_hwr(l)) / (2.*canyon_hwr(l) + 1.)\n else if (ctype(c) == icol_shadewall) then\n scale_c2l(c) = (3.0 * canyon_hwr(l)) / (2.*canyon_hwr(l) + 1.)\n else if (ctype(c) == icol_road_perv .or. ctype(c) == icol_road_imperv) then\n scale_c2l(c) = 3.0 / (2.*canyon_hwr(l) + 1.)\n else if (ctype(c) == icol_roof) then\n scale_c2l(c) = 1.0\n end if\n else\n scale_c2l(c) = 1.0\n end if\n end do\n else if (c2l_scale_type == 'urbanh') then\n do c = lbc,ubc\n l = clandunit(c)\n if (ltype(l) == isturb) then\n if (ctype(c) == icol_sunwall) then\n scale_c2l(c) = spval\n else if (ctype(c) == icol_shadewall) then\n scale_c2l(c) = spval\n else if (ctype(c) == icol_road_perv .or. ctype(c) == icol_road_imperv) then\n scale_c2l(c) = spval\n else if (ctype(c) == icol_roof) then\n scale_c2l(c) = spval\n end if\n else\n scale_c2l(c) = 1.0\n end if\n end do\n end if\n\n sumwt(:) = 0.\n gcount(:) = 0\n do c = lbc,ubc\n if (carr(c) /= spval .and. scale_c2l(c) /= spval) then\n l = clandunit(c)\n g = cgridcell(c)\n if(wtgcell(c) .ne. 0) then\n carr(c) = garr(g)\n endif\n end if\n end do\n end subroutine g2c_1d\n\n subroutine gather_1d_real(l1d,lnn,g1d,gnn)\n use spmdGathScatMod\n use clmtype , only : grlnd, nameg\n\n implicit none\n integer lnn, gnn\n real(kind=double),dimension(lnn) :: l1d\n real(kind=double),dimension(gnn) :: g1d\n real(kind=double), pointer :: lp_yw(:), gp_yw(:)\n\n allocate(lp_yw(lnn) )\n allocate(gp_yw(gnn) )\n lp_yw = l1d\n\n\n call gather_data_to_master(lp_yw,gp_yw,grlnd)\n\n g1d = gp_yw\n deallocate(lp_yw)\n deallocate(gp_yw)\n end subroutine gather_1d_real\n\n subroutine scatter_1d_r(l1d,lnn,g1d,gnn)\n use spmdGathScatMod, only: scatter_1darray_real\n use clmtype , only : grlnd, nameg\n\n implicit none\n integer lnn, gnn\n real(kind=double),dimension(lnn) :: l1d\n real,dimension(gnn) :: g1d\n real(kind=double), pointer :: lp_yw(:), gp_yw(:)\n\n\n\n\n allocate(lp_yw(begg:endg) )\n allocate(gp_yw(gnn) )\n\n\n gp_yw(:) = g1d(:)\n\n\n! call scatter_data_from_master(lp, gp, grlnd)\n\n call scatter_1darray_real(lp_yw, gp_yw, grlnd)\n\n\n l1d = lp_yw(begg:endg)\n\n deallocate(lp_yw)\n deallocate(gp_yw)\n end subroutine scatter_1d_r\n\n subroutine output_nc(array,idim,jdim, var_name, file_name)\n implicit none\n#include \n integer idim,jdim\n real array(idim,jdim)\n integer dim(2)\n character(len=*) file_name,var_name\n integer iret,ncid,varid,idim_id,jdim_id\n integer i,j\n iret = nf_create(trim(file_name), 0, ncid)\n iret = nf_def_dim(ncid, \"idim\", idim,idim_id)\n iret = nf_def_dim(ncid, \"jdim\", jdim,jdim_id)\n dim(1)=idim_id\n dim(2)=jdim_id\n iret = nf_put_att_real(ncid, NF_GLOBAL, &\n \"missing_value\", NF_FLOAT, 1, -1.E33)\n\n iret = nf_def_var(ncid,var_name,NF_FLOAT,2,dim,varid)\n iret = nf_enddef(ncid)\n\n! output\n iret = nf_inq_varid(ncid,var_name,varid)\n iret = nf_put_var_real(ncid,varid,array)\n iret=nf_close(ncid)\n end subroutine output_nc\n\n subroutine g2c_2d(lbc, ubc, lbl, ubl, lbg, ubg, num2d, carr, garr, &\n c2l_scale_type, l2g_scale_type)\n!\n! !DESCRIPTION:\n! Perfrom subgrid-average from columns to gridcells.\n! Averaging is only done for points that are not equal to \"spval\".\n!\n use clm_varcon, only : spval, isturb, icol_roof, icol_sunwall, icol_shadewall, &\n icol_road_perv, icol_road_imperv\n use clm_varctl, only : iulog\n! !ARGUMENTS:\n implicit none\n integer , intent(in) :: lbc, ubc ! beginning and ending column indices\n integer , intent(in) :: lbl, ubl ! beginning and ending landunit indices\n integer , intent(in) :: lbg, ubg ! beginning and ending gridcell indices\n integer , intent(in) :: num2d ! size of second dimension\n real(kind=double), intent(inout) :: carr(lbc:ubc,num2d) ! input column array\n real(kind=double), intent(in) :: garr(lbg:ubg,num2d) ! output gridcell array\n character(len=*), intent(in) :: c2l_scale_type ! scale factor type for averaging\n character(len=*), intent(in) :: l2g_scale_type ! scale factor type for averaging\n\n real(kind=double) :: yw_r\n!\n! !REVISION HISTORY:\n! Created by Mariana Vertenstein 12/03\n!\n!\n! !LOCAL VARIABLES:\n!EOP\n integer :: j,ci,c,g,l,index ! indices\n integer :: max_col_per_gcell ! max columns per gridcell; on the fly\n logical :: found ! temporary for error check\n real(kind=double) :: scale_c2l(lbc:ubc) ! scale factor\n real(kind=double) :: scale_l2g(lbl:ubl) ! scale factor\n real(kind=double) :: sumwt(lbg:ubg) ! sum of weights\n real(kind=double), pointer :: wtgcell(:) ! weight of columns relative to gridcells\n integer , pointer :: clandunit(:) ! landunit of corresponding column\n integer , pointer :: cgridcell(:) ! gridcell of corresponding column\n integer , pointer :: ncolumns(:) ! number of columns in gridcell\n integer , pointer :: coli(:) ! initial column index in gridcell\n integer , pointer :: ctype(:) ! column type\n integer , pointer :: ltype(:) ! landunit type\n real(kind=double), pointer :: canyon_hwr(:) ! urban canyon height to width ratio\n real :: w_yw\n!------------------------------------------------------------------------\n\n ctype => clm3%g%l%c%itype\n ltype => clm3%g%l%itype\n canyon_hwr => clm3%g%l%canyon_hwr\n wtgcell => clm3%g%l%c%wtgcell\n clandunit => clm3%g%l%c%landunit\n cgridcell => clm3%g%l%c%gridcell\n ncolumns => clm3%g%ncolumns\n coli => clm3%g%coli\n\n if (l2g_scale_type == 'unity') then\n do l = lbl,ubl\n scale_l2g(l) = 1.0\n end do\n else\n write(iulog,*)'WARNING: In module_clm_HYDRO.F c2g_2d() - '// &\n 'scale type ',l2g_scale_type,' not supported'\n end if\n if (c2l_scale_type == 'unity') then\n do c = lbc,ubc\n scale_c2l(c) = 1.0\n end do\n else if (c2l_scale_type == 'urbanf') then\n do c = lbc,ubc\n l = clandunit(c)\n if (ltype(l) == isturb) then\n if (ctype(c) == icol_sunwall) then\n scale_c2l(c) = 3.0 * canyon_hwr(l)\n else if (ctype(c) == icol_shadewall) then\n scale_c2l(c) = 3.0 * canyon_hwr(l)\n else if (ctype(c) == icol_road_perv .or. ctype(c) == icol_road_imperv) then\n scale_c2l(c) = 3.0\n else if (ctype(c) == icol_roof) then\n scale_c2l(c) = 1.0\n end if\n else\n scale_c2l(c) = 1.0\n end if\n end do\n else if (c2l_scale_type == 'urbans') then\n do c = lbc,ubc\n l = clandunit(c)\n if (ltype(l) == isturb) then\n if (ctype(c) == icol_sunwall) then\n scale_c2l(c) = (3.0 * canyon_hwr(l)) / (2.*canyon_hwr(l) + 1.)\n else if (ctype(c) == icol_shadewall) then\n scale_c2l(c) = (3.0 * canyon_hwr(l)) / (2.*canyon_hwr(l) + 1.)\n else if (ctype(c) == icol_road_perv .or. ctype(c) == icol_road_imperv) then\n scale_c2l(c) = 3.0 / (2.*canyon_hwr(l) + 1.)\n else if (ctype(c) == icol_roof) then\n scale_c2l(c) = 1.0\n end if\n else\n scale_c2l(c) = 1.0\n end if\n end do\n else if (c2l_scale_type == 'urbanh') then\n do c = lbc,ubc\n l = clandunit(c)\n if (ltype(l) == isturb) then\n if (ctype(c) == icol_sunwall) then\n scale_c2l(c) = spval\n else if (ctype(c) == icol_shadewall) then\n scale_c2l(c) = spval\n else if (ctype(c) == icol_road_perv .or. ctype(c) == icol_road_imperv) then\n scale_c2l(c) = spval\n else if (ctype(c) == icol_roof) then\n scale_c2l(c) = spval\n end if\n else\n scale_c2l(c) = 1.0\n end if\n end do\n else\n write(iulog,*) 'WARNING: In module_clm_HYDRO.F c2g_2d()- '// &\n 'scale type ',c2l_scale_type,' not supported'\n end if\n\n do j = 1,num2d\n sumwt(:) = 0.\n do c = lbc,ubc\n if (wtgcell(c) /= 0) then\n if (carr(c,j) /= spval .and. scale_c2l(c) /= spval) then\n l = clandunit(c)\n g = cgridcell(c)\n sumwt(g) = sumwt(g) + wtgcell(c)\n end if\n end if\n end do\n do c = lbc,ubc\n if (wtgcell(c) /= 0) then\n if (carr(c,j) /= spval .and. scale_c2l(c) /= spval) then\n l = clandunit(c)\n g = cgridcell(c)\n !garr(g,j) = garr(g,j) + carr(c,j) * scale_c2l(c) * scale_l2g(l) * wtgcell(c)\n !w_yw = scale_c2l(c) * scale_l2g(l) * wtgcell(c)\n w_yw = scale_c2l(c) * scale_l2g(l)\n if(w_yw .ne. 0) then\n ! carr(c,j) = garr(g,j) / w_yw *sumwt(g)\n yw_r = garr(g,j) / w_yw\n if(abs(yw_r - carr(c,j)) .lt. 400 .and. yw_r .ne. 0 ) then\n carr(c,j) = garr(g,j) / w_yw\n endif\n endif\n end if\n end if\n end do\n end do\n\n end subroutine g2c_2d\n\n subroutine g2c_2d_tmp(lbc, ubc, lbl, ubl, lbg, ubg, num2d, carr, garr, &\n c2l_scale_type, l2g_scale_type, minv, maxv)\n!\n! !DESCRIPTION:\n! Perfrom subgrid-average from columns to gridcells.\n! Averaging is only done for points that are not equal to \"spval\".\n!\n use clm_varcon, only : spval, isturb, icol_roof, icol_sunwall, icol_shadewall, &\n icol_road_perv, icol_road_imperv\n use clm_varctl, only : iulog\n! !ARGUMENTS:\n implicit none\n integer , intent(in) :: lbc, ubc ! beginning and ending column indices\n integer , intent(in) :: lbl, ubl ! beginning and ending landunit indices\n integer , intent(in) :: lbg, ubg ! beginning and ending gridcell indices\n integer , intent(in) :: num2d ! size of second dimension\n real(kind=double), intent(inout) :: carr(lbc:ubc,num2d) ! input column array\n real(kind=double), intent(in) :: garr(lbg:ubg,num2d) ! output gridcell array\n character(len=*), intent(in) :: c2l_scale_type ! scale factor type for averaging\n character(len=*), intent(in) :: l2g_scale_type ! scale factor type for averaging\n\n real(kind=double) :: yw_r\n real :: minv, maxv\n!\n! !REVISION HISTORY:\n! Created by Mariana Vertenstein 12/03\n!\n!\n! !LOCAL VARIABLES:\n!EOP\n integer :: j,ci,c,g,l,index ! indices\n integer :: max_col_per_gcell ! max columns per gridcell; on the fly\n logical :: found ! temporary for error check\n real(kind=double) :: scale_c2l(lbc:ubc) ! scale factor\n real(kind=double) :: scale_l2g(lbl:ubl) ! scale factor\n real(kind=double) :: sumwt(lbg:ubg) ! sum of weights\n real(kind=double), pointer :: wtgcell(:) ! weight of columns relative to gridcells\n integer , pointer :: clandunit(:) ! landunit of corresponding column\n integer , pointer :: cgridcell(:) ! gridcell of corresponding column\n integer , pointer :: ncolumns(:) ! number of columns in gridcell\n integer , pointer :: coli(:) ! initial column index in gridcell\n integer , pointer :: ctype(:) ! column type\n integer , pointer :: ltype(:) ! landunit type\n real(kind=double), pointer :: canyon_hwr(:) ! urban canyon height to width ratio\n real :: w_yw\n!------------------------------------------------------------------------\n\n ctype => clm3%g%l%c%itype\n ltype => clm3%g%l%itype\n canyon_hwr => clm3%g%l%canyon_hwr\n wtgcell => clm3%g%l%c%wtgcell\n clandunit => clm3%g%l%c%landunit\n cgridcell => clm3%g%l%c%gridcell\n ncolumns => clm3%g%ncolumns\n coli => clm3%g%coli\n\n if (l2g_scale_type == 'unity') then\n do l = lbl,ubl\n scale_l2g(l) = 1.0\n end do\n else\n write(iulog,*) 'WARNING: In module_clm_HYDRO.F g2c_2d_tmp - '// &\n 'scale type ',l2g_scale_type,' not supported'\n end if\n if (c2l_scale_type == 'unity') then\n do c = lbc,ubc\n scale_c2l(c) = 1.0\n end do\n else if (c2l_scale_type == 'urbanf') then\n do c = lbc,ubc\n l = clandunit(c)\n if (ltype(l) == isturb) then\n if (ctype(c) == icol_sunwall) then\n scale_c2l(c) = 3.0 * canyon_hwr(l)\n else if (ctype(c) == icol_shadewall) then\n scale_c2l(c) = 3.0 * canyon_hwr(l)\n else if (ctype(c) == icol_road_perv .or. ctype(c) == icol_road_imperv) then\n scale_c2l(c) = 3.0\n else if (ctype(c) == icol_roof) then\n scale_c2l(c) = 1.0\n end if\n else\n scale_c2l(c) = 1.0\n end if\n end do\n else if (c2l_scale_type == 'urbans') then\n do c = lbc,ubc\n l = clandunit(c)\n if (ltype(l) == isturb) then\n if (ctype(c) == icol_sunwall) then\n scale_c2l(c) = (3.0 * canyon_hwr(l)) / (2.*canyon_hwr(l) + 1.)\n else if (ctype(c) == icol_shadewall) then\n scale_c2l(c) = (3.0 * canyon_hwr(l)) / (2.*canyon_hwr(l) + 1.)\n else if (ctype(c) == icol_road_perv .or. ctype(c) == icol_road_imperv) then\n scale_c2l(c) = 3.0 / (2.*canyon_hwr(l) + 1.)\n else if (ctype(c) == icol_roof) then\n scale_c2l(c) = 1.0\n end if\n else\n scale_c2l(c) = 1.0\n end if\n end do\n else if (c2l_scale_type == 'urbanh') then\n do c = lbc,ubc\n l = clandunit(c)\n if (ltype(l) == isturb) then\n if (ctype(c) == icol_sunwall) then\n scale_c2l(c) = spval\n else if (ctype(c) == icol_shadewall) then\n scale_c2l(c) = spval\n else if (ctype(c) == icol_road_perv .or. ctype(c) == icol_road_imperv) then\n scale_c2l(c) = spval\n else if (ctype(c) == icol_roof) then\n scale_c2l(c) = spval\n end if\n else\n scale_c2l(c) = 1.0\n end if\n end do\n else\n write(iulog,*) 'WARNING: In module_clm_HYDRO.F g2c_2d_tmp() - '// &\n 'scale type ',c2l_scale_type,' not supported'\n end if\n\n do j = 1,num2d\n sumwt(:) = 0.\n do c = lbc,ubc\n if (wtgcell(c) /= 0) then\n if (carr(c,j) /= spval .and. scale_c2l(c) /= spval) then\n l = clandunit(c)\n g = cgridcell(c)\n sumwt(g) = sumwt(g) + wtgcell(c)\n end if\n end if\n end do\n do c = lbc,ubc\n if (wtgcell(c) /= 0) then\n if (carr(c,j) /= spval .and. scale_c2l(c) /= spval) then\n l = clandunit(c)\n g = cgridcell(c)\n !garr(g,j) = garr(g,j) + carr(c,j) * scale_c2l(c) * scale_l2g(l) * wtgcell(c)\n !w_yw = scale_c2l(c) * scale_l2g(l) * wtgcell(c)\n w_yw = scale_c2l(c) * scale_l2g(l)\n if(w_yw .ne. 0) then\n if(abs(garr(g,j)) .gt. minv .and. abs(garr(g,j)) .lt. maxv) then\n ! carr(c,j) = garr(g,j) / w_yw *sumwt(g)\n yw_r = garr(g,j) / w_yw\n if(yw_r .gt. 0) then\n carr(c,j) = garr(g,j) / w_yw\n endif\n endif\n endif\n end if\n end if\n end do\n end do\n\n end subroutine g2c_2d_tmp\nend module module_clm_HYDRO\n" }, { "path": "src/CPL/LIS_cpl/Makefile", "content": "# Makefile \n#\n\n.SUFFIXES:\n.SUFFIXES: .o .F\nLIS_ROOT = ../../../..\n\nLIS_MOD = -I ../../mod -I$(LIS_ROOT)/make\ninclude $(LIS_ROOT)/make/configure.lis\ninclude ../../macros\n\nMODFLAG = -I./ -I ../../MPP -I ../../mod\n\nOBJS = \\\n\tmodule_lis_HYDRO.o\\\n\tlis_drv_HYDRO.o\nall:\t$(OBJS) \n\n.F.o:\n\t@echo \"\"\n\t$(COMPILER90) $(CPPINVOKE) $(CPPFLAGS) -I$(NETCDFINC) -o $(@) $(F90FLAGS) $(MODFLAG) -I../../mod $(LIS_MOD) -I$(MOD_ESMF) $(*).F\n\t@echo \"\"\n\tar -r ../../lib/libHYDRO.a $(@)\n\n#\n# Dependencies:\n#\n\nclean:\n\trm -f *.o *.mod *.stb *~ \n" }, { "path": "src/CPL/LIS_cpl/Makefile.cpl", "content": "# Makefile \n\nall:\n\t(cd ../../; make -f Makefile.comm)\n\t(make)\n\nclean:\n\t(make clean)\n\t(cd ../../; make -f Makefile.comm clean)\n" }, { "path": "src/CPL/LIS_cpl/lis_drv_HYDRO.F", "content": "\n!2345678\n subroutine lis_drv_HYDRO(n)\n use module_lis_HYDRO, only: lis_cpl_HYDRO\n implicit none\n integer n\n#ifdef HYDRO_D\n write(6,*) \"calling lis_cpl_HYDRO \"\n#endif\n! stop 888\n call lis_cpl_HYDRO(n)\n end subroutine lis_drv_HYDRO\n" }, { "path": "src/CPL/LIS_cpl/module_lis_HYDRO.F", "content": "\nmodule module_lis_HYDRO\n use noah271_lsmMod, only : noah271_struc\n! use LIS_coreMod, only : LIS_rc, LIS_domain, LIS_masterproc, &\n! LIS_ews_ind, LIS_ewe_ind, LIS_nss_ind, LIS_nse_ind\n use LIS_coreMod\n! use LIS_historyMod, only: LIS_gather_gridded_output, lis_gather_tiled_vector_output\n\n! use HYDRO module\n use module_hydro_stop, only: HYDRO_stop\n use module_rt_data, only: rt_domain\n use module_CPL_LAND, only: CPL_LAND_INIT, cpl_outdate\n use module_mpp_land\n use config_base, only : nlst\n use module_HYDRO_drv, only: HYDRO_ini, HYDRO_exe\n\n!!! temp use\n use module_yw, only: SFHEAD1RT,INFXS1RT, soldrain\n contains\n\n subroutine lis_cpl_HYDRO(n)\n\n\n\n implicit none\n integer n, k, ix,jx\n\n integer :: did, its,ite,jts,jte, ierr\n\n integer ntime, wrf_ix,wrf_jx\n logical mpi_inited\n\n!output flux and state variable\n\n integer :: i,j, kz\n\n\n did = 1\n\n ntime = 1\n\n! write(6,*) \"yyyywww step 2, n =\", n\n! write(6,*) \"npesx, npesy\",LIS_rc%npesx, LIS_rc%npesy\n\n if(.not. RT_DOMAIN(did)%initialized) then\n\n!!! get soil layers from lis\n!!! ++++++++++++++\n nlst(did)%nsoil = noah271_struc(n)%nslay\n#ifdef MPP_LAND\n call mpp_land_bcast_int1(nlst(did)%nsoil)\n#endif\n if(nlst(did)%nsoil < 1) then\n write(6,*) \"FATAL ERROR: nsoil is less than 1\"\n call hydro_stop(\"In module_lis_HYDRO.F module_lis_HYDRO() - nsoil is less than 1\")\n endif\n allocate(nlst(did)%zsoil8(nlst(did)%nsoil))\n nlst(did)%zsoil8(1) = -noah271_struc(n)%lyrthk(1)\n DO KZ = 2,nlst(did)%nsoil\n nlst(did)%zsoil8(KZ) = -noah271_struc(n)%lyrthk(KZ)+nlst(did)%zsoil8(KZ-1)\n END DO\n!!! ----------\n#ifdef HYDRO_D\n write(6,*) \"zsoil8 = \",nlst(did)%zsoil8\n\n#endif\n\n call MPI_Initialized( mpi_inited, ierr )\n if ( .NOT. mpi_inited ) then\n call MPI_Init( ierr ) ! stand alone land model.\n if (ierr /= MPI_SUCCESS) stop \"MPI_INIT\"\n call MPI_Comm_dup(MPI_COMM_WORLD, HYDRO_COMM_WORLD, ierr)\n if (ierr /= MPI_SUCCESS) stop \"MPI_COMM_DUP\"\n endif\n call MPI_Comm_rank( HYDRO_COMM_WORLD, my_id, ierr )\n call MPI_Comm_size( HYDRO_COMM_WORLD, numprocs, ierr )\n endif\n\n if(nlst(did)%rtFlag .eq. 0) return\n\n write(cpl_outdate(1:5),'(I4,\"-\")') LIS_rc%yr\n\n if(LIS_rc%mo .lt. 10) then\n write(cpl_outdate(6:8),'(\"0\",I1,\"-\")') LIS_rc%mo\n else\n write(cpl_outdate(6:8),'(I2,\"-\")') LIS_rc%mo\n endif\n\n if(LIS_rc%da .lt. 10) then\n write(cpl_outdate(9:11),'(\"0\",I1,\"_\")') LIS_rc%da\n else\n write(cpl_outdate(9:11),'(I2,\"_\")') LIS_rc%da\n endif\n\n if(LIS_rc%hr .lt. 10) then\n write(cpl_outdate(12:14),'(\"0\",I1,\":\")') LIS_rc%hr\n else\n write(cpl_outdate(12:14),'(I2,\":\")') LIS_rc%hr\n endif\n\n if(LIS_rc%mn .lt. 10) then\n write(cpl_outdate(15:17),'(\"0\",I1,\":\")') LIS_rc%mn\n else\n write(cpl_outdate(15:17),'(I2,\":\")') LIS_rc%mn\n endif\n\n if(LIS_rc%ss .lt. 10) then\n write(cpl_outdate(18:19),'(\"0\",I1)') LIS_rc%ss\n else\n write(cpl_outdate(18:19),'(I2)') LIS_rc%ss\n endif\n\n\n nlst(did)%olddate(1:19) = cpl_outdate(1:19)\n\n\n jx = LIS_rc%lnr(n)\n ix = LIS_rc%lnc(n)\n its = LIS_ews_ind(LIS_rc%nnest,my_id+1)\n ite = LIS_ewe_ind(LIS_rc%nnest,my_id+1)\n jts = LIS_nss_ind(LIS_rc%nnest,my_id+1)\n jte = LIS_nse_ind(LIS_rc%nnest,my_id+1)\n\n! write(6,*) \"LIS_ews_ind\",LIS_ews_ind\n! write(6,*) \"LIS_ewe_ind\",LIS_ewe_ind\n! write(6,*) \"LIS_nss_ind\",LIS_nss_ind\n! write(6,*) \"LIS_nse_ind\",LIS_nse_ind\n\n if(.not. RT_DOMAIN(did)%initialized) then\n! write(6,*) \"yyyywww step 3\"\n#ifdef HYDRO_D\n write(6,*) \"ix,jx, cpl_land_dt\",ix,jx, LIS_rc%ts\n\n! write(6,*) \"yyyywww step 4 before HYDRO_ini= \"\n write(6,*) \"its,ite,jts,jte\", its,ite,jts,jte\n write(6,*) \"noah271_struc(n)%nslay=\", noah271_struc(n)%nslay\n write(6,*) \"noah271_struc(n)%lyrthk=\", noah271_struc(n)%lyrthk\n\n#endif\n nlst(did)%startdate(1:19) = cpl_outdate(1:19)\n\n call CPL_LAND_INIT(its,ite,jts,jte)\n\n\n! write(6,*) \"yyyywww step 4 before HYDRO_ini= \"\n! write(6,*) \"its,ite,jts,jte\", its,ite,jts,jte\n\n call HYDRO_ini(ntime,did=did,ix0=1,jx0=1)\n\n if(nlst(did)%sys_cpl .ne. 3) then\n write(6,*) \"FATAL ERROR: sys_cpl should be 3.\"\n call hydro_stop(\"In module_lis_HYDRO.F lis_cpl_HYDRO() - \"// &\n \"sys_cpl should be 3. Check hydro.namelist file\")\n endif\n! write(6,*) \"yyyywww step 5 my_id= \", my_id\n\n nlst(did)%dt = LIS_rc%ts\n\n! write(6,*) \"LIS_rc%gnc(n),LIS_rc%gnr(n),LIS_rc%glbnch_red(n)\", &\n! LIS_rc%gnc(n),LIS_rc%gnr(n),LIS_rc%glbnch_red(n)\n\n! write(6,*) \"LIS_rc%nch =\", LIS_rc%nch(n)\n! write(6,*) \"size(noah271_struc(n)%noah%cmc)\" , size(noah271_struc(n)%noah%cmc)\n\n! write(6,*) \"LIS_nss_halo_ind,LIS_nse_halo_ind\", LIS_nss_halo_ind,LIS_nse_halo_ind\n! write(6,*) \"LIS_ews_halo_ind,LIS_ewe_halo_ind\",LIS_ews_halo_ind,LIS_ewe_halo_ind\n\n! nlst(did)%startdate(1:19) = cpl_outdate(1:19)\n\n RT_DOMAIN(did)%initialized = .true.\n endif\n\n\n! write(6,*) \"before call lis2HYDRO\"\n\n! write(6,*) \"size(noah271_struc(n)%noah%smc(1)),n,ix,jx\" , size(noah271_struc(n)%noah%smc(1)),n,ix,jx\n! write(6,*) \"nlst(did)%nsoil = \", nlst(did)%nsoil\n\n ! get the initial data from LIS\n do k = 1 , nlst(did)%nsoil\n call lis2HYDRO(RT_DOMAIN(did)%SMC(:,:,k),noah271_struc(n)%noah%smc(k),size(noah271_struc(n)%noah%smc(k)),n,ix,jx)\n call lis2HYDRO(RT_DOMAIN(did)%stc(:,:,k),noah271_struc(n)%noah%stc(k),size(noah271_struc(n)%noah%stc(k)), n,ix,jx)\n call lis2HYDRO(RT_DOMAIN(did)%SH2OX(:,:,k),noah271_struc(n)%noah%sh2o(k),size(noah271_struc(n)%noah%sh2o(k)),n,ix,jx)\n enddo\n\n#ifdef HYDRO_D\n write(6,*) \"NDHMS lis date \", LIS_rc%yr, LIS_rc%mo, LIS_rc%da, LIS_rc%hr, LIS_rc%mn, LIS_rc%ss\n#endif\n! write(11,*) \"RT_DOMAIN(did)%stc\",RT_DOMAIN(did)%stc(:,:,1)\n! write(12,*) \"noah271_struc(n)%noah%stc(1)\",noah271_struc(n)%noah%stc(1)\n! call land_finish()\n\n call lis2HYDRO(RT_DOMAIN(did)%infxsrt(:,:),INFXS1RT,size(INFXS1RT),n,ix,jx)\n call lis2HYDRO(RT_DOMAIN(did)%soldrain(:,:),SOLDRAIN,size(SOLDRAIN),n,ix,jx)\n\n\n call HYDRO_exe(did)\n\n! add for update the land surface model state variable.\n ! 3 d variable\n do k = 1 , nlst(did)%nsoil\n call HYDRO2lis_2d(RT_DOMAIN(did)%SMC(:,:,k),noah271_struc(n)%noah%smc(k),size(noah271_struc(n)%noah%smc(k)),n,ix,jx)\n call HYDRO2lis_2d(RT_DOMAIN(did)%stc(:,:,k),noah271_struc(n)%noah%stc(k),size(noah271_struc(n)%noah%stc(k)),n,ix,jx)\n call HYDRO2lis_2d(RT_DOMAIN(did)%SH2OX(:,:,k),noah271_struc(n)%noah%sh2o(k),size(noah271_struc(n)%noah%sh2o(k)),n,ix,jx)\n end do\n\n call HYDRO2lis_2d(rt_domain(did)%overland%control%surface_water_head_lsm(:,:),SFHEAD1RT,size(SFHEAD1RT),n,ix,jx)\n\n return\n end subroutine lis_cpl_HYDRO\n\n subroutine HYDRO2lis_2d(var,v1d,size1,n,ix,jx)\n implicit none\n integer :: n, ix, jx, i, r,c, size1\n real, dimension(ix,jx) :: var\n real, dimension(jx,ix) :: tmpVar\n real :: v1d (size1)\n\n! call LIS_gather_gridded_output(n, p1,tmpVar)\n do r=1,jx\n do c=1,ix\n if(LIS_domain(n)%gindex(c,r).ne.-1) then\n v1d(LIS_domain(n)%gindex(c,r)) = var(c,r)\n endif\n enddo\n enddo\n\n end subroutine HYDRO2lis_2d\n\n subroutine lis2HYDRO(var,v1d,size1,n,ix,jx)\n implicit none\n integer n, ix,jx, r,c, size1\n real, dimension(ix,jx) :: var\n! real, dimension(jx,ix) :: tmpVar\n real :: v1d (size1)\n\n\n! do i = 1, ix\n! tmpVar(:,i) = Var(i,:)\n! end do\n! call LIS_gather_tiled_vector_output(n,v1d,tmpVar)\n\n do r=1,jx\n do c=1,ix\n if(LIS_domain(n)%gindex(c,r).ne.-1) then\n var(c,r) = v1d(LIS_domain(n)%gindex(c,r))\n endif\n enddo\n enddo\n\n end subroutine lis2HYDRO\n\nend module module_lis_HYDRO\n" }, { "path": "src/CPL/NUOPC_cpl/.gitignore", "content": "*.a\n*.mk\n*.mod\n*.o\nVERSION\n" }, { "path": "src/CPL/NUOPC_cpl/CMakeLists.txt", "content": "### Library Prerequisites\nif (NOT TARGET esmf)\n find_package(ESMF MODULE REQUIRED)\nendif (NOT TARGET esmf)\n\n### Library Files\nlist(APPEND wrfhydro_nuopc_files\n WRFHydro_NUOPC_Cap.F90\n WRFHydro_NUOPC_Gluecode.F90\n WRFHydro_NUOPC_Fields.F90\n WRFHydro_NUOPC_Flags.F90\n WRFHydro_ESMF_Extensions.F90\n)\n\n### Library Dependencies\nlist(APPEND wrfhydro_nuopc_deps\n hydro_routing\n hydro_mpp\n hydro_driver\n hydro_orchestrator\n)\n\nlist(APPEND wrfhydro_nuopc_linklibs\n hydro_utils\n hydro_mpp\n hydro_debug_utils\n hydro_routing_overland\n hydro_routing_subsurface\n hydro_data_rec\n hydro_routing\n hydro_routing_diversions\n fortglob\n hydro_routing_reservoirs_levelpool\n hydro_routing_reservoirs_hybrid\n hydro_routing_reservoirs_rfc\n hydro_routing_reservoirs\n hydro_driver\n hydro_orchestrator\n hydro_netcdf_layer\n)\nif (WRF_HYDRO_NUDGING STREQUAL \"1\")\n list(APPEND wrfhydro_nuopc_linklibs\n hydro_nudging\n )\nendif (WRF_HYDRO_NUDGING STREQUAL \"1\")\n\n\n### New Library: wrfhydro_nuopc\nadd_library(wrfhydro_nuopc STATIC ${wrfhydro_nuopc_files})\nadd_dependencies(wrfhydro_nuopc ${wrfhydro_nuopc_deps})\ntarget_link_libraries(wrfhydro_nuopc PUBLIC ${wrfhydro_nuopc_linklibs})\ntarget_link_libraries(wrfhydro_nuopc PUBLIC esmf)\ntarget_link_libraries(wrfhydro_nuopc PUBLIC ${NETCDF_LIBRARIES})\n\n### Library Installation\ninstall(TARGETS wrfhydro_nuopc ${wrfhydro_nuopc_linklibs}\n EXPORT wrfhydro-config\n LIBRARY DESTINATION lib\n)\ninstall(DIRECTORY ${CMAKE_Fortran_MODULE_DIRECTORY}\n DESTINATION ${CMAKE_INSTALL_PREFIX}/WRFHYDRO\n)\ninstall(EXPORT wrfhydro-config\n DESTINATION lib/cmake\n)\n\n" }, { "path": "src/CPL/NUOPC_cpl/Doxyfile", "content": "# Doxyfile 1.8.12\n\n# This file describes the settings to be used by the documentation system\n# doxygen (www.doxygen.org) for a project.\n#\n# All text after a double hash (##) is considered a comment and is placed in\n# front of the TAG it is preceding.\n#\n# All text after a single hash (#) is considered a comment and will be ignored.\n# The format is:\n# TAG = value [value, ...]\n# For lists, items can also be appended using:\n# TAG += value [value, ...]\n# Values that contain spaces should be placed between quotes (\\\" \\\").\n\n#---------------------------------------------------------------------------\n# Project related configuration options\n#---------------------------------------------------------------------------\n\n# This tag specifies the encoding used for all characters in the config file\n# that follow. The default is UTF-8 which is also the encoding used for all text\n# before the first occurrence of this tag. Doxygen uses libiconv (or the iconv\n# built into libc) for the transcoding. See http://www.gnu.org/software/libiconv\n# for the list of possible encodings.\n# The default value is: UTF-8.\n\nDOXYFILE_ENCODING = UTF-8\n\n# The PROJECT_NAME tag is a single word (or a sequence of words surrounded by\n# double-quotes, unless you are using Doxywizard) that should identify the\n# project for which the documentation is generated. This name is used in the\n# title of most generated pages and in a few other places.\n# The default value is: My Project.\n\nPROJECT_NAME = \"WRF-Hydro NUOPC Cap\"\n\n# The PROJECT_NUMBER tag can be used to enter a project or revision number. This\n# could be handy for archiving the generated documentation or if some version\n# control system is used.\n\nPROJECT_NUMBER =\n\n# Using the PROJECT_BRIEF tag one can provide an optional one line description\n# for a project that appears at the top of each page and should give viewer a\n# quick idea about the purpose of the project. Keep the description short.\n\nPROJECT_BRIEF =\n\n# With the PROJECT_LOGO tag one can specify a logo or an icon that is included\n# in the documentation. The maximum height of the logo should not exceed 55\n# pixels and the maximum width should not exceed 200 pixels. Doxygen will copy\n# the logo to the output directory.\n\nPROJECT_LOGO =\n\n# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path\n# into which the generated documentation will be written. If a relative path is\n# entered, it will be relative to the location where doxygen was started. If\n# left blank the current directory will be used.\n\nOUTPUT_DIRECTORY = docs\n\n# If the CREATE_SUBDIRS tag is set to YES then doxygen will create 4096 sub-\n# directories (in 2 levels) under the output directory of each output format and\n# will distribute the generated files over these directories. Enabling this\n# option can be useful when feeding doxygen a huge amount of source files, where\n# putting all generated files in the same directory would otherwise causes\n# performance problems for the file system.\n# The default value is: NO.\n\nCREATE_SUBDIRS = NO\n\n# If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII\n# characters to appear in the names of generated files. If set to NO, non-ASCII\n# characters will be escaped, for example _xE3_x81_x84 will be used for Unicode\n# U+3044.\n# The default value is: NO.\n\nALLOW_UNICODE_NAMES = NO\n\n# The OUTPUT_LANGUAGE tag is used to specify the language in which all\n# documentation generated by doxygen is written. Doxygen will use this\n# information to generate all constant output in the proper language.\n# Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Catalan, Chinese,\n# Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United States),\n# Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hungarian,\n# Indonesian, Italian, Japanese, Japanese-en (Japanese with English messages),\n# Korean, Korean-en (Korean with English messages), Latvian, Lithuanian,\n# Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, Romanian, Russian,\n# Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, Swedish, Turkish,\n# Ukrainian and Vietnamese.\n# The default value is: English.\n\nOUTPUT_LANGUAGE = English\n\n# If the BRIEF_MEMBER_DESC tag is set to YES, doxygen will include brief member\n# descriptions after the members that are listed in the file and class\n# documentation (similar to Javadoc). Set to NO to disable this.\n# The default value is: YES.\n\nBRIEF_MEMBER_DESC = YES\n\n# If the REPEAT_BRIEF tag is set to YES, doxygen will prepend the brief\n# description of a member or function before the detailed description\n#\n# Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the\n# brief descriptions will be completely suppressed.\n# The default value is: YES.\n\nREPEAT_BRIEF = YES\n\n# This tag implements a quasi-intelligent brief description abbreviator that is\n# used to form the text in various listings. Each string in this list, if found\n# as the leading text of the brief description, will be stripped from the text\n# and the result, after processing the whole list, is used as the annotated\n# text. Otherwise, the brief description is used as-is. If left blank, the\n# following values are used ($name is automatically replaced with the name of\n# the entity):The $name class, The $name widget, The $name file, is, provides,\n# specifies, contains, represents, a, an and the.\n\nABBREVIATE_BRIEF = \"The $name class\" \\\n \"The $name widget\" \\\n \"The $name file\" \\\n is \\\n provides \\\n specifies \\\n contains \\\n represents \\\n a \\\n an \\\n the\n\n# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then\n# doxygen will generate a detailed section even if there is only a brief\n# description.\n# The default value is: NO.\n\nALWAYS_DETAILED_SEC = NO\n\n# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all\n# inherited members of a class in the documentation of that class as if those\n# members were ordinary class members. Constructors, destructors and assignment\n# operators of the base classes will not be shown.\n# The default value is: NO.\n\nINLINE_INHERITED_MEMB = NO\n\n# If the FULL_PATH_NAMES tag is set to YES, doxygen will prepend the full path\n# before files name in the file list and in the header files. If set to NO the\n# shortest path that makes the file name unique will be used\n# The default value is: YES.\n\nFULL_PATH_NAMES = YES\n\n# The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path.\n# Stripping is only done if one of the specified strings matches the left-hand\n# part of the path. The tag can be used to show relative paths in the file list.\n# If left blank the directory from which doxygen is run is used as the path to\n# strip.\n#\n# Note that you can specify absolute paths here, but also relative paths, which\n# will be relative from the directory where doxygen is started.\n# This tag requires that the tag FULL_PATH_NAMES is set to YES.\n\nSTRIP_FROM_PATH =\n\n# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the\n# path mentioned in the documentation of a class, which tells the reader which\n# header file to include in order to use a class. If left blank only the name of\n# the header file containing the class definition is used. Otherwise one should\n# specify the list of include paths that are normally passed to the compiler\n# using the -I flag.\n\nSTRIP_FROM_INC_PATH =\n\n# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but\n# less readable) file names. This can be useful is your file systems doesn't\n# support long names like on DOS, Mac, or CD-ROM.\n# The default value is: NO.\n\nSHORT_NAMES = NO\n\n# If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the\n# first line (until the first dot) of a Javadoc-style comment as the brief\n# description. If set to NO, the Javadoc-style will behave just like regular Qt-\n# style comments (thus requiring an explicit @brief command for a brief\n# description.)\n# The default value is: NO.\n\nJAVADOC_AUTOBRIEF = NO\n\n# If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first\n# line (until the first dot) of a Qt-style comment as the brief description. If\n# set to NO, the Qt-style will behave just like regular Qt-style comments (thus\n# requiring an explicit \\brief command for a brief description.)\n# The default value is: NO.\n\nQT_AUTOBRIEF = NO\n\n# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen treat a\n# multi-line C++ special comment block (i.e. a block of //! or /// comments) as\n# a brief description. This used to be the default behavior. The new default is\n# to treat a multi-line C++ comment block as a detailed description. Set this\n# tag to YES if you prefer the old behavior instead.\n#\n# Note that setting this tag to YES also means that rational rose comments are\n# not recognized any more.\n# The default value is: NO.\n\nMULTILINE_CPP_IS_BRIEF = NO\n\n# If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the\n# documentation from any documented member that it re-implements.\n# The default value is: YES.\n\nINHERIT_DOCS = YES\n\n# If the SEPARATE_MEMBER_PAGES tag is set to YES then doxygen will produce a new\n# page for each member. If set to NO, the documentation of a member will be part\n# of the file/class/namespace that contains it.\n# The default value is: NO.\n\nSEPARATE_MEMBER_PAGES = NO\n\n# The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen\n# uses this value to replace tabs by spaces in code fragments.\n# Minimum value: 1, maximum value: 16, default value: 4.\n\nTAB_SIZE = 4\n\n# This tag can be used to specify a number of aliases that act as commands in\n# the documentation. An alias has the form:\n# name=value\n# For example adding\n# \"sideeffect=@par Side Effects:\\n\"\n# will allow you to put the command \\sideeffect (or @sideeffect) in the\n# documentation, which will result in a user-defined paragraph with heading\n# \"Side Effects:\". You can put \\n's in the value part of an alias to insert\n# newlines.\n\nALIASES =\n\n# This tag can be used to specify a number of word-keyword mappings (TCL only).\n# A mapping has the form \"name=value\". For example adding \"class=itcl::class\"\n# will allow you to use the command class in the itcl::class meaning.\n\nTCL_SUBST =\n\n# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources\n# only. Doxygen will then generate output that is more tailored for C. For\n# instance, some of the names that are used will be different. The list of all\n# members will be omitted, etc.\n# The default value is: NO.\n\nOPTIMIZE_OUTPUT_FOR_C = NO\n\n# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or\n# Python sources only. Doxygen will then generate output that is more tailored\n# for that language. For instance, namespaces will be presented as packages,\n# qualified scopes will look different, etc.\n# The default value is: NO.\n\nOPTIMIZE_OUTPUT_JAVA = NO\n\n# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran\n# sources. Doxygen will then generate output that is tailored for Fortran.\n# The default value is: NO.\n\nOPTIMIZE_FOR_FORTRAN = YES\n\n# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL\n# sources. Doxygen will then generate output that is tailored for VHDL.\n# The default value is: NO.\n\nOPTIMIZE_OUTPUT_VHDL = NO\n\n# Doxygen selects the parser to use depending on the extension of the files it\n# parses. With this tag you can assign which parser to use for a given\n# extension. Doxygen has a built-in mapping, but you can override or extend it\n# using this tag. The format is ext=language, where ext is a file extension, and\n# language is one of the parsers supported by doxygen: IDL, Java, Javascript,\n# C#, C, C++, D, PHP, Objective-C, Python, Fortran (fixed format Fortran:\n# FortranFixed, free formatted Fortran: FortranFree, unknown formatted Fortran:\n# Fortran. In the later case the parser tries to guess whether the code is fixed\n# or free formatted code, this is the default for Fortran type files), VHDL. For\n# instance to make doxygen treat .inc files as Fortran files (default is PHP),\n# and .f files as C (default is Fortran), use: inc=Fortran f=C.\n#\n# Note: For files without extension you can use no_extension as a placeholder.\n#\n# Note that for custom extensions you also need to set FILE_PATTERNS otherwise\n# the files are not read by doxygen.\n\nEXTENSION_MAPPING =\n\n# If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments\n# according to the Markdown format, which allows for more readable\n# documentation. See http://daringfireball.net/projects/markdown/ for details.\n# The output of markdown processing is further processed by doxygen, so you can\n# mix doxygen, HTML, and XML commands with Markdown formatting. Disable only in\n# case of backward compatibilities issues.\n# The default value is: YES.\n\nMARKDOWN_SUPPORT = YES\n\n# When the TOC_INCLUDE_HEADINGS tag is set to a non-zero value, all headings up\n# to that level are automatically included in the table of contents, even if\n# they do not have an id attribute.\n# Note: This feature currently applies only to Markdown headings.\n# Minimum value: 0, maximum value: 99, default value: 0.\n# This tag requires that the tag MARKDOWN_SUPPORT is set to YES.\n\nTOC_INCLUDE_HEADINGS = 0\n\n# When enabled doxygen tries to link words that correspond to documented\n# classes, or namespaces to their corresponding documentation. Such a link can\n# be prevented in individual cases by putting a % sign in front of the word or\n# globally by setting AUTOLINK_SUPPORT to NO.\n# The default value is: YES.\n\nAUTOLINK_SUPPORT = YES\n\n# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want\n# to include (a tag file for) the STL sources as input, then you should set this\n# tag to YES in order to let doxygen match functions declarations and\n# definitions whose arguments contain STL classes (e.g. func(std::string);\n# versus func(std::string) {}). This also make the inheritance and collaboration\n# diagrams that involve STL classes more complete and accurate.\n# The default value is: NO.\n\nBUILTIN_STL_SUPPORT = NO\n\n# If you use Microsoft's C++/CLI language, you should set this option to YES to\n# enable parsing support.\n# The default value is: NO.\n\nCPP_CLI_SUPPORT = NO\n\n# Set the SIP_SUPPORT tag to YES if your project consists of sip (see:\n# http://www.riverbankcomputing.co.uk/software/sip/intro) sources only. Doxygen\n# will parse them like normal C++ but will assume all classes use public instead\n# of private inheritance when no explicit protection keyword is present.\n# The default value is: NO.\n\nSIP_SUPPORT = NO\n\n# For Microsoft's IDL there are propget and propput attributes to indicate\n# getter and setter methods for a property. Setting this option to YES will make\n# doxygen to replace the get and set methods by a property in the documentation.\n# This will only work if the methods are indeed getting or setting a simple\n# type. If this is not the case, or you want to show the methods anyway, you\n# should set this option to NO.\n# The default value is: YES.\n\nIDL_PROPERTY_SUPPORT = YES\n\n# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC\n# tag is set to YES then doxygen will reuse the documentation of the first\n# member in the group (if any) for the other members of the group. By default\n# all members of a group must be documented explicitly.\n# The default value is: NO.\n\nDISTRIBUTE_GROUP_DOC = NO\n\n# If one adds a struct or class to a group and this option is enabled, then also\n# any nested class or struct is added to the same group. By default this option\n# is disabled and one has to add nested compounds explicitly via \\ingroup.\n# The default value is: NO.\n\nGROUP_NESTED_COMPOUNDS = NO\n\n# Set the SUBGROUPING tag to YES to allow class member groups of the same type\n# (for instance a group of public functions) to be put as a subgroup of that\n# type (e.g. under the Public Functions section). Set it to NO to prevent\n# subgrouping. Alternatively, this can be done per class using the\n# \\nosubgrouping command.\n# The default value is: YES.\n\nSUBGROUPING = YES\n\n# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions\n# are shown inside the group in which they are included (e.g. using \\ingroup)\n# instead of on a separate page (for HTML and Man pages) or section (for LaTeX\n# and RTF).\n#\n# Note that this feature does not work in combination with\n# SEPARATE_MEMBER_PAGES.\n# The default value is: NO.\n\nINLINE_GROUPED_CLASSES = NO\n\n# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and unions\n# with only public data fields or simple typedef fields will be shown inline in\n# the documentation of the scope in which they are defined (i.e. file,\n# namespace, or group documentation), provided this scope is documented. If set\n# to NO, structs, classes, and unions are shown on a separate page (for HTML and\n# Man pages) or section (for LaTeX and RTF).\n# The default value is: NO.\n\nINLINE_SIMPLE_STRUCTS = NO\n\n# When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or\n# enum is documented as struct, union, or enum with the name of the typedef. So\n# typedef struct TypeS {} TypeT, will appear in the documentation as a struct\n# with name TypeT. When disabled the typedef will appear as a member of a file,\n# namespace, or class. And the struct will be named TypeS. This can typically be\n# useful for C code in case the coding convention dictates that all compound\n# types are typedef'ed and only the typedef is referenced, never the tag name.\n# The default value is: NO.\n\nTYPEDEF_HIDES_STRUCT = NO\n\n# The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This\n# cache is used to resolve symbols given their name and scope. Since this can be\n# an expensive process and often the same symbol appears multiple times in the\n# code, doxygen keeps a cache of pre-resolved symbols. If the cache is too small\n# doxygen will become slower. If the cache is too large, memory is wasted. The\n# cache size is given by this formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range\n# is 0..9, the default is 0, corresponding to a cache size of 2^16=65536\n# symbols. At the end of a run doxygen will report the cache usage and suggest\n# the optimal cache size from a speed point of view.\n# Minimum value: 0, maximum value: 9, default value: 0.\n\nLOOKUP_CACHE_SIZE = 0\n\n#---------------------------------------------------------------------------\n# Build related configuration options\n#---------------------------------------------------------------------------\n\n# If the EXTRACT_ALL tag is set to YES, doxygen will assume all entities in\n# documentation are documented, even if no documentation was available. Private\n# class members and static file members will be hidden unless the\n# EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES.\n# Note: This will also disable the warnings about undocumented members that are\n# normally produced when WARNINGS is set to YES.\n# The default value is: NO.\n\nEXTRACT_ALL = YES\n\n# If the EXTRACT_PRIVATE tag is set to YES, all private members of a class will\n# be included in the documentation.\n# The default value is: NO.\n\nEXTRACT_PRIVATE = YES\n\n# If the EXTRACT_PACKAGE tag is set to YES, all members with package or internal\n# scope will be included in the documentation.\n# The default value is: NO.\n\nEXTRACT_PACKAGE = YES\n\n# If the EXTRACT_STATIC tag is set to YES, all static members of a file will be\n# included in the documentation.\n# The default value is: NO.\n\nEXTRACT_STATIC = NO\n\n# If the EXTRACT_LOCAL_CLASSES tag is set to YES, classes (and structs) defined\n# locally in source files will be included in the documentation. If set to NO,\n# only classes defined in header files are included. Does not have any effect\n# for Java sources.\n# The default value is: YES.\n\nEXTRACT_LOCAL_CLASSES = YES\n\n# This flag is only useful for Objective-C code. If set to YES, local methods,\n# which are defined in the implementation section but not in the interface are\n# included in the documentation. If set to NO, only methods in the interface are\n# included.\n# The default value is: NO.\n\nEXTRACT_LOCAL_METHODS = NO\n\n# If this flag is set to YES, the members of anonymous namespaces will be\n# extracted and appear in the documentation as a namespace called\n# 'anonymous_namespace{file}', where file will be replaced with the base name of\n# the file that contains the anonymous namespace. By default anonymous namespace\n# are hidden.\n# The default value is: NO.\n\nEXTRACT_ANON_NSPACES = NO\n\n# If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all\n# undocumented members inside documented classes or files. If set to NO these\n# members will be included in the various overviews, but no documentation\n# section is generated. This option has no effect if EXTRACT_ALL is enabled.\n# The default value is: NO.\n\nHIDE_UNDOC_MEMBERS = NO\n\n# If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all\n# undocumented classes that are normally visible in the class hierarchy. If set\n# to NO, these classes will be included in the various overviews. This option\n# has no effect if EXTRACT_ALL is enabled.\n# The default value is: NO.\n\nHIDE_UNDOC_CLASSES = NO\n\n# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend\n# (class|struct|union) declarations. If set to NO, these declarations will be\n# included in the documentation.\n# The default value is: NO.\n\nHIDE_FRIEND_COMPOUNDS = NO\n\n# If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any\n# documentation blocks found inside the body of a function. If set to NO, these\n# blocks will be appended to the function's detailed documentation block.\n# The default value is: NO.\n\nHIDE_IN_BODY_DOCS = NO\n\n# The INTERNAL_DOCS tag determines if documentation that is typed after a\n# \\internal command is included. If the tag is set to NO then the documentation\n# will be excluded. Set it to YES to include the internal documentation.\n# The default value is: NO.\n\nINTERNAL_DOCS = NO\n\n# If the CASE_SENSE_NAMES tag is set to NO then doxygen will only generate file\n# names in lower-case letters. If set to YES, upper-case letters are also\n# allowed. This is useful if you have classes or files whose names only differ\n# in case and if your file system supports case sensitive file names. Windows\n# and Mac users are advised to set this option to NO.\n# The default value is: system dependent.\n\nCASE_SENSE_NAMES = YES\n\n# If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with\n# their full class and namespace scopes in the documentation. If set to YES, the\n# scope will be hidden.\n# The default value is: NO.\n\nHIDE_SCOPE_NAMES = NO\n\n# If the HIDE_COMPOUND_REFERENCE tag is set to NO (default) then doxygen will\n# append additional text to a page's title, such as Class Reference. If set to\n# YES the compound reference will be hidden.\n# The default value is: NO.\n\nHIDE_COMPOUND_REFERENCE= NO\n\n# If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of\n# the files that are included by a file in the documentation of that file.\n# The default value is: YES.\n\nSHOW_INCLUDE_FILES = YES\n\n# If the SHOW_GROUPED_MEMB_INC tag is set to YES then Doxygen will add for each\n# grouped member an include statement to the documentation, telling the reader\n# which file to include in order to use the member.\n# The default value is: NO.\n\nSHOW_GROUPED_MEMB_INC = NO\n\n# If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include\n# files with double quotes in the documentation rather than with sharp brackets.\n# The default value is: NO.\n\nFORCE_LOCAL_INCLUDES = NO\n\n# If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the\n# documentation for inline members.\n# The default value is: YES.\n\nINLINE_INFO = YES\n\n# If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the\n# (detailed) documentation of file and class members alphabetically by member\n# name. If set to NO, the members will appear in declaration order.\n# The default value is: YES.\n\nSORT_MEMBER_DOCS = YES\n\n# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief\n# descriptions of file, namespace and class members alphabetically by member\n# name. If set to NO, the members will appear in declaration order. Note that\n# this will also influence the order of the classes in the class list.\n# The default value is: NO.\n\nSORT_BRIEF_DOCS = NO\n\n# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the\n# (brief and detailed) documentation of class members so that constructors and\n# destructors are listed first. If set to NO the constructors will appear in the\n# respective orders defined by SORT_BRIEF_DOCS and SORT_MEMBER_DOCS.\n# Note: If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief\n# member documentation.\n# Note: If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting\n# detailed member documentation.\n# The default value is: NO.\n\nSORT_MEMBERS_CTORS_1ST = NO\n\n# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy\n# of group names into alphabetical order. If set to NO the group names will\n# appear in their defined order.\n# The default value is: NO.\n\nSORT_GROUP_NAMES = NO\n\n# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by\n# fully-qualified names, including namespaces. If set to NO, the class list will\n# be sorted only by class name, not including the namespace part.\n# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.\n# Note: This option applies only to the class list, not to the alphabetical\n# list.\n# The default value is: NO.\n\nSORT_BY_SCOPE_NAME = NO\n\n# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to do proper\n# type resolution of all parameters of a function it will reject a match between\n# the prototype and the implementation of a member function even if there is\n# only one candidate or it is obvious which candidate to choose by doing a\n# simple string match. By disabling STRICT_PROTO_MATCHING doxygen will still\n# accept a match between prototype and implementation in such cases.\n# The default value is: NO.\n\nSTRICT_PROTO_MATCHING = NO\n\n# The GENERATE_TODOLIST tag can be used to enable (YES) or disable (NO) the todo\n# list. This list is created by putting \\todo commands in the documentation.\n# The default value is: YES.\n\nGENERATE_TODOLIST = YES\n\n# The GENERATE_TESTLIST tag can be used to enable (YES) or disable (NO) the test\n# list. This list is created by putting \\test commands in the documentation.\n# The default value is: YES.\n\nGENERATE_TESTLIST = YES\n\n# The GENERATE_BUGLIST tag can be used to enable (YES) or disable (NO) the bug\n# list. This list is created by putting \\bug commands in the documentation.\n# The default value is: YES.\n\nGENERATE_BUGLIST = YES\n\n# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or disable (NO)\n# the deprecated list. This list is created by putting \\deprecated commands in\n# the documentation.\n# The default value is: YES.\n\nGENERATE_DEPRECATEDLIST= YES\n\n# The ENABLED_SECTIONS tag can be used to enable conditional documentation\n# sections, marked by \\if ... \\endif and \\cond \n# ... \\endcond blocks.\n\nENABLED_SECTIONS =\n\n# The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the\n# initial value of a variable or macro / define can have for it to appear in the\n# documentation. If the initializer consists of more lines than specified here\n# it will be hidden. Use a value of 0 to hide initializers completely. The\n# appearance of the value of individual variables and macros / defines can be\n# controlled using \\showinitializer or \\hideinitializer command in the\n# documentation regardless of this setting.\n# Minimum value: 0, maximum value: 10000, default value: 30.\n\nMAX_INITIALIZER_LINES = 30\n\n# Set the SHOW_USED_FILES tag to NO to disable the list of files generated at\n# the bottom of the documentation of classes and structs. If set to YES, the\n# list will mention the files that were used to generate the documentation.\n# The default value is: YES.\n\nSHOW_USED_FILES = YES\n\n# Set the SHOW_FILES tag to NO to disable the generation of the Files page. This\n# will remove the Files entry from the Quick Index and from the Folder Tree View\n# (if specified).\n# The default value is: YES.\n\nSHOW_FILES = YES\n\n# Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces\n# page. This will remove the Namespaces entry from the Quick Index and from the\n# Folder Tree View (if specified).\n# The default value is: YES.\n\nSHOW_NAMESPACES = YES\n\n# The FILE_VERSION_FILTER tag can be used to specify a program or script that\n# doxygen should invoke to get the current version for each file (typically from\n# the version control system). Doxygen will invoke the program by executing (via\n# popen()) the command command input-file, where command is the value of the\n# FILE_VERSION_FILTER tag, and input-file is the name of an input file provided\n# by doxygen. Whatever the program writes to standard output is used as the file\n# version. For an example see the documentation.\n\nFILE_VERSION_FILTER =\n\n# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed\n# by doxygen. The layout file controls the global structure of the generated\n# output files in an output format independent way. To create the layout file\n# that represents doxygen's defaults, run doxygen with the -l option. You can\n# optionally specify a file name after the option, if omitted DoxygenLayout.xml\n# will be used as the name of the layout file.\n#\n# Note that if you run doxygen from a directory containing a file called\n# DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE\n# tag is left empty.\n\nLAYOUT_FILE =\n\n# The CITE_BIB_FILES tag can be used to specify one or more bib files containing\n# the reference definitions. This must be a list of .bib files. The .bib\n# extension is automatically appended if omitted. This requires the bibtex tool\n# to be installed. See also http://en.wikipedia.org/wiki/BibTeX for more info.\n# For LaTeX the style of the bibliography can be controlled using\n# LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the\n# search path. See also \\cite for info how to create references.\n\nCITE_BIB_FILES =\n\n#---------------------------------------------------------------------------\n# Configuration options related to warning and progress messages\n#---------------------------------------------------------------------------\n\n# The QUIET tag can be used to turn on/off the messages that are generated to\n# standard output by doxygen. If QUIET is set to YES this implies that the\n# messages are off.\n# The default value is: NO.\n\nQUIET = NO\n\n# The WARNINGS tag can be used to turn on/off the warning messages that are\n# generated to standard error (stderr) by doxygen. If WARNINGS is set to YES\n# this implies that the warnings are on.\n#\n# Tip: Turn warnings on while writing the documentation.\n# The default value is: YES.\n\nWARNINGS = YES\n\n# If the WARN_IF_UNDOCUMENTED tag is set to YES then doxygen will generate\n# warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag\n# will automatically be disabled.\n# The default value is: YES.\n\nWARN_IF_UNDOCUMENTED = YES\n\n# If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for\n# potential errors in the documentation, such as not documenting some parameters\n# in a documented function, or documenting parameters that don't exist or using\n# markup commands wrongly.\n# The default value is: YES.\n\nWARN_IF_DOC_ERROR = YES\n\n# This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that\n# are documented, but have no documentation for their parameters or return\n# value. If set to NO, doxygen will only warn about wrong or incomplete\n# parameter documentation, but not about the absence of documentation.\n# The default value is: NO.\n\nWARN_NO_PARAMDOC = NO\n\n# If the WARN_AS_ERROR tag is set to YES then doxygen will immediately stop when\n# a warning is encountered.\n# The default value is: NO.\n\nWARN_AS_ERROR = NO\n\n# The WARN_FORMAT tag determines the format of the warning messages that doxygen\n# can produce. The string should contain the $file, $line, and $text tags, which\n# will be replaced by the file and line number from which the warning originated\n# and the warning text. Optionally the format may contain $version, which will\n# be replaced by the version of the file (if it could be obtained via\n# FILE_VERSION_FILTER)\n# The default value is: $file:$line: $text.\n\nWARN_FORMAT = \"$file:$line: $text\"\n\n# The WARN_LOGFILE tag can be used to specify a file to which warning and error\n# messages should be written. If left blank the output is written to standard\n# error (stderr).\n\nWARN_LOGFILE =\n\n#---------------------------------------------------------------------------\n# Configuration options related to the input files\n#---------------------------------------------------------------------------\n\n# The INPUT tag is used to specify the files and/or directories that contain\n# documented source files. You may enter file names like myfile.cpp or\n# directories like /usr/src/myproject. Separate the files or directories with\n# spaces. See also FILE_PATTERNS and EXTENSION_MAPPING\n# Note: If this tag is empty the current directory is searched.\n\nINPUT =\n\n# This tag can be used to specify the character encoding of the source files\n# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses\n# libiconv (or the iconv built into libc) for the transcoding. See the libiconv\n# documentation (see: http://www.gnu.org/software/libiconv) for the list of\n# possible encodings.\n# The default value is: UTF-8.\n\nINPUT_ENCODING = UTF-8\n\n# If the value of the INPUT tag contains directories, you can use the\n# FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and\n# *.h) to filter out the source-files in the directories.\n#\n# Note that for custom extensions or not directly supported extensions you also\n# need to set EXTENSION_MAPPING for the extension otherwise the files are not\n# read by doxygen.\n#\n# If left blank the following patterns are tested:*.c, *.cc, *.cxx, *.cpp,\n# *.c++, *.java, *.ii, *.ixx, *.ipp, *.i++, *.inl, *.idl, *.ddl, *.odl, *.h,\n# *.hh, *.hxx, *.hpp, *.h++, *.cs, *.d, *.php, *.php4, *.php5, *.phtml, *.inc,\n# *.m, *.markdown, *.md, *.mm, *.dox, *.py, *.pyw, *.f90, *.f95, *.f03, *.f08,\n# *.f, *.for, *.tcl, *.vhd, *.vhdl, *.ucf and *.qsf.\n\nFILE_PATTERNS = *.c \\\n *.cc \\\n *.cxx \\\n *.cpp \\\n *.c++ \\\n *.java \\\n *.ii \\\n *.ixx \\\n *.ipp \\\n *.i++ \\\n *.inl \\\n *.idl \\\n *.ddl \\\n *.odl \\\n *.h \\\n *.hh \\\n *.hxx \\\n *.hpp \\\n *.h++ \\\n *.cs \\\n *.d \\\n *.php \\\n *.php4 \\\n *.php5 \\\n *.phtml \\\n *.inc \\\n *.m \\\n *.markdown \\\n *.mm \\\n *.dox \\\n *.py \\\n *.pyw \\\n *.f90 \\\n\t\t\t *.F90 \\\n *.f95 \\\n *.f03 \\\n *.f08 \\\n *.f \\\n *.for \\\n *.tcl \\\n *.vhd \\\n *.vhdl \\\n *.ucf \\\n *.qsf\n\n# The RECURSIVE tag can be used to specify whether or not subdirectories should\n# be searched for input files as well.\n# The default value is: NO.\n\nRECURSIVE = NO\n\n# The EXCLUDE tag can be used to specify files and/or directories that should be\n# excluded from the INPUT source files. This way you can easily exclude a\n# subdirectory from a directory tree whose root is specified with the INPUT tag.\n#\n# Note that relative paths are relative to the directory from which doxygen is\n# run.\n\nEXCLUDE =\n\n# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or\n# directories that are symbolic links (a Unix file system feature) are excluded\n# from the input.\n# The default value is: NO.\n\nEXCLUDE_SYMLINKS = NO\n\n# If the value of the INPUT tag contains directories, you can use the\n# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude\n# certain files from those directories.\n#\n# Note that the wildcards are matched against the file with absolute path, so to\n# exclude all test directories for example use the pattern */test/*\n\nEXCLUDE_PATTERNS =\n\n# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names\n# (namespaces, classes, functions, etc.) that should be excluded from the\n# output. The symbol name can be a fully qualified name, a word, or if the\n# wildcard * is used, a substring. Examples: ANamespace, AClass,\n# AClass::ANamespace, ANamespace::*Test\n#\n# Note that the wildcards are matched against the file with absolute path, so to\n# exclude all test directories use the pattern */test/*\n\nEXCLUDE_SYMBOLS =\n\n# The EXAMPLE_PATH tag can be used to specify one or more files or directories\n# that contain example code fragments that are included (see the \\include\n# command).\n\nEXAMPLE_PATH =\n\n# If the value of the EXAMPLE_PATH tag contains directories, you can use the\n# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and\n# *.h) to filter out the source-files in the directories. If left blank all\n# files are included.\n\nEXAMPLE_PATTERNS = *\n\n# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be\n# searched for input files to be used with the \\include or \\dontinclude commands\n# irrespective of the value of the RECURSIVE tag.\n# The default value is: NO.\n\nEXAMPLE_RECURSIVE = NO\n\n# The IMAGE_PATH tag can be used to specify one or more files or directories\n# that contain images that are to be included in the documentation (see the\n# \\image command).\n\nIMAGE_PATH = docimages\n\n# The INPUT_FILTER tag can be used to specify a program that doxygen should\n# invoke to filter for each input file. Doxygen will invoke the filter program\n# by executing (via popen()) the command:\n#\n# \n#\n# where is the value of the INPUT_FILTER tag, and is the\n# name of an input file. Doxygen will then use the output that the filter\n# program writes to standard output. If FILTER_PATTERNS is specified, this tag\n# will be ignored.\n#\n# Note that the filter must not add or remove lines; it is applied before the\n# code is scanned, but not when the output code is generated. If lines are added\n# or removed, the anchors will not be placed correctly.\n#\n# Note that for custom extensions or not directly supported extensions you also\n# need to set EXTENSION_MAPPING for the extension otherwise the files are not\n# properly processed by doxygen.\n\nINPUT_FILTER =\n\n# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern\n# basis. Doxygen will compare the file name with each pattern and apply the\n# filter if there is a match. The filters are a list of the form: pattern=filter\n# (like *.cpp=my_cpp_filter). See INPUT_FILTER for further information on how\n# filters are used. If the FILTER_PATTERNS tag is empty or if none of the\n# patterns match the file name, INPUT_FILTER is applied.\n#\n# Note that for custom extensions or not directly supported extensions you also\n# need to set EXTENSION_MAPPING for the extension otherwise the files are not\n# properly processed by doxygen.\n\nFILTER_PATTERNS =\n\n# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using\n# INPUT_FILTER) will also be used to filter the input files that are used for\n# producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES).\n# The default value is: NO.\n\nFILTER_SOURCE_FILES = NO\n\n# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file\n# pattern. A pattern will override the setting for FILTER_PATTERN (if any) and\n# it is also possible to disable source filtering for a specific pattern using\n# *.ext= (so without naming a filter).\n# This tag requires that the tag FILTER_SOURCE_FILES is set to YES.\n\nFILTER_SOURCE_PATTERNS =\n\n# If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that\n# is part of the input, its contents will be placed on the main page\n# (index.html). This can be useful if you have a project on for instance GitHub\n# and want to reuse the introduction page also for the doxygen output.\n\nUSE_MDFILE_AS_MAINPAGE =\n\n#---------------------------------------------------------------------------\n# Configuration options related to source browsing\n#---------------------------------------------------------------------------\n\n# If the SOURCE_BROWSER tag is set to YES then a list of source files will be\n# generated. Documented entities will be cross-referenced with these sources.\n#\n# Note: To get rid of all source code in the generated output, make sure that\n# also VERBATIM_HEADERS is set to NO.\n# The default value is: NO.\n\nSOURCE_BROWSER = NO\n\n# Setting the INLINE_SOURCES tag to YES will include the body of functions,\n# classes and enums directly into the documentation.\n# The default value is: NO.\n\nINLINE_SOURCES = NO\n\n# Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any\n# special comment blocks from generated source code fragments. Normal C, C++ and\n# Fortran comments will always remain visible.\n# The default value is: YES.\n\nSTRIP_CODE_COMMENTS = YES\n\n# If the REFERENCED_BY_RELATION tag is set to YES then for each documented\n# function all documented functions referencing it will be listed.\n# The default value is: NO.\n\nREFERENCED_BY_RELATION = NO\n\n# If the REFERENCES_RELATION tag is set to YES then for each documented function\n# all documented entities called/used by that function will be listed.\n# The default value is: NO.\n\nREFERENCES_RELATION = NO\n\n# If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set\n# to YES then the hyperlinks from functions in REFERENCES_RELATION and\n# REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will\n# link to the documentation.\n# The default value is: YES.\n\nREFERENCES_LINK_SOURCE = YES\n\n# If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the\n# source code will show a tooltip with additional information such as prototype,\n# brief description and links to the definition and documentation. Since this\n# will make the HTML file larger and loading of large files a bit slower, you\n# can opt to disable this feature.\n# The default value is: YES.\n# This tag requires that the tag SOURCE_BROWSER is set to YES.\n\nSOURCE_TOOLTIPS = YES\n\n# If the USE_HTAGS tag is set to YES then the references to source code will\n# point to the HTML generated by the htags(1) tool instead of doxygen built-in\n# source browser. The htags tool is part of GNU's global source tagging system\n# (see http://www.gnu.org/software/global/global.html). You will need version\n# 4.8.6 or higher.\n#\n# To use it do the following:\n# - Install the latest version of global\n# - Enable SOURCE_BROWSER and USE_HTAGS in the config file\n# - Make sure the INPUT points to the root of the source tree\n# - Run doxygen as normal\n#\n# Doxygen will invoke htags (and that will in turn invoke gtags), so these\n# tools must be available from the command line (i.e. in the search path).\n#\n# The result: instead of the source browser generated by doxygen, the links to\n# source code will now point to the output of htags.\n# The default value is: NO.\n# This tag requires that the tag SOURCE_BROWSER is set to YES.\n\nUSE_HTAGS = NO\n\n# If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a\n# verbatim copy of the header file for each class for which an include is\n# specified. Set to NO to disable this.\n# See also: Section \\class.\n# The default value is: YES.\n\nVERBATIM_HEADERS = YES\n\n# If the CLANG_ASSISTED_PARSING tag is set to YES then doxygen will use the\n# clang parser (see: http://clang.llvm.org/) for more accurate parsing at the\n# cost of reduced performance. This can be particularly helpful with template\n# rich C++ code for which doxygen's built-in parser lacks the necessary type\n# information.\n# Note: The availability of this option depends on whether or not doxygen was\n# generated with the -Duse-libclang=ON option for CMake.\n# The default value is: NO.\n\nCLANG_ASSISTED_PARSING = NO\n\n# If clang assisted parsing is enabled you can provide the compiler with command\n# line options that you would normally use when invoking the compiler. Note that\n# the include paths will already be set by doxygen for the files and directories\n# specified with INPUT and INCLUDE_PATH.\n# This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES.\n\nCLANG_OPTIONS =\n\n#---------------------------------------------------------------------------\n# Configuration options related to the alphabetical class index\n#---------------------------------------------------------------------------\n\n# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all\n# compounds will be generated. Enable this if the project contains a lot of\n# classes, structs, unions or interfaces.\n# The default value is: YES.\n\nALPHABETICAL_INDEX = YES\n\n# The COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns in\n# which the alphabetical index list will be split.\n# Minimum value: 1, maximum value: 20, default value: 5.\n# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.\n\nCOLS_IN_ALPHA_INDEX = 5\n\n# In case all classes in a project start with a common prefix, all classes will\n# be put under the same header in the alphabetical index. The IGNORE_PREFIX tag\n# can be used to specify a prefix (or a list of prefixes) that should be ignored\n# while generating the index headers.\n# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.\n\nIGNORE_PREFIX =\n\n#---------------------------------------------------------------------------\n# Configuration options related to the HTML output\n#---------------------------------------------------------------------------\n\n# If the GENERATE_HTML tag is set to YES, doxygen will generate HTML output\n# The default value is: YES.\n\nGENERATE_HTML = YES\n\n# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a\n# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of\n# it.\n# The default directory is: html.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nHTML_OUTPUT = html\n\n# The HTML_FILE_EXTENSION tag can be used to specify the file extension for each\n# generated HTML page (for example: .htm, .php, .asp).\n# The default value is: .html.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nHTML_FILE_EXTENSION = .html\n\n# The HTML_HEADER tag can be used to specify a user-defined HTML header file for\n# each generated HTML page. If the tag is left blank doxygen will generate a\n# standard header.\n#\n# To get valid HTML the header file that includes any scripts and style sheets\n# that doxygen needs, which is dependent on the configuration options used (e.g.\n# the setting GENERATE_TREEVIEW). It is highly recommended to start with a\n# default header using\n# doxygen -w html new_header.html new_footer.html new_stylesheet.css\n# YourConfigFile\n# and then modify the file new_header.html. See also section \"Doxygen usage\"\n# for information on how to generate the default header that doxygen normally\n# uses.\n# Note: The header is subject to change so you typically have to regenerate the\n# default header when upgrading to a newer version of doxygen. For a description\n# of the possible markers and block names see the documentation.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nHTML_HEADER =\n\n# The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each\n# generated HTML page. If the tag is left blank doxygen will generate a standard\n# footer. See HTML_HEADER for more information on how to generate a default\n# footer and what special commands can be used inside the footer. See also\n# section \"Doxygen usage\" for information on how to generate the default footer\n# that doxygen normally uses.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nHTML_FOOTER =\n\n# The HTML_STYLESHEET tag can be used to specify a user-defined cascading style\n# sheet that is used by each HTML page. It can be used to fine-tune the look of\n# the HTML output. If left blank doxygen will generate a default style sheet.\n# See also section \"Doxygen usage\" for information on how to generate the style\n# sheet that doxygen normally uses.\n# Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as\n# it is more robust and this tag (HTML_STYLESHEET) will in the future become\n# obsolete.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nHTML_STYLESHEET =\n\n# The HTML_EXTRA_STYLESHEET tag can be used to specify additional user-defined\n# cascading style sheets that are included after the standard style sheets\n# created by doxygen. Using this option one can overrule certain style aspects.\n# This is preferred over using HTML_STYLESHEET since it does not replace the\n# standard style sheet and is therefore more robust against future updates.\n# Doxygen will copy the style sheet files to the output directory.\n# Note: The order of the extra style sheet files is of importance (e.g. the last\n# style sheet in the list overrules the setting of the previous ones in the\n# list). For an example see the documentation.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nHTML_EXTRA_STYLESHEET =\n\n# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or\n# other source files which should be copied to the HTML output directory. Note\n# that these files will be copied to the base HTML output directory. Use the\n# $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these\n# files. In the HTML_STYLESHEET file, use the file name only. Also note that the\n# files will be copied as-is; there are no commands or markers available.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nHTML_EXTRA_FILES =\n\n# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen\n# will adjust the colors in the style sheet and background images according to\n# this color. Hue is specified as an angle on a colorwheel, see\n# http://en.wikipedia.org/wiki/Hue for more information. For instance the value\n# 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300\n# purple, and 360 is red again.\n# Minimum value: 0, maximum value: 359, default value: 220.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nHTML_COLORSTYLE_HUE = 220\n\n# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors\n# in the HTML output. For a value of 0 the output will use grayscales only. A\n# value of 255 will produce the most vivid colors.\n# Minimum value: 0, maximum value: 255, default value: 100.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nHTML_COLORSTYLE_SAT = 100\n\n# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the\n# luminance component of the colors in the HTML output. Values below 100\n# gradually make the output lighter, whereas values above 100 make the output\n# darker. The value divided by 100 is the actual gamma applied, so 80 represents\n# a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not\n# change the gamma.\n# Minimum value: 40, maximum value: 240, default value: 80.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nHTML_COLORSTYLE_GAMMA = 80\n\n# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML\n# page will contain the date and time when the page was generated. Setting this\n# to YES can help to show when doxygen was last run and thus if the\n# documentation is up to date.\n# The default value is: NO.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nHTML_TIMESTAMP = NO\n\n# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML\n# documentation will contain sections that can be hidden and shown after the\n# page has loaded.\n# The default value is: NO.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nHTML_DYNAMIC_SECTIONS = NO\n\n# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries\n# shown in the various tree structured indices initially; the user can expand\n# and collapse entries dynamically later on. Doxygen will expand the tree to\n# such a level that at most the specified number of entries are visible (unless\n# a fully collapsed tree already exceeds this amount). So setting the number of\n# entries 1 will produce a full collapsed tree by default. 0 is a special value\n# representing an infinite number of entries and will result in a full expanded\n# tree by default.\n# Minimum value: 0, maximum value: 9999, default value: 100.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nHTML_INDEX_NUM_ENTRIES = 100\n\n# If the GENERATE_DOCSET tag is set to YES, additional index files will be\n# generated that can be used as input for Apple's Xcode 3 integrated development\n# environment (see: http://developer.apple.com/tools/xcode/), introduced with\n# OSX 10.5 (Leopard). To create a documentation set, doxygen will generate a\n# Makefile in the HTML output directory. Running make will produce the docset in\n# that directory and running make install will install the docset in\n# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at\n# startup. See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html\n# for more information.\n# The default value is: NO.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nGENERATE_DOCSET = NO\n\n# This tag determines the name of the docset feed. A documentation feed provides\n# an umbrella under which multiple documentation sets from a single provider\n# (such as a company or product suite) can be grouped.\n# The default value is: Doxygen generated docs.\n# This tag requires that the tag GENERATE_DOCSET is set to YES.\n\nDOCSET_FEEDNAME = \"Doxygen generated docs\"\n\n# This tag specifies a string that should uniquely identify the documentation\n# set bundle. This should be a reverse domain-name style string, e.g.\n# com.mycompany.MyDocSet. Doxygen will append .docset to the name.\n# The default value is: org.doxygen.Project.\n# This tag requires that the tag GENERATE_DOCSET is set to YES.\n\nDOCSET_BUNDLE_ID = org.doxygen.Project\n\n# The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify\n# the documentation publisher. This should be a reverse domain-name style\n# string, e.g. com.mycompany.MyDocSet.documentation.\n# The default value is: org.doxygen.Publisher.\n# This tag requires that the tag GENERATE_DOCSET is set to YES.\n\nDOCSET_PUBLISHER_ID = org.doxygen.Publisher\n\n# The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher.\n# The default value is: Publisher.\n# This tag requires that the tag GENERATE_DOCSET is set to YES.\n\nDOCSET_PUBLISHER_NAME = Publisher\n\n# If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three\n# additional HTML index files: index.hhp, index.hhc, and index.hhk. The\n# index.hhp is a project file that can be read by Microsoft's HTML Help Workshop\n# (see: http://www.microsoft.com/en-us/download/details.aspx?id=21138) on\n# Windows.\n#\n# The HTML Help Workshop contains a compiler that can convert all HTML output\n# generated by doxygen into a single compiled HTML file (.chm). Compiled HTML\n# files are now used as the Windows 98 help format, and will replace the old\n# Windows help format (.hlp) on all Windows platforms in the future. Compressed\n# HTML files also contain an index, a table of contents, and you can search for\n# words in the documentation. The HTML workshop also contains a viewer for\n# compressed HTML files.\n# The default value is: NO.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nGENERATE_HTMLHELP = NO\n\n# The CHM_FILE tag can be used to specify the file name of the resulting .chm\n# file. You can add a path in front of the file if the result should not be\n# written to the html output directory.\n# This tag requires that the tag GENERATE_HTMLHELP is set to YES.\n\nCHM_FILE =\n\n# The HHC_LOCATION tag can be used to specify the location (absolute path\n# including file name) of the HTML help compiler (hhc.exe). If non-empty,\n# doxygen will try to run the HTML help compiler on the generated index.hhp.\n# The file has to be specified with full path.\n# This tag requires that the tag GENERATE_HTMLHELP is set to YES.\n\nHHC_LOCATION =\n\n# The GENERATE_CHI flag controls if a separate .chi index file is generated\n# (YES) or that it should be included in the master .chm file (NO).\n# The default value is: NO.\n# This tag requires that the tag GENERATE_HTMLHELP is set to YES.\n\nGENERATE_CHI = NO\n\n# The CHM_INDEX_ENCODING is used to encode HtmlHelp index (hhk), content (hhc)\n# and project file content.\n# This tag requires that the tag GENERATE_HTMLHELP is set to YES.\n\nCHM_INDEX_ENCODING =\n\n# The BINARY_TOC flag controls whether a binary table of contents is generated\n# (YES) or a normal table of contents (NO) in the .chm file. Furthermore it\n# enables the Previous and Next buttons.\n# The default value is: NO.\n# This tag requires that the tag GENERATE_HTMLHELP is set to YES.\n\nBINARY_TOC = NO\n\n# The TOC_EXPAND flag can be set to YES to add extra items for group members to\n# the table of contents of the HTML help documentation and to the tree view.\n# The default value is: NO.\n# This tag requires that the tag GENERATE_HTMLHELP is set to YES.\n\nTOC_EXPAND = NO\n\n# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and\n# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that\n# can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help\n# (.qch) of the generated HTML documentation.\n# The default value is: NO.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nGENERATE_QHP = NO\n\n# If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify\n# the file name of the resulting .qch file. The path specified is relative to\n# the HTML output folder.\n# This tag requires that the tag GENERATE_QHP is set to YES.\n\nQCH_FILE =\n\n# The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help\n# Project output. For more information please see Qt Help Project / Namespace\n# (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#namespace).\n# The default value is: org.doxygen.Project.\n# This tag requires that the tag GENERATE_QHP is set to YES.\n\nQHP_NAMESPACE = org.doxygen.Project\n\n# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt\n# Help Project output. For more information please see Qt Help Project / Virtual\n# Folders (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#virtual-\n# folders).\n# The default value is: doc.\n# This tag requires that the tag GENERATE_QHP is set to YES.\n\nQHP_VIRTUAL_FOLDER = doc\n\n# If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom\n# filter to add. For more information please see Qt Help Project / Custom\n# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-\n# filters).\n# This tag requires that the tag GENERATE_QHP is set to YES.\n\nQHP_CUST_FILTER_NAME =\n\n# The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the\n# custom filter to add. For more information please see Qt Help Project / Custom\n# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-\n# filters).\n# This tag requires that the tag GENERATE_QHP is set to YES.\n\nQHP_CUST_FILTER_ATTRS =\n\n# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this\n# project's filter section matches. Qt Help Project / Filter Attributes (see:\n# http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes).\n# This tag requires that the tag GENERATE_QHP is set to YES.\n\nQHP_SECT_FILTER_ATTRS =\n\n# The QHG_LOCATION tag can be used to specify the location of Qt's\n# qhelpgenerator. If non-empty doxygen will try to run qhelpgenerator on the\n# generated .qhp file.\n# This tag requires that the tag GENERATE_QHP is set to YES.\n\nQHG_LOCATION =\n\n# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be\n# generated, together with the HTML files, they form an Eclipse help plugin. To\n# install this plugin and make it available under the help contents menu in\n# Eclipse, the contents of the directory containing the HTML and XML files needs\n# to be copied into the plugins directory of eclipse. The name of the directory\n# within the plugins directory should be the same as the ECLIPSE_DOC_ID value.\n# After copying Eclipse needs to be restarted before the help appears.\n# The default value is: NO.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nGENERATE_ECLIPSEHELP = NO\n\n# A unique identifier for the Eclipse help plugin. When installing the plugin\n# the directory name containing the HTML and XML files should also have this\n# name. Each documentation set should have its own identifier.\n# The default value is: org.doxygen.Project.\n# This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES.\n\nECLIPSE_DOC_ID = org.doxygen.Project\n\n# If you want full control over the layout of the generated HTML pages it might\n# be necessary to disable the index and replace it with your own. The\n# DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top\n# of each HTML page. A value of NO enables the index and the value YES disables\n# it. Since the tabs in the index contain the same information as the navigation\n# tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES.\n# The default value is: NO.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nDISABLE_INDEX = NO\n\n# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index\n# structure should be generated to display hierarchical information. If the tag\n# value is set to YES, a side panel will be generated containing a tree-like\n# index structure (just like the one that is generated for HTML Help). For this\n# to work a browser that supports JavaScript, DHTML, CSS and frames is required\n# (i.e. any modern browser). Windows users are probably better off using the\n# HTML help feature. Via custom style sheets (see HTML_EXTRA_STYLESHEET) one can\n# further fine-tune the look of the index. As an example, the default style\n# sheet generated by doxygen has an example that shows how to put an image at\n# the root of the tree instead of the PROJECT_NAME. Since the tree basically has\n# the same information as the tab index, you could consider setting\n# DISABLE_INDEX to YES when enabling this option.\n# The default value is: NO.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nGENERATE_TREEVIEW = NO\n\n# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that\n# doxygen will group on one line in the generated HTML documentation.\n#\n# Note that a value of 0 will completely suppress the enum values from appearing\n# in the overview section.\n# Minimum value: 0, maximum value: 20, default value: 4.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nENUM_VALUES_PER_LINE = 4\n\n# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used\n# to set the initial width (in pixels) of the frame in which the tree is shown.\n# Minimum value: 0, maximum value: 1500, default value: 250.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nTREEVIEW_WIDTH = 250\n\n# If the EXT_LINKS_IN_WINDOW option is set to YES, doxygen will open links to\n# external symbols imported via tag files in a separate window.\n# The default value is: NO.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nEXT_LINKS_IN_WINDOW = NO\n\n# Use this tag to change the font size of LaTeX formulas included as images in\n# the HTML documentation. When you change the font size after a successful\n# doxygen run you need to manually remove any form_*.png images from the HTML\n# output directory to force them to be regenerated.\n# Minimum value: 8, maximum value: 50, default value: 10.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nFORMULA_FONTSIZE = 10\n\n# Use the FORMULA_TRANPARENT tag to determine whether or not the images\n# generated for formulas are transparent PNGs. Transparent PNGs are not\n# supported properly for IE 6.0, but are supported on all modern browsers.\n#\n# Note that when changing this option you need to delete any form_*.png files in\n# the HTML output directory before the changes have effect.\n# The default value is: YES.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nFORMULA_TRANSPARENT = YES\n\n# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see\n# http://www.mathjax.org) which uses client side Javascript for the rendering\n# instead of using pre-rendered bitmaps. Use this if you do not have LaTeX\n# installed or if you want to formulas look prettier in the HTML output. When\n# enabled you may also need to install MathJax separately and configure the path\n# to it using the MATHJAX_RELPATH option.\n# The default value is: NO.\n# This tag requires that the tag GENERATE_HTML is set to YES.\n\nUSE_MATHJAX = NO\n\n# When MathJax is enabled you can set the default output format to be used for\n# the MathJax output. See the MathJax site (see:\n# http://docs.mathjax.org/en/latest/output.html) for more details.\n# Possible values are: HTML-CSS (which is slower, but has the best\n# compatibility), NativeMML (i.e. MathML) and SVG.\n# The default value is: HTML-CSS.\n# This tag requires that the tag USE_MATHJAX is set to YES.\n\nMATHJAX_FORMAT = HTML-CSS\n\n# When MathJax is enabled you need to specify the location relative to the HTML\n# output directory using the MATHJAX_RELPATH option. The destination directory\n# should contain the MathJax.js script. For instance, if the mathjax directory\n# is located at the same level as the HTML output directory, then\n# MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax\n# Content Delivery Network so you can quickly see the result without installing\n# MathJax. However, it is strongly recommended to install a local copy of\n# MathJax from http://www.mathjax.org before deployment.\n# The default value is: http://cdn.mathjax.org/mathjax/latest.\n# This tag requires that the tag USE_MATHJAX is set to YES.\n\nMATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest\n\n# The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax\n# extension names that should be enabled during MathJax rendering. For example\n# MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols\n# This tag requires that the tag USE_MATHJAX is set to YES.\n\nMATHJAX_EXTENSIONS =\n\n# The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces\n# of code that will be used on startup of the MathJax code. See the MathJax site\n# (see: http://docs.mathjax.org/en/latest/output.html) for more details. For an\n# example see the documentation.\n# This tag requires that the tag USE_MATHJAX is set to YES.\n\nMATHJAX_CODEFILE =\n\n# When the SEARCHENGINE tag is enabled doxygen will generate a search box for\n# the HTML output. The underlying search engine uses javascript and DHTML and\n# should work on any modern browser. Note that when using HTML help\n# (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET)\n# there is already a search function so this one should typically be disabled.\n# For large projects the javascript based search engine can be slow, then\n# enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to\n# search using the keyboard; to jump to the search box use + S\n# (what the is depends on the OS and browser, but it is typically\n# , /