As there are no real DEs in hydrology to date, our analysis refers to the most used hydrological models as a starting point. Their history shows that there is a fragmentation of models and that “legacy more than adequacy” is the rule for researchers when choosing an application . Models like SWAT , HEC-HMS , SWMM , and the TOPMODEL family or the good old reservoir models have the lion’s share among users. These models usually provide a good balance between usability and reliability (in the sense that they produce plausible patterns and have no or few running issues). The current state of hydrological science allows us to say that all of these models work, at least for the purposes that they were requested, but they are normally closed to easy modification and tend to lag behind the state of the art of hydrological studies. The state of the art, on the other hand, often makes use of artisanal products, restricted by badly engineered codes, in the hands of a few researchers, and it is not designed for the general reuse that the DE paradigm would require. Many modular frameworks have recently been built with the aim to filling this gap, like SUMMA , SuperflexPy , GEOframe and Raven . However, from the points of view of both researchers and users, a further quantum leap must be made in model infrastructure design and model implementations to cope with the DARTH requirements that are addressed in the paper.

Broadly speaking, four mathematical tools dominate in hydrological modeling research : process-based (PB) models , reservoir-type models (HDSs, as hydrological dynamical systems) , classical statistical models (SMs) and current algorithmic–statistical models that make use of one form of machine learning . To these we could add a further type of model: a tight black box between Earth observations and lumped models and/or machine learning models, usually referred as EO products . Many references already discuss the taxonomy of models (e.g., ), the strengths and weaknesses of each of these approaches (), and their application at various scales of application, and we do not want to add further to those analyses. We just adopt the pragmatic view that they exist; that, notwithstanding their uncertain informatics quality (except maybe for the ML tools that are based on the use of large frameworks), they are used creatively; and that they still continue to produce insights that solve hydrological issues.

All of these models rely on parameter calibration or on some type of “learning” to make their predictions realistic . At present, it is impossible to disentangle the complexity of the model variety and make it simpler. The matter of hydrology and Earth system sciences is complex (in the sense of the complexity sciences) and complicated (affected by huge variability and heterogeneity); thus, whatever it takes to get a clue should be welcomed. This statement, however, implies that we cannot have a DARTH in which just one “solution” is adopted, rather we need a DARTH where many, even competing, paradigms (like PB modeling, ML tools and traditional lumped models) can be tested, compared and eventually put to work together to assess the uncertainty in forecasting. This, in turn, has consequences with respect to the code architectures, infrastructures and the informatics that have to be deployed. Some naive ideas that ML plus EOs, for instance, could do it all, like some Google Earth-like applications seem to envision, is just wishful thinking that clashes with the current view that we have of the discipline. Instead, the idea that different models (or model structures) have to be used and subjected to hypothesis testing procedures has gained ground , even in ML .

Recently, in fact, it has become clear that ML and deep learning (DL) techniques can be interpreted and explained (); thus, they can be used as a tool for understanding (the process) or model parameter learning , instead of primarily for predictive purposes. In any case, ML growth has been mostly driven by a large variety of problems, for instance, computer vision applications, and speech and natural language processing in a way that has to be harmonized with the practices of more traditional ways of conceiving hydrological models.

If the model paradigms cannot be compressed in favor of one choice, a suitable DARTH engine should allow for the implementation of various paradigms, and more than one competing DARTH engine should be made available in the community because the implemented technologies also come with their own legacies.

Just as life on Earth is built upon the four nucleotide bricks and presents an immense variety, it is clearly possible that DARTHs can share common protocols, standards and features and that they can evolve, picking up the best without a continuous recreation of the whole infrastructure from scratch. That is to say, promoting diversity should be accompanied by the sharing of standards for the parts. The way to do it has been traced, for instance, in , who argued that the whole models informatics can be separated into model-agnostic parts, which potentially can be shared, and model-specific parts, which could be differentiated among the various developers or research groups.

It should be stressed, however, that according to their own definition, DARTHs are not simply hydrological models. Models made by scientists are usually developed to test their theoretical works or to provide evidence for research publication; as such, they do not have software quality as their primary goal. DARTHs have models at their scientific core but, according to the vision we promote, they need to provide other services too, including

being available on demand, working seamlessly on the cloud as web services;

A good practice in object-oriented programming is the separation of concerns , which states that any class should have possibly only one responsibility. This approach seems reasonable in this context too, and, in the following, we will try to break down the DARTHs into their main compositional parts.

