Interactive hydrological modelling and simulation on client-side web systems: an educational case study

Computational models allow scientists and engineers to simulate the complex relationships that exist in real-world systems. In water resources, computational hydrological models are fundamental pieces of the workflow of contemporary research, education, and professional practice. These models are used to support a broad range of tasks, including engineering design (e.g., Gironás et al. 2010; U.S. Army Corps of Engineers 2018), flood forecasting (e.g., Beven et al. 1984; Krajewski et al. 2017), flood inundation mapping (Li & Demir 2022), sedimentation forecasting (Xu et al. 2019a, 2019b), water quality research (Jha et al. 2007), and water resources management (Sulis & Sechi 2013), among others.

From a practical perspective, using physically based models presents many challenges. Data appropriateness, preparation, scale, sparsity, and errors are significant obstacles that prohibit the use and confidence of models. Users must also contend with learning a standalone graphical user interface – or lack thereof – to access and deploy the modelling software. Likewise, the coupled challenge of access to computational resources, and the expertise to manage them, can be a significant burden to run a model fit for its intended purpose. These difficulties set a high training level threshold that stakeholders must meet if they want to use these tools and models. Finally, challenges of model reputation, adoption among stakeholders, and lack of benchmark datasets (Ebert-Uphoff et al. 2017) for comparative analysis present limitations to the reproducibility and impact of model findings.

Many of these practical challenges are associated with desktop-based, or offline, modelling workflows. In response, hydroscience computational architectures have advanced alongside cyber and computing technologies. The most recent advances fall within Web-based simulation (WBS), or the use of the Internet to separate modelling tasks among networked machines. A key criterion of WBS is that a web browser plays an active role in modelling and simulation sub-tasks, such as simulation, visualization, data storage, or documentation (Byrne et al. 2010).

Arguably, the two primary goals of WBS are simulation and visualization. In a client-server model, either of these tasks can be completed locally, in a browser on the client's local machine, or remotely, on a server. There are numerous examples of server-side simulation for hydrology and water resources studies, such as streamflow forecasting (Castronova et al. 2013), ecosystem services (Feng et al. 2011), hydrology and climate change (Goodall et al. 2013; Zhang et al. 2019), watershed management (Demir & Beck 2009), mountainous snow-water resources (Wu et al. 2018), environmental decision support (Sun 2013), and urban watershed hydrology (Zeng et al. 2021).

Likewise, there are equally many examples of client-side implementations of data exploration and visualization tools ranging from pure client-side architectures (Jadidoleslam et al. 2020; Walker et al. 2020) to architectures that offer client-side visualizations and some server-side data analytics (Booth et al. 2011; Brendel et al. 2019; Rottler et al. 2021). Furthermore, other efforts have sought to integrate server-side computation and data storage with client-side visualization to support web-based hydrologic workflows (Peckham et al. 2013; Delipetrev et al. 2014; Swain et al. 2015, 2016; Yildirim & Demir 2021). Taken together, these efforts demonstrate a focus on, and the viability of, modelling as a web service for hydrological applications. Notably, this design places computation and simulation predominantly on server resources.

Client-side simulation, however, should not be ruled out as a viable option as it offers many usability advantages. First, all modern browsers comply with the ECMAScript specification (ECMA International 2021), i.e., JavaScript, meaning that JavaScript code is interoperable across any browser on any device, no matter the browser or machine. Second, recent advances in JavaScript interpreters have resulted in significant increases in computational speeds, with one-to-one tests showing JavaScript performance on the order of magnitude of C ++ code (Hinkelmann 2019). When considering a computationally intensive task, JavaScript no longer holds a severe performance disadvantage, while still maintaining its usability and interoperability advantages as a native web language.

