the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 10 Oct 2024
NMP-Hydro 1.0: a C# language and Windows System based Ecohydrological Model Derived from Noah-MP
Abstract. The community Noah with multi-parameterization options (Noah-MP) land surface model (LSM) that is widely used in studies from uncoupled land surface hydrometeorology and ecohydrology to coupled weather and climate predictions. In this study, we developed NMP-Hydro, a hydrological model written in CSharp(C#). NMP-Hydro was developed by faithfully translating the FORTRAN version Noah-MP from the uncoupled WRF-Hydro 3.0, and was coupled with a river routing model. NMP-Hydro exhibits the capacity of parallel execution on Windows systems, utilizing the multi-core CPUs commonly available in today's personal computers. The code of NMP-Hydro has been rigorously tested to ensure that it produces a high-degree of consistency with the simulation output of the original WRF-Hydro. High-resolution (6 km) simulations were conducted and assessed over a grid domain covering the entire Yellow River Basin and the most part of North China. The spatial maps and temporal variations of many state variables simulated by NMP-Hydro and WRF-Hydro/Noah-MP demonstrate consistent results, with occasionally minor discrepancies. The river discharge for the Yellow River under various scheme combinations of six Noah-MP parameterizations exhibits general close agreement with the natural river discharge at the Lanzhou station. NMP-Hydro can be regarded as a reliable replica of Noah-MP in WRF-Hydro 3.0, but it can leverage the modern, powerful, and user-friendly features brought by the C # language to significantly improve the efficiency of the model users and developers.
- Preprint
(3018 KB) - Metadata XML
-
Supplement
(59176 KB) - BibTeX
- EndNote
Status: final response (author comments only)
-
CEC1: 'Comment on gmd-2024-168', Juan Antonio Añel, 30 Oct 2024
Dear authors,
Unfortunately, after checking your manuscript, it has come to our attention that it does not comply with our "Code and Data Policy".
https://www.geoscientific-model-development.net/policies/code_and_data_policy.htmlYou have archived your code on GitHub. However, GitHub is not a suitable repository for scientific publication. GitHub itself instructs authors to use other long-term archival and publishing alternatives, such as Zenodo. Therefore, the current situation with your manuscript is irregular. Please, publish your code in one of the appropriate repositories and reply to this comment with the relevant information (link and a permanent identifier for it (e.g. DOI)) as soon as possible, as we can not accept manuscripts in Discussions that do not comply with our policy. Also, please include the relevant primary input/output data.
In this way, if you do not fix this problem, we will have to reject your manuscript for publication in our journal.
Also, you must include the modified 'Code and Data Availability' section in a potentially reviewed manuscript, the link and DOI of the new repository for the code (also for the dataset if necessary).
Juan A. Añel
Geosci. Model Dev. Executive EditorCitation: https://doi.org/10.5194/gmd-2024-168-CEC1 -
AC1: 'Reply on CEC1', Yonghe Liu, 10 Nov 2024
Dear Juan A. Añel,
I have published the source code to the Science Data Bank (https://www.scidb.cn/en, the same site for publishing the benchmarking dataset) with a DOI: https://doi.org/10.57760/sciencedb.16102.
In our country (China), it is difficult to access Zenodo.
Accordingly, I have modified the following section:
Code and data availability. 1. The NMP-Hydro model code is available at https://doi.org/10.57760/sciencedb.16102 (Liu, 2024a). 2. The Noah-MP technical documentation is available at the same site and more details will continue to be added in the documentation. 3. The benchmark meteorological datasets for driving NMP-Hydro and WRF-Hydro 3.0 were uploaded to the Science Data Bank (DOI: https://doi.org/10.57760/sciencedb.13122 (Liu, 2024b)).
If you do not agree our publication of the source data at Science Data Bank, then we should find another available website that we can access. I expect your further comment.
Thank you very much.
Yonghe Liu
Citation: https://doi.org/10.5194/gmd-2024-168-AC1 -
CEC2: 'Reply on AC1', Juan Antonio Añel, 10 Nov 2024
Dear authors,
Many thanks for addressing this issue so quickly. We can consider now the current version of your manuscript in compliance with the code policy of our journal.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/gmd-2024-168-CEC2 -
AC3: 'Reply on CEC2', Yonghe Liu, 13 Nov 2024
Dear Juan A. Añel,
Thanks for your response.
Yonghe
Citation: https://doi.org/10.5194/gmd-2024-168-AC3
-
AC3: 'Reply on CEC2', Yonghe Liu, 13 Nov 2024
-
CEC2: 'Reply on AC1', Juan Antonio Añel, 10 Nov 2024
-
AC1: 'Reply on CEC1', Yonghe Liu, 10 Nov 2024
-
RC1: 'Comment on gmd-2024-168', Anonymous Referee #1, 01 Nov 2024
The authors developed a hydrological model written in CSharp(C#), called NMP-Hydro 1.0, by translating the FORTRAN version Noah-MP from the uncoupled WRF-Hydro 3.0 and coupling it with a river routing model. This new NMP has the capacity of execution on Windows systems, utilizing the multi-core CPUs commonly available in today's personal computers. The code of NMP-Hydro has been tested to ensure that it produces a high-degree of consistency with the output of the original WRF-Hydro. Overall, this model development effort provides a very useful modeling tool and is important to broaden the Noah-MP community in various applications. The manuscript is generally well organized and is a good fit to GMD. I would recommend publication after the authors address my comments and suggestions.
Specific comments:
- Is there any statistics for the number of users of C language vs FORTRAN language to highlight the need of developing a C-based model system?
- Table 1 caption and related text in the manuscript: please clarify that this is the Noah-MP model version in WRF-Hydro v3.0 not the latest community Noah-MP model version.
- Does the river routing model have to run at the same spatial and temporal resolution as the main Noah-MP column model?
- What are the required input data for the river routing model in addition to those needed by Noah-MP column model?
- What are the reasons for the difference between the two models? Theoretically speaking, they should produce exactly the same results due to the same equations and input data.
- What is the difference in the computational efficiency between the C-based and FORTRAN-based model codes?
- There are a few important state variables that were not compared between the two models, including soil moisture, soil temperature, snow water equivalent, and snow depth.
- Lines 250-264: What are the causes for these large differences in runoff, temperature, radiation, and exchange coefficient?
- Lines 271-273: These differences seem too large for precision errors. Usually, if it is single precision, they would only differ in the 7th digit after the decimal point. Did the authors see any difference between the two models for all output fields in the first few (e.g., 10) model timesteps? If not, then maybe the precision error growth in a longer-period run would contribute to such difference. What model timestep did the authors use? Would reducing the model timestep (i.e., smaller numerical integration errors) lead to more consistency between the two models?
- Is there two-way feedback between Noah-MP and the river routing scheme, or is it just Noah-MP affecting river routing results? Did the authors also see difference between the two Noah-MP models without activating river routing scheme?
- It would be helpful if the authors could discuss a bit the future plans for applying and/or further improving the NMP-Hydro model and potential connection to the broader Noah-MP community.
Citation: https://doi.org/10.5194/gmd-2024-168-RC1 -
AC2: 'Reply on RC1', Yonghe Liu, 10 Nov 2024
Dear Referee #1,
Thank you for providing good comments to improve the manuscript.
Specific comments:
- Is there any statistics for the number of users of C language vs FORTRAN language to highlight the need of developing a C-based model system?
Reply: Here, “C language” is a misspelling, while C# language is correct. According to the TIOBE Programming Community Index (www.tiobe.com) for October 2024, C# is the fifth most popular of all major programming languages, with 5.6% of users, while FORTRAN is the ninth most popular, with 1.8% of users.
After our careful thinking, these statistics will not be present in the manuscript, because the number of the language users is not the main reason to reconstruct the model. The main reason is that C# is a modern and powerful language, and is easy to use (by taking advantage of many powerful code analysis tools for C#), while FORTRAN is a traditional old-style language, which is more difficult to use for many users, due to limited code analysis tools.
- Table 1 caption and related text in the manuscript: please clarify that this is the Noah-MP model version in WRF-Hydro v3.0 not the latest community Noah-MP model version.
Reply: The caption is now changed to “Figure 1. The architectural diagram of NMP-Hydro (a) and the conversion of FORTRAN arrays to C# arrays (b). NMP-Hydro is a reconstructed replica of the version of Noah-MP that is coupled in WRF-Hydro 3.0. “
The related text in the manuscript is also minorly modified now. Generally, the original description has mentioned the version.
- Does the river routing model have to run at the same spatial and temporal resolution as the main Noah-MP column model?
Reply: according to this comment, we have added following paragraph in section 3.2:
“This module requires two additional inputs files, a river segment list file named ‘ChannelOrder.txt’ and a ‘namelist.txt’ file. The latter file is used to set parameters and the length of time step. Each river segment in the list file presents following information: its own index, the index of its next downstream river segment, the row number and the column number of the grid box (in Noah-MP’s running domain) providing runoff input to the current segment, the length (m) of the current river segment, the two parameter values (K and X) of the Muskingum method, the area of the catchment of the current segment. Each river segment upstream of other segments must be listed ahead of all its downstream segments. The river segment list can be derived from both gridded river network or vectorized river network. The resolution of the river routing is determined by the original river network from which river segment list is derived. Therefore, the choice of using vector river network or gridded river network and the selection of spatial resolution are completely determined by the river segment list file which is provided by the users. The length of the temporal step of the river routing is required to be multiple times shorter than the time step for running the Noah-MP, and can also be designated by the users. In our application, the time step of routing is set to 600s or 900s, while the time step for Noah-MP LSM is set to 3 hours. “
This description clearly states that the spatial resolution of the river routing model can be determined by the river segment list file. And the time step can be set by users. Therefore, both the spatial and temporal resolution can be very different to the Noah-MP column model.
- What are the required input data for the river routing model in addition to those needed by Noah-MP column model?
Reply: “This module requires two additional inputs files, a river segment list file named ‘ChannelOrder.txt’ and a ‘namelist.txt’ file for setting parameters.”
- What are the reasons for the difference between the two models? Theoretically speaking, they should produce exactly the same results due to the same equations and input data.
Reply: We feel very sorry for that the reasons of the difference between the two models is now unknown. We agree with your comment that the models should produce exactly the same results due to the same equations and input data. However, the equations must be implemented by the programming code. The difference between the C# platform and the Fortran platform is complex, while the Noah-MP model is not a simple model but a model with tens thousands of lines, which made the model very difficult for us to discern where the difference is coming from. Therefore, to find the reason of the difference seems highly beyond our ability at this stage.
- What is the difference in the computational efficiency between the C-based and FORTRAN-based model codes?
Reply: We must admit that the C# language (not the C language in the above misspelling) is slower than the Fortran language. According to our experience, for running a time step of non-parallel WRF-Hydro (the original Noah-MP model) and the non-parallel NMP-Hydro (our newly developed model) on our laptops, the former seems taking less time than the latter. But the parallel running of NMP-Hydro is faster than a non-parallel WRF-Hydro. However, benchmarking comparison is difficult for us to made because the two models usually running on different platforms (operation systems) and computers.
Pursuing higher computational efficiency is not in our goal for reconstructing the Noah-MP model. Therefore, we will not present much discussion on this topic. For most cases, the computational efficiency is not a critical issue, because the difference is always small and acceptable.
- There are a few important state variables that were not compared between the two models, including soil moisture, soil temperature, snow water equivalent, and snow depth.
Reply: There are indeed many important state variables need to concern. In this revision, we have provided the comparison of soil water content, soil temperature, snow water equivalent and snow depth in supplementary material. These variables generally show similar effects as the variables that are presented in the main manuscript. Corresponding description was now added to the manuscript.
Due to our limited energy, we cannot provide the tests on all of them and on everywhere. Consider that these variables are interconnected, the benchmark differences for other variables actually can be indirectly reflected by the results of the presented variables.
- Lines 250-264: What are the causes for these large differences in runoff, temperature, radiation, and exchange coefficient?
Reply: We must admit that the causes are unknown and is difficult to discern now (if we know the reason, we will not leave these differences until the submitting of this manuscript). So, we feel very sorry for our inability. At this stage, we need much more users to help us to find the causes.
- Lines 271-273: These differences seem too large for precision errors. Usually, if it is single precision, they would only differ in the 7th digit after the decimal point. Did the authors see any difference between the two models for all output fields in the first few (e.g., 10) model timesteps? If not, then maybe the precision error growth in a longer-period run would contribute to such difference. What model timestep did the authors use? Would reducing the model timestep (i.e., smaller numerical integration errors) lead to more consistency between the two models?
Reply: Thanks for your recommendation to solve the difference issue of the two models.
However, actually, during our efforts of more than five years (Dec. 2018 to now (Sep. 2024)), we have compared the two models in step-by-step running on multiple grid-boxes, in the first 3-time steps. We find that mostly the differences are very small. We found that there were significant calculation errors (small but cannot be regarded as wrong) after multiple iterations in the VEG-FLUX function (especially in TV and TG calculations), but due to the iteration, it was difficult to figure out whether the error came from because there were many variables in the function and the code was lengthy and iterative. However, according to the comparison of output results, in fact, Both TV and TG have very small errors between the two models.
All the LSM simulation is based on a 3-hourly timestep. We do not believe that reducing the model time step can get better consistency, because the Noah-MP is not a partial differential equation-based model (unlike that in climate models) and there is no numerical integration concept here.
In the manuscript, we have pointed out that the error mainly occurs in winter months. If the error is not a simple floating-point error accumulation, it must be related to the freezing of water, but we have not found the inconsistency in the code. Theoretically, some inconsistent parameter settings may also cause large inconsistency.
- Is there two-way feedback between Noah-MP and the river routing scheme, or is it just Noah-MP affecting river routing results? Did the authors also see difference between the two Noah-MP models without activating river routing scheme?
Reply: There is no feedback from the river routing module to the Noah-MP LSM, therefore, the difference is unrelated to the river routing module.
- It would be helpful if the authors could discuss a bit the future plans for applying and/or further improving the NMP-Hydro model and potential connection to the broader Noah-MP community.
Reply: According to this recommendation, a new paragraph was added to the ‘conclusion’ section:
“This new software can run on Windows system platforms. Its C# code can be analyzed and visually browsed using many modern intelligent tools such as those in Sharpdevelop (https://github.com/icsharpcode/SharpDevelop) or Microsoft Visual Studio. The code of NMP-Hydro is easier to analyze, study and modify, which in turn will attract more users and promote the future development of the Noah-MP model. The current version of NMP-Hydro can serve as a good model for simulating land surface processes in climate change and ecohydrology research. Although NMP-Hydro cannot be coupled with the WRF model, it can still be used as a prototype system of Noah-MP to improve the Noah-MP schemes. Any new improvements in NMP-Hydro can easily be updated to other FORTRAN based Noah-MP. Future plans for the development of NMP-Hydro include (1) investigating whether the remaining differences between NMP-Hydro and the original WRF-Hydro 3.0 are caused by floating-point errors or other bugs in the code; (2) providing a single-column run mode and incorporating a genetic algorithm-based parameter optimization module; (3) extending the functionality for modelling dynamic vegetation by designing new schemes or optimizing parameters.”
We have revised the manuscript in a moderately deep extent, according to your comment.
Here, we upload a supplement file, but the revised manuscript is not allowed to upload here (this is required by the system. I do not understand why). Maybe we can upload the revised manuscript in a later chance.
If you have further comment, please let us know.
Thank you very much.
Yonghe Liu
- AC4: 'A new response on RC1', Yonghe Liu, 20 Dec 2024
- RC2: 'Comment on gmd-2024-168', Anonymous Referee #2, 29 Nov 2024
- RC3: 'Comment on gmd-2024-168', Anonymous Referee #3, 06 Dec 2024
Viewed
| HTML | XML | Total | Supplement | BibTeX | EndNote | |
|---|---|---|---|---|---|---|
| 311 | 86 | 40 | 437 | 39 | 6 | 5 |
- HTML: 311
- PDF: 86
- XML: 40
- Total: 437
- Supplement: 39
- BibTeX: 6
- EndNote: 5
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1