This paper outlines the application and usefulness of a software platform that enables hydrologists to develop custom functionality in a new hydrological modelling tool, eWater Source, designed for water resources planning and management. The flexible architecture of the software allows incorporation of third-party components as plug-ins to add new capabilities that are not built in. Plug-ins can be developed to adapt the software to suit the needs of hydrologists with modest software development knowledge. This can result in an improvement in workflow and efficiencies. In addition, modellers can use plug-ins to integrate hydrological process and management models that may not be able to be built in the normal tool. The paper introduces the plug-ins functionality of the modelling tool, its design and applications with three example plug-ins to demonstrate. These are: (1) a data processing plug-in to upscale urban environment models; (2) a management rule plug-in to calculate loss allowances for the Pioneer Valley; and (3) a model plug-in to integrate into a river system model. For planning purposes, the use of plug-ins is thought to be critical for modelling management rules for various jurisdictions since these can vary significantly between jurisdictions and change over time.
ABBREVIATIONS AND NOTATION
High security class A
High security class B
Days at end of month
Cooperative Research Centre
Department of Natural Resources and Water
Department of Sustainability and Environment
Geographic information system
Génie Rural à 4 paramètres Journalier
High class priority water allocations
Integrated Quantity and Quality Model
Index percentage announced allocation for High Class B Pioneer
Murray–Darling Basin Commission
Monthly Simulation Model
Non-stream flow period
Set of data points for the transmission operational allowance
Minimum flow rate
Resource Allocation Model
Stream flow period
Transmission operational allowance
The Invisible Modelling Environment
Maximum capacity of the production store
Groundwater exchange coefficient
Maximum capacity of the routing store
Base lag of the unit hydrograph
In hydrological modelling, there is no single approach or algorithm that makes the most sense in all circumstances. Differing data sources across catchments limit the applicability of some approaches. Different solutions are needed to answer questions at very fine spatial and temporal scales as opposed to broader scales (Wurbs 1994; Wagener et al. 2010). Urban environments have different characteristics to rural environments, which themselves have very different hydrological characteristics depending on the amount of in-stream and catchment development. In water resources management (and particularly in Australia), the policy and operational rules governing the running of the system can be both complex and highly specific to a location. Water resource management has evolved over time to include more complex rules for allocation in attempts to adjust for increasing environmental and socio-economic challenges. In addition, Australia's river management, and therefore much of the hydrological modelling, was managed in jurisdictions, and so modelling tools were developed for specific regions. This caused an establishment of modelling approaches that were unique to the different regions. More recently, there has been a strong emphasis on integrated modelling using a holistic approach, both in modelling transboundary river systems where different parts of the basins fall under different political jurisdictions, and also in incorporating multiple processes and multiple management rules for defined regions (Welsh et al. 2013; Dutta et al. 2014). In this paper, a model shall be referred to as a generic conceptual representation of an environment or process that does not necessarily contain any site-specific data. Models take the form of equations, algorithms and/or computer code that may have a user interface (UI). The term framework is used to describe the underlying systems upon which models and other software products (applications) are developed.
In the 1970s and the 1980s, site-specific river basin models were developed by engineers for water management organisations (Zagona et al. 2001). Different organisations used different approaches, hardware and software technologies to develop models suitable to their needs at that time. These models, with limited representation of hydrological processes, could not be easily modified and were not flexible enough to apply in other sites and to incorporate new components for changing modelling needs. For example, within the Murray–Darling Basin (MDB) of Australia, different models have been used by different jurisdictions. The Queensland and New South Wales state governments use the Integrated Quantity and Quality Model (IQQM) (Simons et al. 1996; Podger 2004; Podger & Beecham 2004) at daily time scale. The Victorian state government uses the Resource Allocation Model (REALM) (Diment 1991; Perera et al. 2005) at monthly scale. The Murray–Darling Basin Authority uses the Monthly Simulation Model (MSM) with BigMod (Close 1996; MDBC 2002) to model river flow for the Murray. These models are hard to combine due to different modelling concepts and temporal and spatial resolutions.
The eWater Cooperative Research Centre (CRC) in partnership with several governmental and non-governmental organisations within Australia has recently developed an integrated modelling software called the eWater Source (shortened to Source from here on) that is designed to provide a common catchment and river modelling platform across Australia (Dutta et al. 2012, 2013; Welsh et al. 2013). Source has inherited many aspects from existing models, in particular, the IQQM, MSM-BigMod and REALM and it has addressed extensibility limitations making it a flexible platform for expanding uses.
The modelling tools that are mentioned above generally fall short in one aspect – since the models were hard-coded it was difficult to adapt new models of hydrological processes or incorporate complicated and changing management rules. Generally provided are ‘rules engines’ that give some flexibility in defining flow, constraints and management decisions (Hameed & O'Neill 2005; VU & DSE 2005a); however, one would have to be creative with the available components of the software and create dummy systems in order to represent complicated resource assessment and sharing systems (e.g., VU & DSE 2005b). Wurbs (1994) observed that engineers and scientists naturally prefer the flexibility provided in programs they have developed themselves, however it was not practical for each water management agency to develop flexible in-house models. Therefore, in Australian water resources modelling, the advancement of hydrological models was limited by modellers' software development capabilities or the resources available to acquire the help of software professionals (Welsh et al. 2013).
Best practice modelling dictates that some level of complexity is required in hydrological modelling to obtain results which can be comparable to observed data (Black et al. 2011). To achieve this, the models need to incorporate the dominant processes that impact the water balance in a system. Where interactions between domain-specific models (e.g., MODFLOW (McDonald & Harbaugh 1988), REALM, IQQM, MSM-Bigmod, WATHNET (Kuczera 1997) and rainfall–runoff (RR) models are important, a manual approach called ‘loose coupling’ is often adopted for integrating the results from different domains (Cuddy & Fitch 2010; Gijsbers 2010; Yang & Podger 2010). Loose coupling in the context of this paper refers to completing a particular model run and then once complete, using the results as input for another model. The term integration is used to describe any interaction between different applications, models, processes and/or interfaces. Source providing flexibility for users to more easily implement integrative approaches is arguably a way the river system modelling community can improve the predictive capabilities of their existing models. However, this would also give users the responsibility to apply best practice modelling techniques since the flexibility allows users to create more complex models than the available data justifies (Silberstein 2006).
In the context of spatially focused environmental management, geographic information systems (GIS) were the first set of tools that provided integration functionality. They provided data management, process modelling, analysis and visualisation tools in single packages, otherwise known as software services. Now, GIS tools address problems from a range of research disciplines including atmosphere-surface systems, hydrology, forestry and biology. Argent (2004) explains that this was a successful approach to integration; however, it resulted in modelling concept inflexibility, since GIS tools are often built with specific technical and conceptual structures in mind, opposed to a generic platform for environmental modelling. Meanwhile, the integration of GIS and environmental modelling has advanced with the ability to build model functions into the GIS and vice versa using flexible scripting languages (e.g., DeVantier & Feldman 1993; Engel et al. 1993) and development of spatial and visualisation component-ware (e.g., Argent & Mitchell 1999;Rebolj & Sturm 1999). However, GIS are yet to integrate many well-known hydrological models, for example, MODFLOW.
From a software development point of view, there is a huge amount of flexibility available to the developers and modellers to build specialised software applications. Generally, the flexibility is available via the software development frameworks, where library and service components of the frameworks are used by the developers to build an application. From these building blocks, a conceptual modelling structure can be built.
The principles of component-based software development also apply to modelling applications; however, there are some important attributes of the modelling discipline that make it unique to others. First, process models (e.g., RR, routing, groundwater–surface water interactions) are the major components of the application. The process models are combined to form the conceptual structure of applications and, depending on the flexibility of the applications, models can be adjusted, deleted, added and/or replaced. Second, the users of such applications include scientists, who are always exploring and inventing new models. As such, it is desirable for applications used for modelling to be flexible, and have a wide range of available models, functions and tools for visualisation and analysis (Argent 2004).
Some basic applications may allow access to the software framework's components but do not declare a highly defined conceptual structure, such as VisualTIME (Stenson et al. 2011). Similarly, applications such as MATLAB (MathWorks 2013) and R (R Core Team 2013) provide code-based modelling interfaces that have large and diverse ranges of tools within toolboxes and packages available for modelling, visualisation and analysis. These examples provide a large degree of flexibility, particularly with creating or adjusting conceptual structures of models. However, it is undesirable to develop a model from scratch if the conceptual structure replicates something already developed in the past. Conversely, highly developed software applications are completely inflexible in their conceptual structure, but usually provide more usability in their interface (e.g., MODFLOW, REALM, IQQM, MSM-Bigmod, WATHNET).
Generally, it is observed that flexibility decreases as the definition of conceptual structure increases as a software becomes more developed. Flexibility in these software applications comes from greater functionality, in the available modelling components, analysis tools and UI, requiring more effort on the part of the software developers to keep the applications up-to-date. Often the application can be more ‘current’ than the software framework as new and innovative methods are manually incorporated into the application instead of updating the software framework.
There are examples of concerted efforts to develop facilitations to integrate different legacy environmental modelling applications, such as GIBSI (Mailhot et al. 1997; Rousseau et al. 1997), which combines four legacy models with a database management system and a GIS. Another example is the IRSMF (Yang 2010), which is designed to link surface water and groundwater legacy models. Both examples are specialised software applications and therefore are limited to only use their respective specified legacy models, although there are applications that are designed to offer more generic approaches. For example, RAISON treats models as separate modules, only acting as a module management system, by managing the data handling, execution, visualisation and analysis functions (Argent 2004).
There is an increasing emphasis on using integrative approaches in environmental science. Argent (2004) summarises the software development approaches and concepts for integrating environmental models. More specific to hydrology, Wagener et al. (2010) describes cross-disciplinary integrations as a primary characteristic of future hydrologic research. A major challenge for environmental modellers is dealing with system complexity in circumstances that arise from non-linear, heterogeneous and dynamic processes involving hydrologic, biogeochemical, ecologic and human systems, with strong interactions and feedbacks. These are not easily derived from understanding the components of the system in isolation. To align with these challenges Source needs to be highly adaptable, to be able to easily implement integrative approaches. For integrative approaches to be used, Source needs to allow extension within the simulation. The extensions themselves must be specifically developed to depend on components of the host application.
One of the key features that Source provides is a platform to incorporate new components and functionalities. The philosophy of extensibility of hydrological applications is inherited from Source's predecessor, the E2 Catchment Modelling Framework (Argent et al. 2005, 2009; Argent 2007; Perraud et al. 2005), with which Source shares much of the conceptual structure and software implementation. Source gives users a platform to be able to add and develop features as plug-ins to the application. A plug-in is a set of software components that adds specific abilities to a larger software application. Plug-ins designed by the modelling community should help alleviate the pressure on developers on keeping applications up-to-date, increase the life of applications and enhance the flexibility of highly developed software. A particularly valuable feature of using plug-in architecture is that it allows plug-ins to effectively become part of the host application. This means there should not be any additional performance overhead compared to hard-coding since it enables intra-process communication between plug-in and host application (opposed to inter-process communication). This paper aims to determine how Source's plug-in functionality could be used to improve current river system modelling methods, and demonstrate that there is a negligible performance penalty involved in using Source plug-ins.
SOFTWARE DEVELOPMENT APPROACH
There are many examples of modern software designs that use plug-in architectures. Web browsers are well-known to utilise plug-in architectures since it is not possible to know all the media types that will be relevant when the web browsers are initially developed. For example, Macromedia's plug-in allows their Shockwave Flash animations to be displayed in popular web browsers (Chatley et al. 2003). The Eclipse Platform is used for building integrated development environments, and is another successful example of a system designed for long-term evolution using reusable and extensible components (Wermelinger & Yu 2008).
Source is developed using The Invisible Modelling Environment (TIME, Rahman et al. 2003) and includes a graphical UI, a command line interface and a web service interface (Penton et al. 2011). Most uses of the system are catered for by the graphical UI, including model building, model calibration and running scenarios. The command line and web services interfaces support batch runs and other styles of automation on either a local machine or remotely over a network.
Source allows users to open, create, change and save project files which are made up of one or more scenarios. The scenarios contain the configurable catchment and river system models. There are two scenario types available in Source: the River Management Schematic Scenarios for river forecasting, operations and river planning purposes, and scenarios created with the Geographic Wizard for catchment modelling. These scenarios include various components including a range of UI based tools for data analysis and import/export, catchment runoff models, ground–surface water interaction models, demand models, river regulation and storages, water quality models and a variety of resource assessment models. Even with such a comprehensive list of available models, to ensure applicability to a wide variety of hydrological modellers that covers multiple disciplines and scales, additional flexibility and customisations are required, since it is unfeasible to build functionality to meet the requirements for every user of Source. Nor is it practical to constrain users to only use Source's hard-coded functionality.
Using an object-oriented paradigm in the software architecture provides a means to substitute alternative, but in some way equivalent components, based on common interfaces. For example, a common interface may be defined for data sources that allows multiple sources of data to be used and substituted, without affecting the existing system (Argent 2004; Papajorgji 2005). The Source architecture supports user-developed models or tools to be ‘plugged in’ to different parts of the modelling process. Plug-ins offer flexibility without the significant computational burden of interpreters (which executes the code without prior compiling) or difficulties in modifying and maintaining the code base (eWater CRC 2011a). Source provides services for the plug-ins to use, including the Plug-in Manager which is a way for the plug-ins to register themselves with the host application, and protocols for the exchange of data. As the plug-ins effectively become components of the software at runtime, they too must be written to run on the .NET platform, although they do not need to be written in the same language that is used for the core product. Plug-ins are compiled to form dynamic-link libraries (DLLs). In the plug-in code, the user defines the location within Source that the DLL will be executed (the ‘plug-in point’). Source supports plug-in points for catchment, node or link models, data preprocessing tools, and extending or customising UI behaviour (Figure 1). Plug-ins can be categorised into two basic types: UI and Model Integration (MI) plug-ins.
UI plug-ins can be used to perform pre- and post-processing functions, for example, exporting model results to custom file formats. UI plug-ins can also perform and/or automate data processing tasks which would have otherwise been performed manually as a pre- or post-processing exercise, such as reformatting RR data from the Australian Bureau of Meteorology's SILO data drill (Jeffrey et al. 2001).
UI Plug-ins are conceptually different from MI plug-ins, although all MI plug-ins have some UI component. MI plug-ins are models of hydrological processes or management to be incorporated into Source. The model equations are solved for discrete time steps within the simulation period, for instance, for RR or groundwater flux models.
There are two basic ways of implementing a MI plug-in. The first way is to develop a class within a code that ‘inherits’ from an existing model template and implements or ‘overrides’ the required algorithms, such as the ‘run time step’ procedure required by most temporal models (it is called runTimeStep() in Source). The underlying mechanism to find the custom built methods is software reflection (Perraud et al. 2005). At the initialisation phase, Source will scan through all loaded DLLs to find the classes that inherit from the relevant model template and make them available for selection by the end user. For example, a plug-in could inherit from the RR model library of TIME (Rahman et al. 2003) and then the custom RR model would appear, alongside existing models, in the list of available RR models. This method requires adding the persistence mechanism so that Source maintains the user specified parameters of the model each time the project file is created, run, saved or re-opened. Source uses an object relational broker called NHibernate (Perkins 2011) to store Source projects in a database.
The other way of implementing a MI plug-in is by creating a new function to be added to the language of the Source Function Editor. The Function Editor allows users to define a value using an expression via a range of arithmetic, comparison and logical operators, time variables and functions. This tool is embedded in many of the core model elements, typically where a management rule or some other human behaviour (such as demand) needs to be captured (Penton & Gilmore 2009). Model parameter and input values can be dynamically dependent on the values of other model parameters. Function Editor plug-ins are software components as in any other plug-in, except they are specifically accessed via the Function Editor.
Function Editor plug-ins have been termed Custom Functions and are identified by the use of the CustomFunctionContainer attribute on the containing class and also the CustomFunction attribute on the containing function (Figure 2). Users are able to use Custom Functions within the Function Editor to operate on specified data during run time (Kim et al. 2011, Figure 3). When there is a referral to a function, Source will search through the CustomFunction attributes that are being used to find available Custom Functions.
Dynamic linking of plug-ins to Source allows constant data exchange through intra-process communication, because the plug-in effectively becomes part of the host application. One-way exchange of data from the plug-in to the Source run time is the simplest form of MI. These types of algorithms can be run independently of Source and give the same results since no data are required from the simulation. In these cases, loose coupling may be preferred since there is little benefit to the predictive performance in fully integrating these types of models when the alternative will give the same results. On the other hand, loose coupling inhibits the ability to perform repeated sampling for things such as parameter optimisation. Two-way data exchange means that some feedback is required by the plug-in and the plug-in has a dynamic relationship with Source (Figure 4). To illustrate, a RR model most typically has a one-way linkage to a river systems model. The RR model is respondent to climate, but not to any of the variables calculated within the river model. By comparison, a flow routing model operating within a single reach of the river model has, as one of its inputs, the incoming flow from upstream, thus it has a two-way data exchange with the rest of the river systems model. Finally, a demand model might be implemented as either a one-way or a two-way data exchange. If the demand model is independent of the operations of the river, in that it is not subject to demand restrictions or delivery shortfalls, then the demand model will produce the same result regardless of what happens elsewhere in the river systems model and could be implemented with one-way data exchange, perhaps as a loosely coupled component. If, on the other hand, the predicted demand is responsive to water availability in the overall system, such as areas of crop planting being dependent upon water allocation decisions, then the demand model needs a two-way data exchange with the rest of the model.
The following examples are given to demonstrate some potential uses of Source's plug-in functionality. The examples have been developed during trial demonstrations and testing of Source. The first example is for a data processing UI plug-in which is an important display of how plug-ins can be used to import data of a different scale, process it and run it in a Source simulation. It uses output from eWater Urban Developer (shortened to Urban Developer from here on) which is a modelling platform specifically designed to model the urban water cycle (eWater CRC 2011b). The second example is of a MI plug-in used as part of the resource assessment system for the Pioneer Valley, Queensland. This plug-in was developed as part of Queensland Department of Environment and Resource Management's Source trial demonstration to exhibit the extensibility of Source's resource assessment and Function Editor functionalities (eWater CRC 2011c). The final example was designed to exhibit the alternative to loosely coupling RR and river system models. This was achieved using the Function Editor and MI plug-ins using Custom Functions.
UI plug-in for upscaling Urban Developer to Source
In this practical use of UI plug-ins given by Dugge et al. (2012a), there was a requirement to use the daily model results of an Urban Developer application (eWater CRC 2011b) to upscale the model to a larger time step in Source, generating surrogate models that are faster to run but that recreate important characteristics of the original model output. A sampling scheme method was employed to select appropriate aggregated monthly values for use in a regional model (as recommended by Coombes & Kuczera (2003) and Kuczera (2008)). The model extension was implemented in a plug-in. The plug-in takes the daily output of an allotment or cluster scale model and preprocesses the data for use in a water demand node in Source that implements the original model presented in Kuczera (2008).
The k-Nearest Neighbour (kNN) Upscaling Preprocessor plug-in uses Urban Developer results. The Source UI for the plug-in is shown in Figure 5. The plug-in allows users to load Rain and Tank Yield files that will be plotted against each other. The ‘Clipping Threshold (c1)’ and the ‘Days at End of Month (c2)’ parameter can be adjusted and the plug-in will calculate the corrected monthly rainfall time series for the given parameter set and plot the tank yield time series against this corrected rainfall time series. The correlation coefficient is shown in the lower right of the plot area. By clicking ‘Auto-Calibrate’, a steepest ascent hill climbing algorithm is started that searches for the set of parameters that maximise the correlation coefficient (Dugge et al. 2012b).
After a suitable parameter set has been found, the corrected rainfall and the tank yield time series can be exported into a daily time step or monthly time step to incorporate in large system modelling in Source. The correction with the same parameter set can be applied to one or more other rainfall time series.
UI plug-ins have the potential to save time and effort for tasks such as data assimilation and processing. These types of plug-ins would be most desirable for ongoing activities that involve large data sets. This loose coupling example is a case where this functionality could be performed external to Source. However, the workflow is improved by developing a plug-in. In this case, the more the plug-in is used, the more value that will be returned for the initial effort required to build the plug-in. As a one-off exercise, there would be hardly any benefit over performing this task in external software. This particular plug-in is, however, likely to be frequently used since it provides a user-friendly means of upscaling Urban Developer models. Integrating numerical models into the simulation run rather than importing the output of externally run output also provides some time-saving capacity.
MI plug-in for water management rules for the Pioneer valley
In this example, there is a two-way data exchange. The river system requires this integration to be able to behave like the actual system. In addition, these resource management rules cannot be modelled externally since there is an interdependence of data between the plug-in and Source at each time step. That is, data for the current and previous time steps need to be fed into the resource calculation, the announced allocation is determined, and then data is fed back into the Source simulation. This example also uses the plug-in functionality to solve a complex problem in the announced allocation calculation. There is non-linearity caused by the interdependence of the transmission and operational allowance and the announced allocation calculations. This is solved by a simple root finding solver that continuously performs the announced allocation and transmission and operational allowance calculations until the solution converges. This method would have been difficult to implement using conventional hydrological modelling tools and is a unique selling point of this approach.
MI plug-in for a RR model (GR4J)
The daily rainfall–runoff model, Génie Rural à 4 paramètres Journalier (GR4J) (Perrin et al. 2003), is imported as a series of Custom Functions in a plug-in into a Source Rivers scenario (Kim et al. 2011). The Function Editor performs the series of calculations at each time step. The final expression requires 17 input variables to calculate runoff at each time step.
Four component types of the Function Editor were used in the RR model: Global Expressions, Variables, Time Series and Custom Functions. The calculations of GR4J are contained within the Custom Functions. Four input parameters, maximum capacity of the production store (x1), groundwater exchange coefficient (x2), maximum capacity of the routing store (x3) and base lag of the unit hydrograph (x4), were used for each Custom Function, which were calibrated externally. It is however, possible to calibrate the parameters using the automatic calibration wizard in Source (eWater CRC 2012d).
Eight of GR4J's variables are updated using Custom Functions at each time step. Figure 7's agreement between observed and modelled flow at a selected headwater catchment demonstrates a successful implementation of the GR4J algorithm using Function Editor and Custom Functions.
Using plug-ins to integrate models that are one-way data exchanges with Source can be an alternative to running in external software and manually importing results into Source. Both methods would yield the same results. Other than the benefits to workflow for the user, there is seemingly little additional advantage in running a single simulation rather than two. However, the simulations have become much more reproducible, which is important for design studies. Furthermore, having a fully integrated model allows repeated sampling methods such as optimisation. The integration of the GR4J RR model into Source's Function Editor through the use of Custom Functions is a one-way data exchange example. There are many other possible ways of incorporating the GR4J results into a Source Rivers scenario, including using the output of a Source Catchments scenario. However, in this example of a one-way data exchange plug-in, automatic adjustment of GR4J parameters could be performed to observe the effect on the Source Rivers scenario. Although in this example there is the alternative of using external software to produce the same results, there are times where the integration of models are necessary to model the dynamic relationships between different processes.
The time performance of simulations is a critical element for modellers. There is usually a very small performance penalty during application startup as the application has to scan for available plug-ins and load the associated DLLs into memory. The performance of running the plug-in is comparable to what it would have been if the plug-in was hard-coded into the container software, the exception being the case where the plug-in manager is doing some non-negligible operation while running the plug-ins. To investigate this, we compared the time performance between two methods for integrating a simple model: (1) using a custom function plug-in and (2) hard-coding. Results showed that there is no significant performance penalty for running the plug-ins compared to hard-coding in the application. A simulation that had 183 calls to plug-in code took a similar time to run the same simulation with the hard-coded method (Table 1). The reason for the similar timing is that once a plug-in is loaded into memory, it becomes part of the container software's process and the communication between plug-in and container becomes intra-process communication.
|Implementation||Number of calls||Total time (min:sec:millisec)|
|Custom Function plug-in||183||01:02:22|
|Implementation||Number of calls||Total time (min:sec:millisec)|
|Custom Function plug-in||183||01:02:22|
Software frameworks will have components to provide some flexibility to the user given that the user is using the software framework directly or the application used allows access to the components. In more specialised applications conceptual structures are more evolved and harder to change, and so it is more difficult to provide flexibility in these more developed applications. However, in these applications there are still options in providing components that can be accessed from the software framework or elsewhere. Plug-ins are able to enhance the flexibility of the applications that may have deep-seated conceptual structures.
From a flexibility perspective, it can be seen why many modellers prefer using software frameworks directly, such as TIME, or using generic modelling applications, such as MATLAB or R. Modellers are able to develop their own conceptual models, using a flexible scripting language. Modellers also appreciate the availability of flexible scripting languages in more specific applications, such as GIS.
Source has been developed with flexibility in mind with plug-in infrastructure to support extensibility in the UI and available models. Some benefit can clearly be seen through the use of integrating plug-ins into hydrological modelling tools such as Source, since it gives the freedom of scripting languages, while still making use of the existing structure and UI. However, does the improvement in modelling tools mean that there will be an improvement to the results of the models themselves? The discipline of hydrology is broad and hydrologists have widely varied backgrounds. Increased flexibility in modelling software is generally desired since it increases usability but also widens the spectrum of potential users for a single piece of software, without users needing the software development background to build functionality themselves. Allowing users to draw from their own expertise would theoretically reduce the probability of human error since users could use modelling methods that have already been validated. On the other hand, it gives the opportunity for users to introduce untested methods and to potentially produce inappropriate results, ranging from subtly wrong to nonsensical. Therefore, this customisation capability gives greater responsibility to the users of the software to adhere to best modelling practices. It is obvious that the usefulness of incorporating plug-ins in hydrological modelling tools will depend on whether they will save the user time and energy, and whether they will improve the predictive performance of the model. In this way, the plug-ins may contribute to increase in demand and enhance the life-span of the tools.
The performance assessment showed that the penalty of using plug-ins is insignificant. There should not be any reduction of simulation performance apart for the extra time required to run the plug-in code itself, since cross-DLL communications should not be significant at the simulation stage of the application's execution.
The paper has introduced the plug-ins functionality of eWater Source, a newly developed integrated hydrological modelling software, and demonstrated through several examples the capability of this functionality in enhancing the performance of the software. There are three main ways the plug-in functionality of Source could improve on current hydrological modelling: workflow efficiency can be improved during data processing such as in the preprocessing plug-in for upscaling Urban Developer to Source; the predictive performance of the models can be increased by integrating significant processes in an oversimplified base model such as in the plug-in for Water Management Rules for the Pioneer Valley; and it allows users to impart their own knowledge base which is easier than adopting new concepts, but also could potentially allow integration over multiple disciplines resulting in connecting the wider modelling and research community. Some workflow streamlining can be achieved in integrating models using the plug-in functionality but it is only necessary when the introduced models require feedback. Users should only use this functionality if there are not any hard-coded or manual alternatives that could be achieved in less time. Creating more complex models than what is justified by the available data should be avoided in accordance with best practice modelling guidelines. Basic performance benchmarking showed that using plug-ins had insignificant performance penalties over hard-coding.
The authors would like to acknowledge the members of the Source team, specifically David Penton of CSIRO for his contributions to the Function Editor functionality. We thank Matthew Stenson and Jie Chen of CSIRO for their constructive reviews of the manuscript.