Client-side computational resources have been used to perform various tasks, including modelling, in environmental and water resources applications. Prior to the cross-browser standardization of JavaScript, Java language applets were used to perform client-side tasks, such as calculations for decision support tools in watershed management (Voinov & Costanza 1999; Mustajoki et al. 2004). More recent examples show the potential to leverage client-side compute resources for much of a WBS workflow. A client-side simulation engine was implemented to calculate biochemical oxygen demand and dissolved oxygen along a river reach (Walker & Chapra 2014). The simulation engine was complemented by client-side visualization and a user interface, which allowed for the rapid iteration of simulation inputs. The same authors also implemented a client-side version of the ABCD Water Balance model, a simple lumped hydrological model to simulate streamflow at a daily scale (Walker 2014). In another example, a web-based analysis and scenario tool for the eutrophication of inland waters perform all necessary computations in the web browser (Strömbäck et al. 2019). The authors, however, report that they simplified the original model to make the browser implementation more performant. Finally, a numerical engine has been developed to simulate tsunami wave generation and propagation, and its visualization, as a JavaScript-WebGL library (Galaz et al. 2022). The simulation engine was tightly coupled with other web elements, data sources, and sensors to support a web platform for public education and tsunami awareness.

Environmental web applications have demonstrated the potential to leverage client-side computational resources for flood mitigation (Alabbad et al. 2022), well forecasting (Sit et al. 2021), sedimentation forecasting (Xu et al. 2019a, 2019b), and decision support systems (Ewing & Demir 2021). Furthermore, other client-side tools have been developed for hydrological studies focusing on participatory decision support (Teague et al. 2021), watershed delineation (Sit et al. 2019), and flood map generation (Hu & Demir 2021). Taken together, an ecosystem of web-ready, hydrological tools has emerged in the last decade. Implementing a hydrological model in JavaScript, the lingua franca of the web provides many opportunities for extensions in this dynamic, interconnected ecosystem.

One potential application area for web-based rainfall-runoff models is in hydroscience education. Although models are fundamental to various professional workflows, there are many challenges to a model's successful integration into hydroscience curricula. First, the educational focus in hydroscience curricula is (or should be) on core hydroscience concepts and not a particular vocational tool, such as a model. Equally, there is no single model (i.e., vocational tool) that is universally used professionally, which would justify its instruction over all others, always.

If indeed a model is selected for classroom use, instructors face barriers to its successful educational application. Many barriers, if not all, stem from the most essential and precious resource – time. For example, data acquisition and preparation are fundamental modelling tasks. Yet, they can be the most time-consuming. Various surveys of professionals across data science and scientific modelling disciplines show that data acquisition and data preparation account for a majority of the time spent on a modelling workflow (Jackson 2014; Lohr 2014; CrowdFlower 2016; Anaconda 2020). Furthermore, using models often requires specific, standalone software and other Information Technology (IT) knowledge to operate. These technologies often have steep learning curves, especially for beginners. Learning and executing these parts of a model workflow take much more time than the time for computation and analysis of results, especially in the case of classroom examples. Thus, there is tension for the instructor between teaching the fundamentals of the subject matter and teaching the model workflow as a conduit to explore the subject matter; in short, teaching the science vs. teaching the tool. This reality describes the challenge to teach contemporary hydroscience topics in a manner, which recognizes the state-of-the-science tools, without obscuring the subject fundamentals behind the technical/vocational knowledge of specific software or tool chains.

The aim of this paper is twofold. First, we seek to understand the capability of client-side technologies, i.e., JavaScript, to perform computationally intensive hydrological modelling, such as full-scale, physically based rainfall-runoff models. Second, we seek to explore potential application areas that browser-based hydrological modelling can support. Towards these aims, we implement and test the performance of a JavaScript version of a rainfall-runoff model currently used for both operational flood forecasting and research. Furthermore, we present a fast and interactive in-browser interface designed for hydroscience education. In the Materials and Methods section, we detail the hydrological model used, a previous implementation of the same model in the C Programming Language, and subsequently the current implementation of the model in the JavaScript language. In the Results section, we first confirm the proper implementation of the model via a comparison of benchmarking results. We then detail the use of the client-side model and simulation engine as part of an educational use case. In the Discussion section, we examine further the performance and discuss the benefits of client-side simulation for research, education, and operation. We conclude with a look into future work and the general benefits of client-side computation for water and environmental modelling.