DARTHs, obviously, are useless if there are no data available to run them; therefore, we briefly discuss some of the data aspects relevant to envisioning their design. There is a frequent lack of institutional and political will to publish environmental data, sometimes for reasons of national security and other times to prevent misuse or for confidentiality. This state of affairs creates many obstacles, and open spatial data infrastructures (open SDIs) are still not common . This contrasts with the literature that, for some years now, has forecast a data-rich era for hydrology, coining neologisms like datafication with reference to the upcoming ubiquitous presence of the Internet of Things (IoT) even in natural contexts. However, environmental data are public and supported by various initiatives in the US; in other countries, i.e., in Austria (e.g., https://ehyd.gv.at, last access: 23 September 2022), France (e.g., https://www.hydro.eaufrance.fr/, last access: 23 September 2022), Germany (e.g., https://www.giz.de/de/html/index.html, last access: 23 September 2022), and the UK (e.g., https://archive.ceda.ac.uk, last access: 23 September 2022), there are projects that aim to make the largest possible amount of data open to users, but data availability sometimes requires the payment of a fee. Since the survey by , there have been various initiatives to fill the gaps by various institutions, such as the Global Runoff Data Center (GRDC, http://www.bafg.de/GRDC, last access: 23 September 2022); the Global Water Monitoring System (GWMS, http://www.gemstat.org, last access: 23 September 2022); the Global Earth Observation System of Systems (GEOSS, https://earthobservations.org/geoss.php, last access: 23 September 2022); the World Meteorological Organization (WMO) Hydrological Observing system (WHOS); and, more recently, the Destination Earth architecture. It is also worth mentioning the bottom-up effort started with the Catchment Attributes and MEteorology for Large-sample Studies (CAMELS) datasets . Meanwhile, the Open Geospatial Consortium (OGC) has seeded several projects (https://www.ogc.org/node/1535, last access: 23 September 2022) to establish standards for the delivery and deployment of data related to hydrology. A review of initiatives, topics and issues can be seen in and visionary perspectives are presented in , to which we cannot add more. It is clear, however, that the general situation is still largely placed in between “fragmentation and wholeness” ; this can only be resolved with general agreements and consensus about the usefulness of sharing data and time, without forgetting the question of providing the appropriate ground-based data for the needs of developing countries.

To complicate the matter, the new developments in satellite remote sensing have been producing massive amounts of data at unprecedented spatial and temporal resolutions. According to statistical data from the Committee on Earth Observation Satellites (CEOS), over 500 EO satellites have been launched in the last half-century, and more than 150 new satellites will be in orbit in the near future . For instance, data from missions like Sentinel of the new European Copernicus Earth observation program (https://sentinels.copernicus.eu, last access: 23 September 2022) have already exceeded petabytes of volume. More and more data are expected to come: the American, Japanese, Indian, Chinese and European space agencies have already planned new missions for observing the planet. Notable examples are the NASA Cyclone Global Navigation Satellite System (CYGNSS) and Surface Water and Ocean Topography (SWOT) missions (https://swot.jpl.nasa.gov/mission/overview/, last access: 23 September 2022), the US–Indian NASA-ISRO Synthetic Aperture Radar (SAR) mission , the Radar Observing System for Europe in L-band (ROSE-L) SAR missions, and the Thermal InfraRed Imaging Satellite for High-resolution Natural resource Assessment (TRISHNA) , in addition to a constellation of low-cost commercial CubeSats .

So the question of how these data can be easily accessed and used by DARTHs is not a trivial one. Interesting solutions to facilitate this already exist, such as the Google Earth Engine (https://earthengine.google.com, last access: 23 September 2022) and the newly developed European OpenEO platform (https://openeo.cloud, last access: 23 September 2022). These Earth observation data centers have revolutionized the way users interact with EO data and offer integrated solutions to access large volumes of a variety of EO data with relatively high speed. With this new paradigm of “bringing the users to the data”, users no longer need to download and store large volumes of EO data, and they do not have the problem of dealing with the different formats and grids made available by the range of data providers. DARTHs should, therefore, provide an easy integration with these new platforms to facilitate the use of the wealth of data made available by the various Earth observation programs.

The state of art of the matter, for what can be important for DARTHs, is that data layers have to be somewhat loosely coupled to models via a brokering approach, where some intermediate tool takes care of discovering, gathering and delivering data according to what is requested. This approach has been successfully tested in the recent past and allows the binding of heterogeneous resources from different providers. It is, for instance, at the core of the Destination Earth infrastructure and data space https://digital-strategy.ec.europa.eu/en/policies/destination-earth (last access: 23 September 2022).

A recent conference contribution cites a few examples of brokers: WHOSWHOS, CUAHSI HydroDesktop (through CUAHSI WaterOneFlow), National Water Institute of Argentina (INA) node.js WaterML client (through CUAHSI WaterOneFlow), DAB JS API (through DAB REST API), USGS GWIS JS API plotting library (through RDB service), R scripts (through R WaterML library), C# applications (through CUAHSI WaterOneFlow) and UCAR jOAI (through OAI-PMH/WIGOS metadata). At present, both in research and in applications, the action of matching data and models is done offline by the researchers, but the DARTH vision would require that these data be automatically ingested and processed. Therefore, DARTHs should take care of these aspects by design and be able to abstract data from the algorithms, as also explained in .

Regarding the data sharing/use as well as the fact that chunks of DARTHs could be distributed for inspection and modification by third parties, two strategies could be used. In the ideal situation, where there is a universal broker that (as a provided service) collects required data from the cloud in real time, DARTHs should include a connector to this broker so that all modeling could be performed smoothly (the cloud strategy). The opposite approach is that data are acquired once and for all and are stored locally (the local strategy). The local strategy is clearly unfeasible, due to the burden of data, while the cloud strategy is clearly still immature, even if ML has recently introduced new paradigms in data treatment such as the Apache Hadoop or Apache Spark distributed platforms to facilitate these types of operations.

At a lower level of implementation, the issue of data treatment is managed through the standardization of formats. Standards have been developed for various scopes, including GRIB , NetCDF , HDF5 and database formats. Other, general-purpose standards, like Apache Arrow (https://arrow.apache.org/, last access: 23 September 2022) for tabular data, can be an interesting choice and come with various interfaces to the most common programming languages, thereby allowing for easier compatibility with existing models.

We are not claiming here that some formats should be preferable to others. However, a format and database architecture should be chosen as a starting point, along with a set of tools to transport data from the chosen format to other formats. The data format itself should be self-explicative and not require additional information to be understood. A long experience in this direction is available from UNIDATA (https://www.unidata.ucar.edu/, last access: 23 September 2022), from the WMO, from the ESA and from NASA. For any DARTH builder, therefore, it should not be difficult to agree on some conventional formats to start with coherently.

As realized, there are different types of users and different types of scopes when modeling hydrology; these are summarized in Fig. .

Hard coders (core coders) are those who actually design and write code. Soft coders are those who just modify existing codes and, if possible, develop plug-ins using public application programming interfaces (APIs). Linkers are power users who assemble existing codes through scripting languages or procedures. This role is of particular importance in ML, as Earth scientists very often build their models on top of ML engines provided by big companies or institutions . Runners (users) are those who execute existing codes. They just modify inputs, outputs and parameters, and they create and define scenarios. Players run scenarios and make analyses. Viewers view the players’ results, having a low level of interaction with the framework, and maybe use them to instantiate policies. Providers provide inputs and data to all other user roles (and what was said in the previous section applies to them). The users’ names are self-explanatory. In this paper, we concentrate on the specific roles of coders, linkers and runners with respect to technical and research users. We also have to mention that, even if hard coders seem the most basic of developers, they can be classified as “professional end user developers” . Scientists and engineers developing software have backgrounds in the theoretical models implemented in software, but they do not usually have a strong background or formal training in computer science nor software engineering (while computer scientists, in contrast, are not usually domain experts). The coders that we are referring to here are not usually computer scientists, instead they are domain experts (i.e., hydro-, bio- and/or geo-experts) with a limited computer science background.

To serve the needs of all of those roles and users, besides the scopes inherent to the DARTH vision itself, DARTHs need to be supported by an appropriately modular software infrastructure able to manage the different needs that each user and role has. In addition, in thinking of coders/researchers, a DARTH infrastructure should be able to accept different modeling styles and programming paradigm changes, and DARTHs have to facilitate good programming and testing practices, bridging the knowledge gap of scientists/hydrologists in computer science. Having readable code is something that cannot be renounced . It is a key aspect for a successful long-term development of the code: it improves maintainability and reusability , it saves time in the future, and eases the development and growth of the research community . This topic is further discussed in Sect. 2.4.

As we are aiming to gather a community of developers to build and evolve a DARTH, the code must work seamlessly on the major operating systems (MS Windows, macOS, Linux or others), and this excludes efforts limited to one platform. Besides being programming-language-agnostic, the foreseen DARTHs have to be operating-system-agnostic. It seems a secondary limitation, but, in the present state of the matter, it is certainly not, even if the DE paradigm envisions a type of infrastructure operating over the web that encompasses the characteristics of single machines.

Other consequences follow if we look at the current hydrological models from the coders' position: they are codes written in various programming languages, these days primarily in Fortran, C/C++, Python, R, Java, C#, Julia and MATLAB. The variety of programming languages used brings a legacy that cannot be avoided with a blip, excluding the great part of programming researchers that has been at the core of the evolution of the field. Therefore, DARTHs either (1) need to be based on a platform which, while not being language-agnostic per se (as it is built in a specific language), is able to link libraries in all of the languages or (2) libraries themselves have to evolve to become (web) services, as often happens in ML. Only in this way will it be able to approach the mass of researchers and fully utilize the efforts already undertaken. This would bridge the past and future of hydrological and environmental modeling and make revolutionary changes possible in an incremental way. DARTHs should not subtract, just add and evolve.

There are at least two other model design requirements of DARTHs that have to be accomplished. The first is related to the specification of the data that a model actually uses. We cannot identify the external behavior of a model by saying, for instance, that it needs “precipitation”, but more precision is necessary about the units and the spatial and temporal dimensions. To continue with the given example, we need to specify the form of the precipitation (e.g., liquid-water precipitation), the spatial aggregation (e.g., catchment average), the temporal resolution (e.g., hourly) and the units (e.g., mm). In fact, this problem was raised quite a long time ago when first there was the need to give metadata, explaining what the values in each variable represent, and their spatial and temporal properties. The CF convention (https://cfconventions.org/, last access: 23 September 2022) is one of the attempts to clarify these aspects, followed by other initiatives such as the Basic Model Interface , which contains a “grammar” for creating new names and is more specialized than CF in the hydrological sciences. The success of a DARTH depends on these specifications in which the freedom of choice is sacrificed to the adoption of some standard that makes the models potentially interoperable and discoverable on the web by their input and output requirements. Assuming that one such convention would be adopted by all models, a user would know which models they can connect to obtain the dynamics of a process that they want to estimate or predict. A black-box characterization of models can be done by accurately specifying their inputs and outputs (I/O).

The second is that researchers and the concerned users do not just care about the models' I/O but also about their realism, reliability, replicability and reproducibility, and robustness, characteristics whose meaning is discussed thoroughly in the glossary. This information, which, in part, can be tested a posteriori by use and comparison with real-world observations, can also be gained by inspecting the models’ codes with their implementation details.

In summary, the DARTH architecture must account for various requirements, including

being programming-language-agnostic,

Another characteristic deemed important for DARTH infrastructure is that DARTHs should not be invasive of programming habits (i.e., not forcing the programming to adopt constructs that computer scientists appreciate but scientists and engineers cannot manage). The available environmental modeling frameworks, which are infrastructures to all effects, can be classified into two broad categories: heavyweight frameworks and lightweight frameworks . The former is characterized by large and unwieldy APIs that require a considerable effort from developers (scientists or soft coders) to become familiar them with before writing new code. Moreover, such an effort somehow creates a strict legacy within the infrastructure, and this has limited the diffusion of these systems in the recent past .

Conversely, show how lightweight frameworks have many functions for the developer due to the techniques used to reduce the overall size of the API and the developer's dependence on it. A lightweight environmental modeling framework (EMF) fits easily with existing models as there is no interference with complex APIs. This is very useful for environmental modelers as it allows the use of existing modeling code and libraries, integrating them into a larger framework. In a lightweight framework, model components can work and continue to evolve outside the framework; thus, adopting and using a lightweight framework is easy. This type of infrastructure is the most suited to DARTH development as each research group is not strictly bound to a specific infrastructure and it becomes easy to include new modeling solutions in existing models.

If the replicability of results is guaranteed by the availability of models, data and knowledge of the simulation setups, the clearest level of knowledge can be obtained when the codes are open source and can be analyzed. Being open source is not a mandatory requirement but certainly helps the structuring of open science and is highly desirable for the openness of science and code inspection by third parties. In fact, there is no such thing as “black-box science” , and the peer review process alone is largely ineffective at “sniffing out” poor validation and testing of model content .

We are committed to open science in this paper; therefore, in the following, we take for granted that the codes are open source, provided in an open repository, with an open license and with the building tools (i.e., the tools to compile the source codes).

If we then consider the point of view of the runners, we are interested in the reliability of the content and that runners can give their findings back to the system and enrich the knowledge base.

A new paradigm can be formulated as “participatory hydrological modeling”, indicating that it can be used by many researchers who can seamlessly cooperate to produce added value for the DARTHs. Not only do we aim to have a multitude of users, there should also be a multitude of developers to exploit science by providing bottom-up contributions. These requisites have some consequences in the functional design of a model. Take, for instance, the case of the Object Modeling System (OMS; ): besides a fully configurable setup, it provides a standard organization of the files used for modeling (as presented in Fig. ). A runner can be provided with all that they need (e.g., input data, parameters values, input and output file names, and modeling solutions' structure definition) to run their simulation (in the “dist” folder), in this case locally on their own computer, including the source code, the size of which is quite irrelevant with respect to the data (in “data” and “output” folders). The preprepared simulation is described and governed by “.sim” files in the “simulation” folder that contains the workflow of what is going to be executed with all of the required information. The runner can then add new simulations, with changed parameters, modified spatial partitions and input data, and can distribute all of their improvements and results back to the community with which they are interacting. This procedure, although not yet automated, has already been widely used by the authors of this work in their projects (where collaborative efforts were necessary). The idea can no doubt be improved, and the organization provided is very simple, based on a file system organization; much more sophisticated architectures, using databases and web services, could be deployed to obtain the same functionalities with automatic procedures, similar to those used in the version control system for codes. If we then assigned a unique identifier to any catchment worldwide, the procedure could even be decentralized and certified by using, for instance, blockchain-like technologies . However, as simple as it is, it is a proof of concept that such a strategy of participatory modeling is possible.

As described in the previous sections, DARTHs can be envisioned as a distributed ecosystem of different software packages that serve multiple roles and users and in which models and data can move around the web. To get some order within the models’ design, computer scientists distinguish between various levels of interoperability, according to the openness, digital portability and client-interaction style that characterize a given tool, i.e., a data-/process-driven analytical model provided as a digital software or service. distinguish three levels, but we identify five with the following definitions (which are presented with more detail in the glossary):

Model as an Application (MaaA) is the case for most of the existing classical hydrological models . Traditionally engineered models tend to be “applications”, meaning that they bundle together all of the features that are required to have an all-round modeling experience, but these are exactly the opposite of what is needed by DARTHs, where everything must be provided as a service and loosely tied. give a further clear description of MaaA. Most current models fall into this category.

MaaA, MaaT, MaaS and MaaR can be thought of in order of suitability for DARTHs to fit the paradigm of the DE concept. MaaA models are good, for instance, for those who want to claim the intellectual property rights or for commercial environments, but they are a bad thing for science. Their code is a block, making independent revision nearly impossible. Testing new features, which is an intrinsically problematic issue , becomes almost unviable in MaaA. In fact, these models have been implemented as monolithic codes, and the absence of separation of concerns makes it difficult to read/debug them . If a modeler is interested in using a particular MaaA function, this is actually not possible, and coders are re-implementing the same things over and over. MaaA models are usually defined as “silos”, in the sense that they cannot exchange data and procedures and do not favor the exchange of knowledge between related disciplines.

MaaT models are a step forward that MaaA can gain after a robust refactoring. They preserve the benefits (from MaaA) of a strong control of the model’s use and execution; however, the limitations on the usability and flexibility of the model are evident. Within MaaT, everything is controlled by the developers, who not only establish how and when the models can be used but also control the model evolution and enhancement. Clearly, if the provider is an organized community with rules for obtaining contributions, the model can be a “community model”, in the sense, for instance, that CLM5 and JULES are.

MaaS interoperability consists instead of machine-to-machine interaction through a published API (e.g., for a run configuration and execution). Nevertheless, it is not possible to move the model and make it run on a different machine transparently without human intervention.

The previous three levels establish user dependence on the provider of the modeling services. What we should aim for with DARTHs is to accomplish the more flexible possibilities represented by MaaR. MaaR allows one to effectively move the model and make it run on the machine that performs best for a specific use case, with clear benefits in terms of scalability and interoperability. MaaR obviously requires a flexible infrastructure that allows models to be built rapidly and openly as well as protocols to make the parts of the system work together without side effects. While fully-fledged MaaR models do not yet exist, the Cloud Services Integration Platform (CSIP; ) and the Community Surface Dynamics Modeling System (CSDMS; ) are examples of something between MaaS and MaaR. However, thus far, they have not been as widely adopted as they could be, indicating (1) some possible complexity in their use that coders and runners could not face properly or (2) some missing action in disseminating their added value among scientists. In the era of big data, various frameworks can provide executions of software tasks over the web. For instance, Kubernetes (https://en.wikipedia.org/wiki/Kubernetes, last access: 23 September 2022) is an orchestrator of containers that automate software deployment and management that could be used for some of these tasks. Airflow (https://airflow.apache.org/, last access: 23 September 2022) is a manager of workflows that could be arranged to manage these MaaS and MaaR software layers, even if DARTHs would require a more “declarative” (see the glossary) interactivity than the one that Airflow implements.

The informatics itself, however, does not guarantee the scientific content of the models that can be run on the infrastructure. Therefore, we claim that a further (fifth) step has to be made that covers both the science and technological sides:

Model as a Commodity (MaaC). In the case that models can be chosen from a pool present in the cloud, not only can they be automatically connected and made to run with minimal intervention to respond to the needs of the users demands (as essentially required by MaaR) but they can also be contributed to, modified and expanded by the technical user to fit their purposes. Thus, the pool increases as science advances. MaaC models are also required, by construction, to embed tools for assessing their reliability; to support literate computing, as supported for instance by notebooks (but not limited to them); and to allow for hypothesis testing.

MaaC models are demanding, as they should make the process of coupling models and the addition of features as automatic as possible, with the least possible input from the runner or coder. Currently, some conceptual work still needs to be done in this direction, as pointed out by the example of the infiltration model discussed in . As shown in Fig. , many of the MaaC requirements can be built in parallel to the infrastructures that implement the requirements of MaaT through to MaaR.

The listed characteristics of MaaC have implementation consequences that will be discussed in the following sections. A key feature of the most evolved modeling infrastructures is the possibility to break models down into parts that can be reassembled for a specific purpose, which depends on the ability of a modeling infrastructure to make model parts interact as well as to allow them to be modified, evolved or changed. A mature DARTH requires MaaC models.

Building models differently from what was traditionally conceived is the way to achieve the flexibility required by DARTHs; this spans different methods, roles, uses and the need to describe different resolutions and scales, and it requires that one considers new assumptions and paradigms and extends their scientific domain over several traditional disciplines .

Unlike past practices, structuring the software into composable parts, called “components”, should become the standard. Figure  shows the functioning of such a component, Prospero, that estimates evapotranspiration (ET). The Prospero component uses two other components: one describing the canopy and one describing the constraints (stresses) limiting evaporation. Each component exchanges information with the other through their inputs and outputs, as indicated by the arrows in Fig. . All internal components are intrinsically not accessible at runtime (according to the information-hiding principle – for its definition, please refer to the glossary), and the core algorithms of the components can be changed in favor of others that perform faster or more realistically without altering the overall scope of the system (i.e., estimating ET).

Components can be interchanged by the runners, chosen from a pool and linked together (in this case, illustrated using a script in a domain-specific language, DSL).

This modeling-by-component (MBC) approach has actually existed for more than 40 years , but it is only in the last 20 years that it has gained momentum in the environmental modeling community . Often, it has been referred to as “integrated environmental modeling” (IEM) because it stems from the need to study heterogeneous processes together and integrates knowledge from various disciplines .

There are only a few examples of MBC in the more restricted hydrological and meteorological community, including TIME , OpenMI , CSDMS , ESMF and OMS . A longer list can be found in .

MBC concepts and the technological consequences of this method are tempting, but their real deployment can suffer from “invasiveness” in some cases (i.e., they may change the habits of a good programmer, e.g., ), and they require quite an adaptation of the usual programming styles. Among these abovementioned examples, OMS faced this issue, explicitly finding encouraging solutions . MBC promotes a server-oriented architecture (SOA) of the software, which is the same type of software architecture that was requested for treating heterogeneous data sources. In principle, the SOA framework can work on different machines and is scalable across various hardware architectures. The final coder or user does not have to take care of the details of the computational engines because the framework itself takes care of it. Good features of the MBC approach are as follows:

The framework employs encapsulation, which simplifies code inspection. The components can work in a stand-alone manner (supported by a given infrastructure), and each of them can be tested separately.

Therefore, this way of designing and organizing codes is the natural candidate for fulfilling the requirements of DARTHs and for providing the building blocks of futuristic MaaC infrastructures. However, MaaC has to be treated with care, as it can potentially lead to the spreading of unreliable or untested models. Hence, MaaC models should not be limited to simply providing the results of simulations; instead, they should be equipped by design with a collection of tools for assessing the degree of reliability of the results and for quantifying their errors (uncertainty). This aspect requires further investigation in the technicality of MaaC.

If MBC is a necessary ingredient of DARTHs, then we have to understand how to write the code inside the components. The first requirement is that the code has to be clear: in fact, in order to accomplish the open-science ideas, it can be argued that not only does the code have to be open source but it also has to be understandable. offer an overview of good practices to be followed. Years ago, Donald Knuth put forward the concept of literate programming. He proposed tools to enable users to integrate texts and figures with code and then, with additional tools, to prepare documents in which the code is explained. The idea, however fascinating in principle, did not really gain momentum among programmers, even though there were programming-specific tools such as WEB , Sweave , Knitr and others that would have allowed it.

It was , in fact, who proposed that the best documentation of the code is the code itself and its appropriate organization. With respect to the vision of , some factors play a major role today, particularly the birth of high-level languages that allow a greater expressivity than was possible in the early years of high-level languages. In the early days, memory was so tight that variables and other names were usually single letters, often reused from scope to scope, and looking at a code base was more decrypting than reading. Presently, languages allow the use of more expressive names, and most of the languages have standard ways of inserting comments (to the point of making them invasive sometimes), which can be processed to produce documentation. One of the clearest examples is the Javadoc tools .

Another issue that can arise with open-source codes is the organization of the classes, which is obscure most of the time, and often what is gained in clarity by having classes with short code contents is lost by having hundreds of them without having a clue of their use in sequence. External documentation with Unified Modeling Language (UML) diagrams can help this phase, but it is usually a neglected part of the documentation. Some languages, such as Java, have recently introduced the concept of modules that serve to specify the dependence of one part of the code on others. A further step on this topic is to adopt state-of-the-art building tools, like Maven (https://maven.apache.org/, last access: 23 September 2022) or Gradle (https://gradle.org/, last access: 23 September 2022), that collect all of the dependencies needed to compile the codes and, if well written, at least clarify the dependences at the package level. These tools are much more evolved than the traditional “make” command of the C language, as they allow one to grab codes from globally diffuse repositories and keep each building process up to date, along with the latest version of the libraries that they use.

Going even more in depth into the programming, one aspect that is usually ignored by scientific programmers is that object-oriented programming is not just about using classes but also about organizing them efficiently as projects grow in dimension, as DARTH philosophy requires. These aspects are treated in “design patterns” , which offer a mature understanding of what object-oriented programming is, although they are often not part of elementary books on programming. A few books indeed cover the issues for scientific computing, such as for Fortran 95 and for Java. Another step forward can be made by using a certain degree of abstraction in software, as proposed, for instance, by , with examples in C++, and used in , with Java. Abstraction, one of the basic rules of design pattern (i.e., “program to interface and not to objects”), is important in that it allows the software “not to be modified” but “extended”, thereby enormously increasing the flexibility of a project and its lifetime. This software engineering technique enhances the flexibility already available with MBC and permits it to limit the code dimension and, when well engineered, a massive code reuse.

All of the above prescriptions can have different deployments in different languages, but the overall principles are as follows: reuse code and make it shorter, easy to read, and easy to extend while controlling modifications that can be disruptive to the stability of the whole.

Recently, a practice has been introduced by the Journal of Open Source Software, JOSS (https://joss.theoj.org/, last access: 22 September 2022), to review the model codes as part of the peer review process. It is a possibility that DARTH coders should not overlook. It is clear, in fact, that the credibility of the results must be accompanied by the “inspectability” of any part of the research and, when this is based on extensive computing, it must include access to the code’s internals.

To DARTH, the concept of literate computing can be more useful than literate programming itself. This is, for instance, promoted by the Mathematica notebooks (https://www.wolfram.com/notebooks/, last access: 23 September 2022) and, more recently, by the Jupyter notebooks and others . One necessary characteristic of open science is to keep track of the setting of performed simulations and of the data manipulation used to infer results. Some frameworks, like OMS (David et al., 2013), have internal mechanisms to do this, by commanding the simulation by means of scripts that are subsequently archived in standard places with standard name extensions. However, notebooks, with their mix of scripting, visualization of data and comments, greatly enhance the documentation of a creative scientific process, even if their role should not be overemphasized. For instance, the standard operative approach for GEOframe users is to support the preparation of the analysis of inputs and outputs with Jupyter notebooks. Until more fancy ways of interfacing with models are available, these remain the best way to expose all that has been done to a scientific audience.

An essential aspect of MaaC is the estimation of uncertainty in any type of prediction. This is essential from a practical point of view (i.e., for those activities that rely on model predictions for their planning activities) for the advancement of science, in the continuous activity between ideation, hypothesis testing and refinement. Furthermore, it is also essential for the viewer of the results, including citizens, to understand the reliability of the results. According to our definition in the glossary, reliability is a relative concept, which itself requires studies, but models do have a degree of reliability if each of their estimations always comes with an estimation of its uncertainty.

We are taught that we cannot validate models but, with the feeble light of statistics, we can try to understand how confident we can be in a certain prediction. and present a very clear summary of the issues, but there is a multitude of other contributions that treat the topic. and , among others, dissected the problem related to the forecasting of discharges, but any model of any type involves errors and has its own error-producing mechanisms, as can be seen, for instance, in or for groundwaters, for vadose zone variables, for ecohydrological modeling, for root uptake, and for general watershed modeling.

Literature is often concerned with where the errors are. Uncertainty comes from errors in data, epistemic errors, errors in methods for parameter calibration and from heterogeneity (i.e., the variability in the domain to be described and modeled). The last example could be included in the epistemic error, but citing it separately serves to stress the point. Part of the uncertainty certainly comes from ignorance of conditions that, being unknown yet necessary to completely define the mathematical problem, must be guessed.

Errors in measurements affect the procedure of calibration and cause the inference of incorrect model parameters. Errors in model structure reflect in incorrect forecasts, which, in turn, cause biased comparisons between these forecasts and the models outputs.

Figure  portrays the life cycle of a model: circles represent data, and boxes represent actions. Input, boundary and initial conditions can contain errors that propagate to the model results, leading to different responses than the control measurement set. Model results contain bias and variability generated by errors in the model structure, which also contains parameters or hyperparameters, if the model is a machine learning one, to be determined. A phase of calibration/training follows to change the model's parameters by evaluating a metric of the difference between predictions and measurements (goodness of fit, GoF). During this phase, the model is run with different sets of parameters until the optimal set of parameters is found, which correspond to the prescribed GoF value. When a satisfactory agreement is reached, the model can go into production or to a further level of analysis with stakeholders.

Once calibration of the model has been done to bring results up to a pre-established level of acceptability, a further evaluation of the model’s results must be done to test the adequacy of the model to solve the problem that it was intended to address .

Usually, the decision-making process implies the existence of a group of stakeholders with a clear methodology or at least a set of beliefs on which to base their final judgments. However, this is not necessarily the case of DARTHs, where, in principle, people can ask for model results without having an informed background. Therefore, even though the range of results that a model provides is restricted, given the laws of dynamics and thermodynamics, DARTHs should by design give appropriate warnings when results require discussion or interpretation. Among the myriad procedures for calibration, sensitivity analysis and data assimilation, error estimation is more art than science: while the methods are rigorous, the assumptions under which they work are of variable credibility depending on the process. For instance, recognizes at least 14 methodologies (as well as generalized likelihood uncertainty estimation – GLUE) to obtain these estimates. Here, we do not advise the use of any particular one of these methods, but we do claim that at least one method should be chosen. If, for the sake of the advancement of science, the search for the origin of errors is paramount, we stay (for that which regards DARTHs) with the simplest fact: “purely empirically, probability and statistics can, of course, describe anything from observations to model residuals, regardless of the actual source of uncertainty” . Moreover, we want to reinforce the idea that error estimation is a practice that has to be continuously exerted and refined. If the comparison between computed and measured quantities is systematically done in DARTHs, the statistics of the performance of a certain model setup becomes more reliable with time. As a consequence, we can easily figure out the success rate of a model’s predictions and use it as a baseline for future decisions. At the same time, using experience and comparison, we can improve the reliability of the methods used to assess uncertainties. That is to say, we can test and improve both the results and the methods to determine their precision.

Model assessment occupies the space between parameter determination , sensitivity analysis , data assimilation and decision-making .

A DARTH needs to be supported with the appropriate informatics that allow it to distribute parallel simulations and search with appropriate scalability among multi-core machines and cloud infrastructures; these are further requests for HPC applied research.

The DARTH metaphor requires an extremely large use of data exchange in the background, which requires extremely high computational power.

Efficiency in a DARTH must be achieved in many ways – for instance, data gathering and ingestion: from the coder to the runner, it is important to have self-explanatory data formats that are efficient with respect to memory . DARTH action, as it has been envisioned so far, can be represented by a graph, where the nodes are computational points, and the arrows represent potential exchanges of data. In Fig. , we have outlined what a chunk of a DARTH should be (without parallel routes). A more complete view is presented in Fig. , where, according to the extended Petri nets (EPN) representation of hydrological dynamical systems , the model is formed by the resolution of six ordinary differential equations (ODEs). In Fig. , each ODE is represented by a circle, and the model fluxes are represented by squares. As the graph shows, there are at least two independent paths that produce (as a sum) the final discharge (QT), and these paths can be run in parallel. If we write the informatics that solves the system of equations, each of the ODEs (i.e., the circles) is mapped to one or more DARTH component, and some other components are required to estimate the fluxes (i.e., the squares). For instance, the green evapotranspiration flux (ETc) in Fig.  corresponds to components represented in Fig. . Therefore, stripping down the mathematics can reveal further possibilities for parallelization. In the hands of computer scientists, this can be done – for instance, it has been studied in the OMS framework . In fact, OMS/CSIP uses knowledge of the component connections to run them in parallel over multi-core machines or on cloud computing services.

Another aspect relevant to hydrologists is that the Earth’s surface can be tiled into catchments and subcatchments . This organization of the space can be utilized to better organize the computation and reduce the information that needs to be passed between the areas. In Fig. , 32 hydrologic response units (HRUs) and two lakes are distinguished, and each of them can be partially processed in parallel. For instance, the Net3 infrastructure has been deployed in the OMS core and serves this scope. It treats the external HRUs (shown in orange at the bottom of Fig. ) independently and then moves down the computation following the channel network. It is worth noting that, if the parallelism is obvious when two paths separate, such as in the graph in Fig. , a pipeline type of parallelism can also be implemented for the linear sequences of models represented by a tree-like graph. In a pipeline, one component gets the input from another; thus, when the graph is straight and acyclic, the work done by a process, represented by a node in the graph, can be performed by a group of processors or cores and, once one of these is freed up, it can be used again for a new job. These techniques are well known to computer scientists but usually not to hydrologists. In Fig. , each square node corresponds to a system that is, in most cases, equal or similar to the one presented in Fig. . Therefore, the underlying infrastructure has to harmonize the various levels of parallelization: the one at the component level (multiple ones for each node) with the one at the river network level. This actually happens, for example, in OMS, and we refer to it as “implicit parallelization”.

Implicit parallelization has the great advantage that its action is completely hidden to the coder who implements the components, and its mechanism does not affect the way the coder implements the processes. If the framework developers find more efficient ways to achieve it, they can change the engine without the hydrological code necessarily being changed.

Purists of HPC could argue that these forms of computation are far from the efficiency of codes tuned in an assembler to obtain the maximum possible performance out of any hardware. However, what matters here is the coders' and runners' ease of use and implementation, as it can lead to the greatest improvements. In well-designed DARTHs, coders can completely ignore the computational pains in parallelizing the codes and instead focus on the tasks that they have to solve (i.e., to cook their ingredients instead of taking care of building the kitchen).

It is worth mentioning at this point, with an eye on participatory computation and programming, that the spatial partitioning of catchments offers the possibility of using different types of models in different locations. For instance, the two lakes in Fig.  (blue and red nodes) are modeled with a different set of equations than the yellow and orange nodes. Moreover, the runs performed for the characterization of the subcatchments that are upstream of the lakes, for example, can be performed by different runners who can share just the final results of their work. To this end, however, catchments (and their partitioning HRUs) need to have a unique identification, ultimately all over the world, although this is what latitude and longitude and their decimals were invented for.

One possible objection to what has been presented is that process-based models , in the traditional sense like ParFlow , GEOtop , HydroGeoSphere and SHE , which have outstanding numerics and capabilities, require a gridded partition of the Earth's surface that does not seem to fit in the nested-graph structure just envisioned. This objection is only partially valid, however, as process-based models have functional parts that can be refactored to be loosely coupled in components, while the computational grids can themselves be advantageously disjointed into spatial parts, and their computation can be organized in a graph-like structure. Certain parts of the codes, though, could remain tied to the grid structure to which other forms of parallelism methods can be applied. For these, other strategies of computation can be envisioned, in which global computations, run by institutions, can be used to drive local computations, similarly to what is done with meteorological models. The use of process-grid-based models, in fact, constitutes a third type of HPC demand that should be harmonized with the others. In summary, various levels of optimization of the computational resources can be activated in DARTHs, depending on modeling choices. However, as we have shown, some of them can remain transparent to the coders and the runners, simplifying their work so that they can be concerned with just the hydrology/biogeochemical physics of the processes, rather than with the informatics. All of this depends upon the adoption of the right framework, which appears, at this point, to be very necessary.

There is a pronounced trend in current hydrological research to use Earth observations (EOs) as the basis of the digital twin Earth (DTE). The ESA and NASA have enthusiastically embraced the idea within their programs (https://www.esa.int/Applications/Observing_the_Earth/Working_towards_a_Digital_Twin_of_Earth, last access: 23 September 2022), and, in lay people's imagination, the visualization of their resources on virtual globes is what comes closest to the idea of DE. From the standpoint of hydrological sciences, EO data, specifically those derived from space-based sensors, have provided new and independent datasets that span the range of water cycle components (the reader is referred to , , and , for further details). The usefulness of Earth observations, however, lies not just in their capacity to reveal insights on the water cycle but also in their potential to benchmark Earth system models. The latter is particularly important when dealing with the representation of human processes by models , as it is undeniable that the interaction between human activities and the hydrological cycle is currently stronger than ever .

Despite the huge availability and variety of data from EOs, the extent to which current hydrological models can efficiently and effectively ingest such massive data volumes is still poor. In meteorological and atmospheric sciences the exploitation of EO data has been supported by the development of community-based models and data assimilation (DA) systems, like OpenDA (https://openda.org/, last access: 23 September 2022) and the Land Information System (LIS; ). On the other hand, this has only partially happened in the hydrological community. The reasons for this range from differences in the scale of applications (hydrologic hindcasting and forecasting has been more oriented to smaller spatial and temporal scales) to aspects of the underlying physical system (i.e., atmospheric vs. hydrological systems vs. ecosystems), with hydrological systems and ecosystems characterized by different, highly nonlinear models for a variety of processes that existing DA and EO techniques may be unable to handle .

If both communities embrace the DARTH logic explained in the previous sections, the hydrological community should learn from the meteorological and atmospheric communities and accelerate the transition from fragmented hydrologic data assimilation research towards community-supported, open-source systems that can operate an efficient ingestion of EO data. The EO community can introduce more sophisticated retrieval processes, can benefit from the granularity permitted by the MBC approach, and can use the mass and energy conservation laws to better define what EO sensors see. Besides using various sensor data, current practices in deploying EO-based products also use hydrological assumptions, such as simple water balance schemes, and different formulations for losses, such as drainage and evaporation . Then, as often happens, these EO-based products are used by hydrologists as forcing or calibration datasets in their hydrological models with the purpose of obtaining the discharges out of a catchment. The hydrological models, however, usually have a different structure with respect to the ones that the EO products are based on, resulting in potential spurious uncertainty and not always optimal results . Instead, the DA could be completely incorporated with the simulations without the need for the intermediate steps in which the EO community deploys its products and the hydrological community its models, and the outcomes of both are compared at a final stage. Papers like and can give guidance on how to achieve this.

Generally speaking and with few exceptions, geophysical variables that are derived from satellite data are obtained via complex retrieval models with numerous underlying assumptions – assumptions that are themselves different from those used by hydrological models. This workflow could be greatly simplified if model components could directly assimilate the spectral signatures of solar and Earth-emitted radiation. To achieve this, DARTH should be equipped with model operator components (e.g, backscatter and radiative transfer models) that are able to use states, fluxes and ancillary information derived from EO data to directly ingest brightness temperature and backscatter observations . In this way DARTHs would represent the bridge between the hydrological and EO communities and would facilitate the participatory science that we are envisioning here.

Other challenges emerge when trying to integrate EO data with hydrological and land surface models. These are related to the mapping of observations to model variables, to the specification of model and observation errors, and to the homogeneity and harmonization of EO data . It is of common interest to solve the mismatches that have been found between hydrological/land surface models and EOs – for instance, when observing the spatial variability of soil moisture or evaporation data . As with the tighter workflow just envisioned, the structure of conceptual hydrological models, which, for instance, could be obtained by producing hybrid PB–ML models (as described in the next section), has to be improved. This, in turn, could result in a rethinking of the processes of calibration and DA, as envisioned by and , albeit from different points of view.

In any case, we suggest that the two communities – hydrologists and remote sensing scientists – should have a stronger and closer collaboration, and DARTHs can provide a way to facilitate it. With DARTHs, we should not have hydrologists using satellite data simply as end users, without giving feedback to remote sensing scientists; moreover, remote sensing scientists should take care of the suggestions and criticism made by hydrologists.

Thus far, we have been agnostic with respect to the types of models, whether PB, HDS, SM or ML; getting into the details of these, their achievements or limitations, is not the argument of this paper. However, as emphasizes, there are some questions that hydrological research is struggling to find answers to. Among these, for instance, is 1 of the 23 questions posed by : what are the hydrologic laws at the catchment scale and how do they change with scale? As points out, the elusiveness of answers to this question in the last 30 years was not caused by the lack of data nor by the heterogeneity of catchments but more probably by some weaknesses in the physical–mathematical methods available (see also , for further discussions); it is necessary to work towards a new mathematical–statistical approach . DARTHs should be implemented to respond to this request.

The change in paradigm that is now expected will bring the possibility of merging different families of models within MBC informatics as well as the possibility of hybrid modeling solutions in which MS, ML, HDS and PB solutions can be mixed. ML techniques are current practice when using PB or HDS models, for instance, in the calibration phases where genetic algorithms have been used since or in particle swarm , but these techniques are not normally used in core modeling. Conversely, the community is more oriented to assimilate EOs, and it has had an articulated approach to ML . As previously mentioned, there is cross-fertilization between the two communities, but often diversity of objectives and mismatches in spatial and temporal scales (small scales vs. large, global scales; hourly vs. daily or larger timescales) generate misunderstandings and imprecise claims regarding the performance of the respective techniques. These operative and semantic gaps can be filled with the help of DARTHs.

The hydrological community is still learning how to use ML, and there is a lot of room to incorporate statistical knowledge in PB models. As writes, ML tools are used together with PB modeling, for instance, for calibration , downscaling of hydrologic data , rainfall–runoff modeling , data retrieval from remote sensing data and interpreting the hydrologic process . Likewise, convolutional neural networks (CNNs) have been used extensively to learn from spatially distributed fields . In most of these trials, PB calibration is performed first and subsequently refined with ML techniques. Obviously, the same workflow is maintained in the production phase. However the granularity of the mixing of models can go deeper: as in , we can use solvers in which some equations are normal partial differential equations (PDEs) or ODEs, and some others, simultaneously solved, are ML-based like long short-term memory (LSTM) models.

However, there are a few technical issues that have to be resolved to satisfy the requirements of a well-engineered DARTH. The solutions of the ML community were generated with a variety of problems in mind, like computer vision applications, speech and natural language processing. As such, the modeling chains were developed somewhat differently from those traditionally used in hydrology and Earth sciences . These tools were created under the modeling assumption that ML can provide an all-purpose, non-linear, function-fitting capability that is “a universal approximator”, as said by . This approach, in fact, is not very different from the idea that PDEs or ODEs are the only tools required to solve any dynamical problem and that they are, from one perspective, like the OpenFOAM or the FEniCS libraries that provide prepackaged solvers and methods for the most common equation types. These frameworks can be assembled before runtime by means of a domain-specific language (DSL) and save time for researchers, who then act as linkers. For instance, in the case of neural networks, ML frameworks supply libraries to define network types like CNNs or recurrent neural networks (RNNs). As with OpenFOAM and FEniCS, they provide common model architectures and interfaces via popular programming languages such as Python, C, C++ and Scala. However, unlike OpenFOAM and FEniCS, a lot of the ML supports special hardware for calculation acceleration, with libraries such as CUDA Deep Neural Network (cuDNN) library, NVIDIA Collective Communications Library (NCCL) and cuBLAS (the GPU implementation of basic linear algebra subprogram, BLAS, libraries) for GPU-accelerated deep learning training. is a nice review of the ML frameworks currently available. Among these, we can mention PyTorch (https://pytorch.org/, last access: 23 September 2022), TensorFlow , ML4J (https://github.com/ml4jarchive, last access: 23 September 2022) and H2O . Moreover, these can use other frameworks, like Hadoop or Spark, to distribute calculations over heterogeneous cloud systems. The HPC computational forms of current PB and ML solutions are also different. Earth science applications tend to use supercomputers, as weather and climate models, or PB models like ParFlow , have a lot of inter-process communication (being grid based) that is optimized on supercomputers. ML approaches typically use cloud computing, taking advantage of algorithms that require less communication along with the compatibility of neural network processing with graphics or tensor processing units. One practical problem, as highlighted in the previous section, is to combine typical MaaA supercomputer-friendly models with ML software packages.

In principle, when using MBC, it would be conceptually easy to say that, in a given modeling solution, some of the components can be PB and some others can be ML based and that the workflow envisioned in the cited papers can, thus, be implemented. For instance, have shown that it can be done by adopting an artificial neural network (ANN) model for runoff purposes, in the OMS/CSIP system. In this case, the ANN libraries were integrated into the framework, and this made the integration easier, although not trivial; however, in general, a more loose coupling through “bridges” should be envisioned. This can be done, and one example is the Fortran–Keras Bridge that allows a two-way connection of MaaT- and MaaC-type models with the Keras framework. Fortunately, the ML types of infrastructure are often engineered as SOA software; therefore, it is not overwhelming to obtain the interactivity required by DARTHs within the flexibility offered by MBC.

One further issue is that there is not just one ML framework, but many. In ML, computations are driven by an internal graph structure, ; however, in some frameworks, this graph is static (e.g., TensorFlow and Caffe2), whereas in others (for instance PyTorch), a dynamic graph is used. Therefore, the choice of the computation model can lead to some differences in programming and runtime. As such, this requires the implementation of a “translator” of the DL structures used in one framework into the others. At least one initiative has been born to accomplish this task, the Open Neural Network Exchange (ONNX) standard , but it is missing an action, like the one offered by the OGC, to pursue that interoperability that DE and DARTH would require. Ultimately, because both PB and ML models require computations on direct acyclic graphs (DAGs), it is possible to think that new common techniques of calculation can be shared by ML and PB models.

For the emerging world of hydrological modeling to be fully operational within DARTHs three efforts are required:

building the appropriate bridges;

What we have said in the paper should suggest that the goal is not to build a fully-fledged DARTH but, rather, to build DARTH services or components that can be assembled together to build a DARTH solution. Moreover, various DARTHs can share some services and develop others for themselves, such as geospatial data abstraction (GDAL) libraries that are used by most of the open-source GIS systems or the Linear Algebra Package (LAPACK) libraries that are widely present in modeling infrastructures. We can think of DARTH components as libraries, although they are more shareable on the web, and as pieces of software that are self-contained and can possibly work alone. Therefore, the organization necessary for the development, maintenance and hosting of such a system is dependent on which DARTH components we are thinking about. As, for instance, EO data are provided by institutions like the Japan Aerospace Exploration Agency (JAXA) or the Indian Space Research Organization (ISRO), it will be their natural duty to provide the data in standardized formats and make them available in appropriate ways (i.e., by exposing an API) to be linked into a DARTH solution. Other subjects can obviously provide their own elaborations or formats of the same data and make them available. For instance, the eWaterCycle application uses the common format CMOR (Climate Model Output Rewriter), and the ESMValTool can be used to make uniform otherwise heterogeneous data. If the core of DARTHs are DARTH components, provided by different institutions or companies, they should eventually be linked together to have a functioning DARTH solution. Deployments like those initiated with eWaterCycle or Delft-FEWS and LIS are examples of integrators of resources; maybe they are not fully compliant with the DARTH architecture, but they can be a good starting point to deploy DARTHs and provide an example of DARTH providers.

Further ideas are expressed in , who provide a specific section with a clear title: “Effective Governance of the Independent Enterprise Systems of a Digital Ecosystem” The word ecosystem, in fact, is probably the more appropriate in this context: not applications but ecosystems of open applications.

Because DARTHs grow and develop continuously by adapting to the emerging scientific questions, in principle there is no need for a centralized director for most of the developments. However, organized communities can achieve more. In particular, any community will be effective if it chooses to adopt common standards for data and formats, while also promoting innovative solutions. The JULES project (https://jules.jchmr.org/, last access: 23 September 2022) is an example of governance for such communities. Examples of successful communities can also be seen in . An obvious and bigger model to learn from, outside the hydrology community, is provided by the GNU/Linux project where one community is responsible for the kernel of the operating system; others, including GNU, provide additional tools; and, at the end of the process, other subjects deploy variously flavored versions of GNU/Linux, called Linux distributions. The DARTH need not be either commercial or non-commercial: both strategies can be pursued (and, we guess, will be pursued). Please observe, however, that commercial is not the opposite of open source: an open-source product can be commercialized, and a commercial product can be open source. Thus, DARTHs can be both commercial or non-commercial but, either way, would require the appropriate open characteristics.

Building pieces of a DARTHs (i.e., DARTH components), as we see it, is feasible by an organized group of researchers (especially at the linker level) or by partnerships funded by international research programs. The OpenEO initiative (https://openeo.org, last access: 23 September 2022) in the field of Earth observation data development is an example of how a DARTH development could be funded. The entire scope of this paper is to suggest a modular architecture with science parts that can, in principle, be affordable to many ,if not all, scientists, as it was for JULES , CLM and other projects. From a lower level , SUMMA , GEOframe and OMS3 are efforts of a single research group that can provide a starting platform for a DARTH. Certainly, producing a DARTH from scratch would be a major effort that only large company associations or governments could afford.

The quality control of the final product is done by, in fact it is, the community that builds a specific part of the DARTHs and the community or the commercial entity that links the various DARTH components to form a DARTH distribution. Certainly, new techniques like the blockchain can be used to certify the steps and the chain of responsibility that a certain DARTH distribution has followed. It is expected that DARTH initiatives will also come up with test cases with specific links to (or support from) important experimental activities, sites and observatories (e.g., https://www.hymex.fr/liaise/index.html, last access: 23 September 2022) that link experimental measurements and observations to model development. The same observatories can also be responsible for building shared benchmarking datasets to test DARTH performance. If we refer to studies pursued with DARTHs, the ultimate responsibility is of the runners who perform the studies and, eventually, the journal that publishes them. One critical aspect though, will be the availability of data, simulation records and software to allow the testing of results by other researchers. Whoever uses a DARTH is responsible for its results, just as whoever publishes something is responsible for the published piece. Experience from the SARS-CoV-2 pandemic suggests that the reader must be educated and that keeping information hidden does not solve issues and does not cultivate the credibility of science. Therefore, in our opinion, limitations on the flow of information is a bad policy. On the other hand, the presence of error estimation, the replicability of the experiment and open code are landmarks for the good will of acting fairly.

In this paper, we have discussed what DARTHs are, and we found that they cannot simply be models as intended in the usual sense. They first need to be supported by an infrastructure that provides the following the following:

the possibility to use the modeling-by-components (MBC) strategy;

Furthermore, we claim that this infrastructure should be able to do the following:

dispatch data and models around the web for distributed elaboration;

Detailed prescriptions were given for these infrastructures to accomplish open-science requests, including being open source and produced by open-source tools, a requirement that is, obviously, an option but that we deem necessary for the progress of science. We also gave indications about deploying the necessary code and computing literacy.

We did not discuss the content nor the structure of the models, but we claimed the following:

DARTHs should be agnostic with respect to the model choice in order to support the progress of science;

Moreover, to help progress, we categorized the models according to their characteristics with respect to being able to cope with the DARTH metaphor, spanning from MaaA to MaaC.

Those who are interested in model content can easily refer to the various commentaries, reflections and blueprints present in literature , which should be thought of as complementary to the present paper.

We also remarked that DARTH has to encourage a new collaborative approach to EOs for both the hydrology (and Earth science) community and the Earth observations community: an approach in which data fusion and products are made at the coder level and not provided “as is” to researchers. Another characteristic that has been invoked is the presence of readily available error estimates with any DARTH in any forecasting and as part of the knowledge creation.

A DARTH should not be thought of as an immutable piece of software but as a dynamically growing and evolving system in which different model paradigms, data and simulations can be exchanged and/or accessed over the web. Semantic information has to be added to allow searches of the competing tools and to make the discovery of data easier. A DARTH system should be openly managed and contributed to by the good will of researchers working within shared policies. DARTH design must favor cross-fertilization of knowledge between related sectors of science, technology and management, avoiding so-called silo-type models. The systems' deployment concepts are, at present, themselves in development, and they are a matter of research, trial and error. Therefore, DARTHs can be designed with the fact in mind that many changes will be possible before getting the desired result.

We did not discuss the most commonly treated area of DE (i.e., the one dealing with visualization of data). It is obviously a fascinating subject, however, our previous experience in building GIS systems has taught us that visualization has to be treated as data and, therefore, loosely coupled to models because it is subject to rapid obsolescence. Many new human–computer interfaces are foreseen in the next few years, and DARTHs have to be prepared to connect to them and exploit their capabilities, including interfaces with the natural languages and body gestures that often appear in sci-fi movies.

Finally, there is an exciting area in HPC research where new methods can be envisioned for processing a chain of models and submodels along DAGs that has just started being explored and that could unify the way that the informatics and numerics of ML and MBC are actually done.

In this paper, we gave a name to the hydrological DTE and expressed optimism that the goal to build a DARTH is a feasible enterprise that can be pursued with success. Many of the aspects touched upon are, in fact, already reality in current state-of-the-art practices and just need to be evolved, systematized, and integrated into a unique framework or made interoperable. This integration is necessary because, as the authors of this work believe, great advancements and innovations in hydrology can only be achieved by treating all of the aspects discussed together.