HydroBOT demonstration
This website, the associated github repository, and Holt et al. (2025) provide examples of using HydroBOT in various ways, as well as its capabilities and pitfalls. To install and use, see get started.
HydroBOT has several goals, and provides workflow and analysis capabilities to achieve them. It treats scenario comparison as a first-class objective, and so is structured to automate over many scenarios, performing the same processing to each, followed by comparison across scenarios (though it can run single scenarios if desired). It produces metadata files to document settings at each step, which double as runnable parameter files for reproducibility.
HydroBOT is built to provide general capacity for synthesis, to then be tailored for specific analysis: what questions are being asked of the scenarios, what synthesis do they need, and how should they be compared. It is designed to be modular, incorporating many different response models, though at this point it contains only one module. It provides important guardrails for both module idiosyncrasies and multidimensional scaling.
Users should consider the various capabilities demonstrated here, and then develop a streamlined flow with just those parameters relevant to the particular analysis.
This website is a demonstration of HydroBOT functionality. As such, it uses a set of extremely simple demonstration scenarios, and the majority of analyses model ecological responses to them with the Environmental Water Requirements (EWR) Tool, maintained by the Murray-Darling Basin Authority. HydroBOT is not limited to these particular scenarios or the EWR tool.
HydroBOT can take any set of hydrographs representing any set of scenarios as input, provided they match gauges for which response models exist. Thus, HydroBOT can be used for analysis of a wide range of hydrologic scenarios across many different projects. Generation of hydrographs representing various scenarios is not part of HydroBOT, instead, HydroBOT ingests hydrologic scenarios and models response to them. In use, users would supply meaningful scenarios.
Please see additional detail about the demonstration scenarios and EWR tool and associated outcome levels, particularly for information about terminology and context of the examples presented here.
Workflow
The basic workflow of HydroBOT involves identifying and selecting data inputs representing scenarios, running response models, aggregation, scaling, and onward modelling of those outputs, and finally synthesis and production of output figures, tables, and other products. In concept, the HydroBOT workflow is split into three components: the controller which points to data and runs response models, the aggregator which scales the outputs of those models in space, time, and along causal networks, and the comparer which synthesises and produces interpretable outputs.
There are many ways to structure this workflow in practice, with examples of full workflows at getting started and here.
In HydroBOT (and hence, this website), we use the word ‘theme’ to refer to the dimension from proximate, granular outcomes (e.g. fish spawning) to larger-scale outcomes such as species, groups of species, or decadal management targets. In the paper describing HydroBOT, this dimension is referred to as ‘value’, representing the use of ‘value’ defined in the sense of an ‘ecological value’, i.e. any social, economic, environmental or cultural asset or function of significance, importance, worth, or use. While that use of ‘value’ is closest to the meaning of this dimension, we do not use it in HydroBOT or here because in describing the functioning of HydroBOT, the word ‘value’ is too easily confused with its meaning as ‘a number’ or even more generally a state, such as the ‘value’ of a function argument. See also the causal network.
Components
Each of the components are discussed in more detail, with this detail used to modify the sorts of workflows in the workflow examples to tailor them for a particular analysis.
Dependencies
HydroBOT relies on external information in three main ways. First, it uses externally-defined response models. It also benefits from causal networks to link those outputs to larger-scale values along the ‘theme’ dimension. Finally, it requires the input scenarios, without which it would have nothing to model from.
-
- Response models estimate responses to hydrological drivers, and are typically developed outside HydroBOT by subject matter experts.
-
- Causal networks are used for aggregation and comparison, but are not part of the flow per se.
-
- Scenario creation is not part of HydroBOT, but scenarios are needed to run HydroBOT
In use, HydroBOT expects that scenario hydrographs are available and the causal networks are defined.
Development
See the repo readme for additional dev info and more complex package installation issues. See the {HydroBOT} repo for development of the package itself.
Acknowledgements
HydroBOT was developed in the climate adaptation theme of the Murray–Darling Water and Environment Research Program, a program of the Murray-Darling Basin Authority. Collaboration with colleagues from Deakin University, CSIRO, and the MDBA were essential to its development and success.