In this section, we first describe the hydrological model, the Hillslope Link Model (HLM), implemented in JavaScript. Next, we describe the original implementation of HLM in the C programming language. Finally, we describe the current methodology to implement the hydrological model as a native client-side simulation engine.

The nature of how rainfall is transformed on and through the landscape to generate runoff and streamflow is a complex physical process, and accurate estimation of this process is important for flood forecasting, disaster relief, engineering design, etc. To address these needs, mathematical models to estimate runoff generation from rainfall have proliferated. One such model is the HLM (Mantilla 2022). The HLM uses the concept of landscape decomposition into just two elements: hillslopes and channel links. Hillslopes are irregular-shaped polygons where the conversion of rainfall to runoff takes place. This process depends on the hillslope attributes such as size, shape, slope, exposure, soil type, and land use. Each hillslope is uniquely associated with a channel link. A hillslope's runoff, both surface and subsurface, drains to the corresponding link and the links make the river network. Runoff that finds its way to the channel is transported downstream and aggregated as the small streams come together to form larger ones that then become rivers, first small then larger. Channel links also have certain attributes that control water transport. These include length, slope, and roughness, as well as other aspects of hydraulic geometry (e.g., channel cross-sectional shape). The typical size of a hillslope is on the order of 0.01 km² and the typical length of a link is on the order of 0.1 km.

The construction of the modelling domain (also called ‘hydrofabric’) requires the use of digital topography data, better known as the digital elevation model (DEM). Such data are widely available at very high spatial resolution, as high or higher than 10 m. From the DEM data, one can extract the drainage (river) network and its basic attributes and the associated outline of the hillslopes with some of the key attributes (Mantilla & Gupta 2005). From other available public sources, such as land surveys, one can obtain information regarding land use and soil types as well as the geometry of the channel cross-sections.

Mathematically, the physical processes involved in runoff generation and transport can be described as a set of ordinary differential equations. There is a good deal of flexibility on how detailed a description is desired. For example, a simple model can be based on a constant runoff coefficient (fractions of rainfall) and constant channel velocity. This results in a linear system of equations and thus is easy to solve. A more realistic description could be based on a non-linear concept of storage at a hillslope and non-linear channel velocity. The resulting system requires a numerical algorithm to solve. Refer to Appendix 2 in Supplementary Material for a description of the mathematical formulations of the constant and variable runoff models. Likewise, the formulation of both the constant and variable runoff models can also be found in Small & Debionne (2016).

The HLM has several attractive properties. First, it respects the scaling (fractal) properties of real river networks (e.g., Horton laws). This allows the model to mimic the correct temporal response for a given size upstream drainage area. Second, it avoids the challenge of properly estimating the lateral fluxes necessary for other regular grid-based models. Each hillslope drains to one channel link and there is no other ‘communication’ between the adjacent hillslopes (this is true, ignoring the saturated groundwater contribution to streamflow). Third, as we just briefly discussed above, the model structure (hydrofabric) and the mathematical description of the physical process are independent. This allows for a consistent study of the importance of different models of certain processes. Fourth, the numerical solvers of ordinary differential equations are much more efficient and easier to implement. The model structure is also amenable to parallelization. Note that the computations of runoff at the hillslopes are independent of each other and that it is the transport of water in the river network that is coupled but in a rather weak way (computations at a link require the availability of streamflow at the two nodes upstream). Five, the model does not require intensive calibration. With a reasonable selection of the parameters, which all have some physical interpretation, the model demonstrates an acceptable level of skill out-of-the-box.

