Deltares
JOSS: comments regarding paper
@DirkEilander @hboisgon @markhegnauer
Hi Dirk, Helene, Mark, I have the pleasure to review the JOSS submission. While I still need to look into the code in detail, here already some comments on the actual JOSS software paper. Only a few things, it's overall pretty clear and well written.
Summary
- [ ] why can it be time-consuming to set-up hydro models?
- [ ] what are 'robust modelling practices'?
- [ ] I am struggling to understand how HydroMT is. Is it an interface that can be implemented into other models (i.e. models support HydroMT) Or can other models be added to HydroMT, i.e. HydroMT supports these models? Maybe it's just semantics, but it would be good to state it less ambigious.
Statement of need
Much of this section (esp. the first paragraph) covers the need for better data (e.g. through improved satellite instruments) and standardized input file-formats. In that way, HydroMT does not solve these challenges, but rather offers a solution to the syndroms not the problem. From that, I cannot directly derive the need for HydroMT.
The aspects mentioned in paragraphs 2 and 3 should thus be discussed more prominently. From what I understand, it is the easier set-up of models and workflows for a wide range of (different) models that makes HydroMT stands out. For what reasons would these aspects be needed? Maybe FAIR software principles and their increasingly important role in academia, or the need for model transparency in the policy-making context (just to name a few).
Functionality
In 'methods and workflow', a Figure 4.1 is mentioned which cannot be found in the paper.
While the Model API is model-agnostic, the ini-file is still model-specific, isn't it? And would the user need to fill the ini-file with information or is this information added from the Data Adapter on-the-fly?
@JannisHoch
Many thanks for the helpful review Jannis! In this comment we provide a first response to your review which I will follow up with a commit to the branch where we apply the changes to the manuscript.
Summary
why can it be time-consuming to set-up hydro models?
Hydro models typically requires a large set of parameters that are derived from different datasets and hence the manual setup can be very time consuming and hard to reproduce.
what are 'robust modelling practices'?
In this case we refer to model sensitivity analysis or model calibration as mentioned earlier in that sentence. I've add a linking word to clarify.
I am struggling to understand how HydroMT is. Is it an interface that can be implemented into other models (i.e. models support HydroMT) Or can other models be added to HydroMT, i.e. HydroMT supports these models? Maybe it's just semantics, but it would be good to state it less ambiguous.
HydroMT provides a general model interface to any hydro model. However, to be able to read and write model specific data formats and parse this to the model interface additional methods might be required. These are supported through the plugin infrastructure which allows users to build a specific HydroMT model class for their own model building on the general HydroMT model classes.
Statement of need
Much of this section (esp. the first paragraph) covers the need for better data (e.g. through improved satellite instruments) and standardized input file-formats. In that way, HydroMT does not solve these challenges, but rather offers a solution to the syndroms not the problem. From that, I cannot directly derive the need for HydroMT.
We agree with the reviewer that HydoMT does not solve the challenge of many data formats or need for better data nor does it try to. The challenge we try to address is to make it easier to work with these data regardless the data format or size by using a generic python interface to different types of data and automating workflows to process these data.
The aspects mentioned in paragraphs 2 and 3 should thus be discussed more prominently. From what I understand, it is the easier set-up of models and workflows for a wide range of (different) models that makes HydroMT stands out. For what reasons would these aspects be needed? Maybe FAIR software principles and their increasingly important role in academia, or the need for model transparency in the policy-making context (just to name a few).
Thanks for this suggestion. We have added a short paragraph to highlight these aspects.
Functionality
In 'methods and workflow', a Figure 4.1 is mentioned which cannot be found in the paper.
Thanks for noticing. This should refer to Figure 1 and has been fixed
While the Model API is model-agnostic, the ini-file is still model-specific, isn't it? And would the user need to fill the ini-file with information or is this information added from the Data Adapter on-the-fly?
The ini file indeed represents a model-specific recipe to build a model and this is where the modeler can make choices how to best setup the model. It lists the workflows and their arguments in order of execution and in combination with the data catalog file provides a reproducible recipe to build a model. For some models default ini files can be prepared in combination with a default data catalog. This cannot and should not be automatized however as it contains this several modelers choices for how to build the model.
