EGU2020-7349
https://doi.org/10.5194/egusphere-egu2020-7349
EGU General Assembly 2020
© Author(s) 2020. This work is distributed under
the Creative Commons Attribution 4.0 License.

The emergence of community models in hydrology

Nans Addor1, Martyn P. Clark2, and Brian Henn3
Nans Addor et al.
  • 1Geography, College of Life and Environmental Sciences, Exeter, United Kingdom (n.addor@exeter.ac.uk)
  • 2Centre for Hydrology & Canmore Coldwater Lab, University of Saskatchewan, Canmore, Canada
  • 3Scripps Institution of Oceanography, UC San Diego, United States

Hydrological models (HMs) are essential tools to explore terrestrial water dynamics and to anticipate future hydrological events. Since their inception, HMs have been developed in parallel by different institutions. There is now a plethora of HMs, yet a relative absence of cross-model developments (code is almost never portable between models) and of guidance on model selection (modellers typically stick to the model they are most familiar with). Furthermore, traditional HMs, developed over the last decades by successive code additions, are rarely adapted to modern hydrological challenges, principally because they lack modularity. These HMs typically rely on a single model structure (most processes are simulated by a single set of equations), which make it difficult to i) understand differences between models, ii) run a large ensemble of models, iii) capture the spatial variability of hydrological processes and iv) develop and improve hydrological models in a coordinated fashion across the community.

These limitations can be overcome by modular modelling frameworks (MMFs), which are master templates for model generation. MMFs offer several options for each important modelling decision. They also allow users to add functionalities when they are required, by loading libraries developed and maintained by the community. This presentation uses FUSE (Framework for Understanding Structural Error) as an example of MMF for hydrology. FUSE enables the generation of a myriad of conceptual HMs by recombining elements from four commonly-used models. This presentation will summarize the development of FUSE version 2 (FUSE2), which was created with users in mind and significantly increases the usability and range of applicability of the original FUSE. In FUSE2, NetCDF output files contain a detailed description of the modelling decisions (e.g., selected modules, numerical scheme, parameter values), which improves reproducibility. FUSE2 also makes code re-usable, as modules can be used across the community and are not limited to a single model structure. After decades of siloed model development, we argue that MMFs are essential to develop and improve hydrological models in a coordinated fashion across the community.

How to cite: Addor, N., Clark, M. P., and Henn, B.: The emergence of community models in hydrology, EGU General Assembly 2020, Online, 4–8 May 2020, EGU2020-7349, https://doi.org/10.5194/egusphere-egu2020-7349, 2020

Comments on the presentation

AC: Author Comment | CC: Community Comment | Report abuse

Presentation version 1 – uploaded on 01 May 2020
  • CC2: Are we yet again reinventing the wheel?, Tobias Pilz, 11 May 2020

    Dear authors,

    thank you for your interesting contribution.

    1) You mention your code being on github, i.e. a tool for FUSE in R and the Fortran code of FUSE. Do you have a link already or is it not yet published?

    2) I am in favour of flexible / modular model frameworks, but it also looks like the number of such frameworks is now increasing. Are we therefore heading for the same issues as for the plethora of models with fixed structures, e.g. a large pool of alternatives where legacy rather than adequacy drives the selection of the framework? Or can all or at least some of them have legitimation, e.g. when competing modelling philosophies (conceptual vs. process-based, lumped vs. (semi-)distributed frameworks, etc.) are incorporated or they have different features (programming language, GUI vs. text-based, etc.)? But how can we then avoid ending up with a hundred of alternative frameworks in the next 10 years and reinventing the wheel yet again?

    Kind regards,

    Tobias

    • AC1: Reply to CC2, Nans Addor, 12 May 2020

      Dear Tobias,

      Thank you for your comments and questions.

      1) The FUSE code is on GitHub indeed (https://github.com/naddor/fuse/) and the tools for FUSE are too (https://github.com/naddor/tofu) - the links were not included in the slides because it is still work in progress but you are welcome to have a look.

      2) Yes, there are now a few modular frameworks out there, and there are, as you note, quite clear differences between them, which makes them fit for different purposes (adequate for different users and applications). I see current frameworks as complementary, I believe this diversity is good, and there might well be several community models emerging. Will we have "a hundred of alternative frameworks in the next 10 years”? Hard to tell, the modularity of these frameworks enables developers to collaborate and work on the same framework instead of developing many models in parallel, so if these frameworks are adopted by hydrologists (not quite the case yet), the number of frameworks that are actively used should stay manageable.

       
      Best,

      Nans
      • CC3: There will be a lot of framework out there ?, Riccardo Rigon, 12 May 2020

        Dear Tobiaz,

        the real "frameworks" are not so many: FUSE - SUMMA - SUPERFLEX now going into PyFLEX (see the presentation by Marco Dal Molin), GEOframe (, For learning material: ) based on OMSv3 (), ESMF (https://en.wikipedia.org/wiki/Earth_System_Modeling_Framework),  CSDMS (), and some others I do not know about. These are frameworks, other are collections of models, often implemented in commercial platforms like Matlab. The latter are "per se" a framework.  (1) I think the first important characteristics they should have to be really not considered "vaporware" is that they are distributed along with sufficient documentation on a public repository.  (2) Better if they are Open Source distributed. (3) Even better if the software could be revisioned too, for instance in JOSS ().

        They usually differ by the language they are implemented (C/C++, FORTRAN, Java, Python etc) and the services they provide. Usually people who promoted them have strong opinion of what is a good modelling platform and they are not willing to change because they probably invested a lot of energies in what they did.

        The science the frameworks convey should be sound but and this is usually guaranteed (but I would not give for granted) by publications in appropriate journals. 

        Said that I would prefer if  there should be some effort for convergence, at least for treating the data in input and output (for this scope a promising tool are the Jupyter Notebooks and the fast growing number of Python tools associated to them) and an intersting approach is the Basic Model interface https://meetingorganizer.copernicus.org/EGU2020/EGU2020-12488.html, which unfortunately was not presented at the assembly.

        These my 2 cents

        ric