From an educational perspective, HLM's concept of landscape decomposition and the resultant mathematical description are well suited for educational applications. In fact, one can organize an entire undergraduate engineering hydrology course using it. First, it is undisputable that the concept faithfully describes surface (including near subsurface or unsaturated zone) water flow in the environment. This facilitates subsequent discussion of the relevant physical processes of rainfall, evapotranspiration, infiltration, runoff, and open channel flow. Because the concept naturally covers a wide range of spatial and temporal scales, it provides background for discussion of space–time variability, land–atmosphere mass and energy exchange, the concept of storage and water balance, and water transport. As the model use requires data, this provides an opportunity to discuss different measurement and sensing technologies, from radar-rainfall to satellite-based soil moisture to in situ techniques of water evaporation, infiltration, and flow. With the above-mentioned elements in place, one can illustrate the key engineering practice methods of the rational method, curve number, unit hydrograph, and flood frequency estimation.

The distinction should be made between the HLM framework, which is the mathematical model by which to describe the physical processes, and the machinery needed to generate a solution based on the mathematical model. To solve these equations, i.e., simulate the rainfall-runoff response of a network, a numerical solver is required. One advantage of the HLM framework is that its river network has a directed graph topology, such that the solution at a hillslope only requires information at the hillslope itself and its direct ‘parents’. Because of this structure, a numerical solution to the rainfall-runoff response at each hillslope link can be found asynchronously. One such numerical solver has been developed to solve systems of ODEs linked by a directed tree structure, as in the case of the HLM river network topology (Small et al. 2013). This solver was written in the C programming language and uses an adaptive step-size Runge–Kutta method with dense output interpolant capabilities. The authors also present a network-partitioning scheme and the scheduler routine that enable distributed and parallel workflows to support massive simulations with high-performance computing (HPC) resources. A version of this implementation provides operational hydrological forecasts for the entire domain of Iowa (Krajewski et al. 2017) and is also used for research applications (e.g., Jadidoleslam et al. 2019). Currently, it supports a variety of input and output types such as databases, binaries, text files, and hierarchical data formats.

From an educational perspective, however, the current workflow for the C Programming Language implementation of the HLM model has many characteristics that hinder its use as an educational tool. The first issue is that of access. This implementation is best suited for HPC environments, where the codebase, its dependencies, and the networked computing resources are maintained by IT professionals. Lack of access to HPC environments limits its use. The alternative to using an established HPC environment would require students to install and maintain a version – and all its dependencies – on one's personal machine. This also presents a significant burden to use. Second, this implementation lacks a graphical user interface. This requires users to alter input files manually, usually in a command line interface. Finally, the C Programming Language implementation lacks even a simple visualization tool. This means that a user would need to interpret simulation results in yet another software. Thus, the current C code implementation significantly limits any possibility of HLM's use in a classroom environment.

This section details the methodology of the client-side (i.e., JavaScript) web application for simulating the rainfall-runoff response of a river network using the HLM family of models. First, we chose to use the HLM because of its flexibility to describe varying levels of complexity in the physical processes; it is open source and well-documented; it has proven its performance in advanced operational forecasting and research applications; and, finally, we have significant experience with it.

To develop HLM-Web as a JavaScript application, we used the object-oriented programming paradigm. As stated previously, DEM data are processed to generate discrete hillslope link sections with distinct physical properties, such as channel length, area of the hillslope, and total upstream area. As such, the hillslope link unit was used as the basis for the object model. Each hillslope link object contains object methods and properties. In general, these methods and properties can be categorized into three groups: physical attributes, model structure (equations), and numerical solver. All necessary properties and methods are added at object instantiation but can also be altered prior to simulation execution.

Physical attributes of the hillslope link object are either direct inputs from the discretization of the river network to be simulated or were calculated using both the hillslope-specific physical attributes and global variables that apply to all hillslope link objects. Refer to Appendix 2 in Supplementary Material for the definition and use of the physical attributes in the model equations. The HLM-Web Educational Hydrology Tool section contains more information about setting global variables.

HLM-Web uses the Runge–Kutta method (fourth order) as a numerical solver. This method is used with an adaptive step-size routine that compares the truncation errors of derivative approximations to user-defined error thresholds to adapt the step size of the integration (Press et al. 1986). Furthermore, a dense output interpolation scheme was used in the solver (Hairer et al. 1993). Dense output schemes allow for higher-order interpolation between step sizes. This is an important feature of the solver because the integration at a hillslope link requires the discharge from upstream links as an input. Due to the adaptive step-size routine, it is unlikely that the upstream links will have a solution at the exact time required for the downstream link. As such, the dense method is used to interpolate the discharge from upstream links as necessary to solve for a hillslope link.

At each hillslope link, the hydrologic model is described as a set of ordinary differential equations. These equations vary depending on the model (e.g., constant vs. variable runoff). Refer to Appendix 2 in Supplementary Material for a mathematical comparison between the constant and variable runoff models. At the instantiation of a Link object, a function is assigned to the object as a method (dydt). No matter the internal structure of the derivatives themselves, the method takes the same inputs: an array, Y, of states of the link; the current simulation time, t; and an array, f, for the forcing (evaporation, precipitation, etc.) at the current simulation time. The function returns the calculated derivatives in an array of equal length to that of array Y.

The order by which the Link objects will be stepped can be generated on the fly using the function (getOrder) or supplied in an input file. Our current methodology is to provide an input file where the order of hillslopes to be processed is generated by a post-order traversal listing of link ids from a depth-first search of the river network as a directed graph. Because solving a link only requires information from the link itself and the link(s) immediately upstream of it, all data held in the upstream link objects can be scrubbed once the simulation of the downstream link is complete. Thus, the post-order traversal is a memory-efficient order used to solve for the links. Only simulation data from preselected links are stored after they are used for the solution of links immediately downstream. Once all link objects have stepped to the end of simulation time, the simulation runtime is reported. Simulation results can be exported as comma-separated values (CSV) or viewed in a figure within the browser window.

It is important to note that this workflow is essentially the same, whether the core HLM-Web simulation engine is used alone or with a graphical user interface (such as the educational user interface presented in Results.) Input data can either be edited within the files prior to the browser parsing them or after.

In this section, we present two case studies of the HLM-Web simulation engine. First, we validate the results from the HLM-Web solver. Next, we detail how HLM-Web's simulation engine can be integrated with other web technologies to create an interactive educational tool to support hydrology education.

The second demonstration of the HLM-Web simulation engine is an interactive educational tool to teach hydrology. Using the simulation engine for a real-world use case provides insight into how interactive WBS may improve the broader modelling workflow beyond the narrow focus of computational time. Synergistically, extending the HLM-Web simulation engine with an easy-to-use interface makes this model more accessible for use in education.

Simulation results are shown at preselected hillslope links within the network. Hillslope links where results are shown (or output) can be readily altered via a configuration file. For this educational application, hillslope link results were selected for visualization by their approximate stream order with respect to the contributing area of the network outlet. Without needing to refresh the current webpage or navigate to a new page, users can easily change the simulation set-up and run the simulation again. Simulation results (i.e., hydrographs) and metadata can also be exported in CSV format for further analysis and visualization. Notably, the codebase allows for any state variable used in a model formulation to be saved and exported. However, the current educational web tool only allows the export of link discharges (i.e., hydrographs.)

All features of the educational tool are based on client-side technologies. The tool was developed with iterative feedback from course instructors with the objective that it would supplement the hydrology courses at the University of Iowa, Department of Civil and Environmental Engineering and the University of Manitoba, Department of Civil Engineering.

HLM-Web demonstrates that it is possible to implement a full-scale distributed rainfall-runoff model and simulation engine using only modern web standards. To the best of our knowledge, a full-scale hydrological model running completely as a client-side application has not yet been presented in the literature. Furthermore, we demonstrate that this technology can be applied to provide an accessible educational tool to the undergraduate hydroscience curriculum. In implementing a distributed rainfall-runoff model on the web, the technology becomes available for use alongside the many web-based applications that comprise the dynamic and interconnected ecosystem of web-ready hydrologic tools.

We begin this section with a brief discussion of benchmarking results. Next, we discuss the computational performance of HLM-Web and the potential strategies to improve it. Next, we discuss the benefits of client-side simulation via the strengths of our HLM-Web educational tool. Finally, we conclude with a discussion of how the technology may be leveraged beyond education in outreach, research, and operations.

Via the direct comparison of benchmark results provided in the HLM documentation (Figure 2), we show that the JavaScript-based HLM-Web provides identical results for both the constant and variable runoff models. This verifies two important criteria. The first is that we have accurately formulated the mathematical models. The second is that we have demonstrated the ability of our numerical solver to return equivalent solutions to that of the solver of the current, operational version.

As expected, the HLM-Web – written in JavaScript for client-side web computing – is slower than the original C code implementation (Hinkelmann 2019). In part, this can be explained by the fact that many of the JavaScript engines are themselves written in C, meaning that there is a practical performance ceiling considering the overhead to interpret and then execute the code.

Nonetheless, the computational speed of the HLM-Web could be increased and, indeed, is part of intended future work. Generally, there are two complementary approaches to increase the computational speeds of the HLM-Web. The first strategy would be to continue to improve the existing codebase. We observe that there remain opportunities for speed improvements in this regard, specifically with respect to the interplay between the scheduler logic and the search algorithms used for the dense interpolant scheme.

The second strategy to increase compute speeds would be to apply new web technologies. In this regard, two current web standards, Web Assembly and Web Workers, offer means to improve compute speeds. First, the Web Assembly is a standard, which allows the execution of portable binary code to be run on web pages (Haas et al. 2017). In practical terms, leveraging this technology would allow for the entire simulation engine, or portions of it, to be run at speeds approaching native C code (Mozilla 2013). Second, Web Worker technology allows JavaScript code to be executed in the background without blocking the function of the webpage it is running in (MDN 2022). A characteristic feature of Web Worker technology is that it can more effectively use multi-core CPUs. Thus, another avenue to improve computational speeds is to parallelize the simulation task across a client's CPU cores via a Web Worker.

As we demonstrate with the educational use case, a client-side simulation workflow can mitigate some of the challenges of offline workflows for users. First, the client-side architecture of HLM-Web allows for interoperable, no install, no set-up hydrological applications. This means that users can perform simulations on any device that has a browser, even on simple machines such as mobile phones or browser-only devices like Chromebooks. Likewise, when the HLW-Web simulation engine is combined with an easy-to-use web interface, modelling and simulation can be done without writing any code. Here, HLM-Web has a major advantage to other options available to educators. Although engineering students are expected to have some skill in programming, developing a full-scale model (code) within a single semester is clearly beyond their level of proficiency.

For users, the time and burden of data preparation and handling are all but eliminated with the HLM-Web educational tool. Likewise, the instructor can calibrate the amount of exposure to the data preparation and handling tasks needed without it being a critical lynchpin within a course. Taken together, HLM-Web and the easy-to-use web interface provide a ‘flat’ learning curve for users to focus on hydrology. Instructors have used the tool for in-class demonstrations, homework, and final examinations. The HLM–Web education tool has been used to teach a variety of hydrological concepts, including simulating watershed response at a range of spatial scales (which, in the process, demonstrates the role of the river network on flow aggregation); the role of rainfall intermittency on peak flow magnitude; the role of soil moisutre as a system memory; unit hydrograph theory; and more. Refer to Appendix 3 in Supplementary Material for sample problems that use the HLW-Web Educational Hydrology Tool.

There are many benefits to a distributed rainfall-runoff model implemented completely in modern, client-side web standards. While many of these benefits are exhibited in the educational tool presented here, they can also be leveraged in application areas such as operations, outreach, and research. First, a curated and simplified interface creates the scaffolding for rapid simulation without writing any code or manual alteration of inputs or parameterization. This can significantly lower barriers to the time-sensitive use of simulation and models. For example, with improvements to compute speeds, either via more computational power or parallelization, HLM-Web could serve as a research sandbox to rapidly test different model formulations or parameter combinations.

The model application can also be coupled with online data products for seamless data preparation and integration. For example, the river network input data could be served to the browser dynamically based on latitude and longitude coordinates supplied via a map interface. Rainfall products, either historical or forecasts, could be queried from a web service (e.g., Seo et al. 2019) and served to the browser for direct integration with the simulation engine. These input data could then be used to generate custom forecasts for a region of interest or design flows for a proposed project. This streamflow data could then be used for dynamic flood inundation mapping. Furthermore, the flood inundation maps could then be used directly as outputs or inputs to generate real-time estimates of flood damage. A workflow such as described would provide value to first responders, disaster planning, and floodplain managers. The automated data preparation and integration opportunities could significantly improve some of modelling's most tedious and time-consuming tasks and, as such, increase access to advanced modelling tools.

A client-side simulation engine also offers some advantages over WBS with server-side compute. First, because HLM-Web does not itself use any server-side compute, it can be hosted on a simple web host for static files. Static hosting presents a significant cost-saving compared to a server environment running compute-intensive tasks, such as simulation. A second advantage to using JavaScript and client-side architectures is that it is inherently an open source because the server passes the written code to the browser and then interprets it on the client machine. This is in contrast with the server-side compute model, where users do not necessarily have access to the source code used. In this manner, the codebase is more available for inspection and development by the community. These advancements lower barriers to access and increases ease-of-use of rainfall-runoff modelling and simulation for a range of applications. In effect, it provides a wide range of stakeholders the means to use and engage in the subject matter within a self-contained, ubiquitous platform.

In this work, we sought to understand the capability of client-side technologies for computational tasks in hydrology. Furthermore, we sought to explore potential application areas that browser-based hydrological modelling can support. First, we presented HLM-Web, a simulation engine for distributed rainfall-runoff modelling in JavaScript, which can run full-scale, physically based models on the client side using a browser. We show that the simulation engine provides equivalent results compared to benchmarks from the previous implementation of the same model in the C Programming Language. We then demonstrate how the core simulation engine can integrate with an easy-to-use in-browser interface designed for hydroscience education. Browser-based simulation, thus, can improve the overall modelling and simulation workflow. These findings suggest that client-side browser-based simulation can support application areas where interactive and iterative simulations are desired.

Previous work in the literature has demonstrated the possibility of in-browser, client-side modelling with simplified models of environmental phenomena. This work moves the field beyond the current state-of-the-science and shows the potential benefits of simulation using native web technologies. Namely, these benefits increased integration with other web-based tools for hydrological modelling, such as integration of the input data and results pipelines; the inherit open-source nature of JavaScript applications; the write once, run everywhere characteristic of JavaScript, allowing for users to always access the most current version of the software; and the potential application pipelines it can service in education, outreach, and research.

Future work will focus on improving the computational performance of the simulation engine and extending its modelling capabilities. Overall performance can be improved through improvement on single machines – via better scheduler and memory management; converting all or part of the engine to Web Assembly; leveraging parallelization of simulations with Web Workers – and developing distributed (Agliamzanov et al. 2020), peer-to-peer compute capabilities. Extending modelling capabilities entails incorporating other environmental processes alongside the hydrologic models presented here and streamlining input and output data with other web-ready hydrologic tools. Together, with the possible extensions, the current implementation suggests that client-side hydrologic modelling and simulation can play a central role in a dynamic, interconnected ecosystem of web-ready hydrologic tools.

All relevant data are included in the paper or its Supplementary Information.

The authors declare there is no conflict.