WaterbalANce, a WebApp for Thornthwaite–Mather Water Balance Computation: Comparison of Applications in Two European Watersheds

: Nowadays, the balance between incoming precipitation and stream or spring discharge is a challenging aspect in many scientiﬁc disciplines related to water management. In this regard, although advances in the methodologies for water balance calculation concerning each component of the water cycle have been achieved, the Thornthwaite–Mather method remains one of the most used, especially for hydrogeological purposes. In fact, in contrast to physical-based models, which require many input parameters, the Thornthwaite–Mather method is a simple, empirical, data-driven procedure in which the error associated with its use is smaller than that associated with the measurement of input data. The disadvantage of this method is that elaboration times can be excessively long if a classical MS Excel ﬁle is used for a large amount of data. Although many authors have attempted to automatize the procedure using simple algorithms or graphical user interfaces, some bugs have been detected. For these reasons, we propose a WebApp for monthly water balance calculation, called WaterbalANce. WaterbalANce was written in Python and is driven by a serverless computing approach. Two respective European watersheds are selected and presented to demonstrate the application of this method. variables


Introduction
The hydrological balance is useful in many disciplines, from agriculture to hydrology and hydraulic engineering or more generally for water management purposes. Water balance refers to the balance between incoming water from precipitation and the outflow of water by evapotranspiration, groundwater recharge, and stream flow [1]. Even if several methods for monthly water balance calculation are available in the literature, the one introduced by Thornthwaite and Mather [2,3] is widely accepted. Although this method is empirical and outdated, it is used in several disciplines, especially in hydrogeology and for teaching purposes. As assessed by some authors [4,5], the Thornthwaite-Mather method performs well in humid regions where the precipitation and air temperature are the only input data. In accordance with other authors [6][7][8][9][10], this method underestimates monthly potential evapotranspiration (PET) under dry and arid climates, because the equation does not consider the saturation vapor deficit of the air. The issue was highlighted by the overestimation of monthly PET in the equatorial humid climate conditions of the Amazon [11]. Another important issue concerns its application to complex geological frameworks, where high permeability variations within the watershed may exist-for example, in carbonate and karstic aquifers, feeding streams, and springs or even highly

Outline of the Method
The WebApp is based on the Thornthwaite-Mather method, an empirical method used to estimate monthly water balance and originally presented by Thornthwaite and related itself [3,[22][23][24]. It requires the following input parameters: the latitude of the study area (LAT, decimal degrees), the mean monthly temperature (Tm, degrees Celsius), and the monthly total precipitation (P, millimeters). By adding the soil moisture storage capacity (SM, millimeters), the rainfall snowfall temperature threshold (SRT, degree Celsius), and runoff factor (beta, percentage), it is possible to calculate the watershed runoff. Beginning with temperature and latitude, the potential evapotranspiration (PET, millimeters) is calculated as follows Equations where k is the latitude-dependent correction factor accounting the number of days in the month and the actual number of hours of insolation; I is the annual heat index; a is a coefficient strictly proportional to I. For the computation of the actual evapotranspiration (AET, millimeters), the soil moisture storage capacity must be selected in reason of the soil and crop type [1,3]. After that, according to the difference between monthly precipitation and PET (millimeters) the soil moisture content changes to satisfy the water request from the soil system. The water surplus is generated only after the soil moisture conditions are satisfied and the temperature is above a rainfall-snowfall threshold (generally temperature >−1 • C) [25]. The runoff factor (beta) is the percentage of the monthly water surplus implied in the generation of the basin runoff, and it is usually settled equal to the 50% of the monthly water surplus [24]. In fact, following the classical rational method, it depends on surface cover and it is a constant value, strictly related to the percentage of impermeable catchment area [26][27][28]. Other authors have demonstrated a seasonal variability of the beta parameter over different climatic regions [29]. Although the setting of the runoff coefficient and soil moisture initial conditions is extremely important for predicting catchment response, this work aims to merely present an online application, which speeds up a widely accepted routine, and it does not consider the calibration of such parameters. The issue related to the snow accumulation and its melt rate is avoided through a simple mass balance. In fact, the snowmelt is generally calculated through energy balance methods or physical-based approaches, which require the availability of several meteorological and hydrological input parameters, which are usually difficult to acquire [30]. The steps involved in the calculation are summarized in the workflow presented in Figure 1. Using this method, it is possible to calculate the components of the water cycle according to the Thornthwaite-Mather method and, in addition, the monthly snowmelt runoff (SMRO, millimeters) and the monthly total runoff (TOT RO, millimeters).

Exporting Algorithm to the Cloud
Today, the serverless computing approach is transforming attitudes towards computing. In particular, the serverless approach is widely used in common applications but is attracting the attention of scientists owing to its capability of allocating resources in real time according to the number of requests/users, as reported in [31,32]. Several service providers offer function-as-a-service (FaaS) solutions that could be used also for scientific computation. A set of functions could be easily exposed to the cloud owing to the availability of different runtime environments, such as Python, NodeJS, .NET core, and Java. In particular, the use of Python by scientists is increasing, and this is demonstrated by the wide availability of code and notebooks written in Python. The ability to convert programmed functions or methods into ready-to-use cloud services is leading to a seemingly serverless development and deployment experience for application software engineers. Without the necessity of allocating resources beforehand, the prototyping of new features and workflows is becoming faster and more convenient for application service providers. These advantages have served to boost the industry trend consequently called serverless computing. The more precise, almost overlapping term in accordance with everything-as a-service (XaaS) cloud computing taxonomies is function-as-a-service (FaaS).
The first implementation of the algorithm was performed in MATLAB. We decided to open up the application to external users, and the export of MATLAB code directly to the cloud is not straightforward. For this reason, we decided to port the code into the Python language using libraries such as numpy, matplotlib, and pandas. After the porting, we designed a cloud architecture based on the serverless approach to reduce the complexity as much as possible in order to maintain and scale the computing. The development of a WebApp simplifies the interaction with users, who are focused on the analysis of data without installing additional software modules. Figure 2 shows the adopted architecture that relies on cloud-based services. In particular, the user provides the required information through the front-end (see  The first implementation of the algorithm was performed in MATLAB. We decided to open up the application to external users, and the export of MATLAB code directly to the cloud is not straightforward. For this reason, we decided to port the code into the Python language using libraries such as numpy, matplotlib, and pandas. After the porting, we designed a cloud architecture based on the serverless approach to reduce the complexity as much as possible in order to maintain and scale the computing. The development of a WebApp simplifies the interaction with users, who are focused on the analysis of data without installing additional software modules. Figure 2 shows the adopted architecture that relies on cloud-based services. In particular, the user provides the required information through the front-end (see  Workflow of the WaterbalANce code. P = monthly precipitation (mm); Tm = mean monthly temperature ( • C); LAT = latitude ( • ); SM = soil moisture storage capacity value (mm); beta = dimensionless runoff coefficient (%); SRT = snowfall rainfall threshold ( • C); PET = monthly potential evapotranspiration (mm); delta = P-PET (mm); AET = monthly actual evapotranspiration (mm); ST = monthly soil moisture (mm); S = monthly water surplus (mm); RO = monthly runoff (mm); RES(i − 1) = dynamic water stored in the basin in the previous month (mm); RES = dynamic water storage available for the next month (mm); SMRO = monthly snow melt runoff (mm); TOT RO = monthly total runoff (mm).    Data are uploaded according to a template that we provide to the end-user. In this phase, the application interacts with API gateway that triggers the lambda function. The lambda function stores the file in a storage service (S3). After the file is stored, the algorithm is executed using a custom layer on the lambda function to include the required dependencies mentioned above. At the end of execution, the final report is stored in the cloud storage, and using a simple notification system service, a message is sent to the enduser, allowing them to retrieve the results in a format such as an Excel spreadsheet file and a graphical plot ( Figure 4). In this way, it is possible to scale the processing of multiple requests. We decided to send the results by using an e-mail considering that the user wishes to start the processing in an asynchronous way, without actively waiting. We decided to use the lambda function as limits in terms of resources (e.g., memory) for our application were expected. An alternative approach in the case of large datasets could rely Data are uploaded according to a template that we provide to the end-user. In this phase, the application interacts with API gateway that triggers the lambda function. The lambda function stores the file in a storage service (S3). After the file is stored, the algorithm is executed using a custom layer on the lambda function to include the required dependencies mentioned above. At the end of execution, the final report is stored in the cloud storage, and using a simple notification system service, a message is sent to the end-user, allowing them to retrieve the results in a format such as an Excel spreadsheet file and a graphical plot ( Figure 4). In this way, it is possible to scale the processing of multiple requests. We decided to send the results by using an e-mail considering that the user wishes to start the processing in an asynchronous way, without actively waiting. We decided to use the lambda function as limits in terms of resources (e.g., memory) for our application were expected. An alternative approach in the case of large datasets could rely on an on-demand node that could be activated and managed by Kubernetes as a task, but for our scenario, this configuration was not applicable. We also released the source code under the GNU GPLv3 license as a public git-hub repository (public repository used to share the code developed in the context of this work can be accessed via the following URL: https://github.com/vrai-group/thornwaterbalance accessed on 12 January 2021) for users who wish to integrate the developed algorithm into their pipeline.
for our scenario, this configuration was not applicable. We also released the source code under the GNU GPLv3 license as a public git-hub repository (public repository used to share the code developed in the context of this work can be accessed via the following URL: https://github.com/vrai-group/thornwaterbalance accessed on 12 January 2021) for users who wish to integrate the developed algorithm into their pipeline.

The Practical Case of the Reno at Pracchia Watershed (Northern Apennines, Central Italy)
The first application of the model was performed on a watershed with a drainage are of roughly 39.8 km 2 , located in the highest region of the Reno river (Northern Apennines, Italy), upstream of Pracchia village (610 m a.s.l.). Its maximum elevation is approximately 1640 m a.s.l., while the basin's mean elevation is around 890 m a.s.l. From a geological point of view, the catchment is characterized by the lithologies of the Tuscan Nappe and Cervarola Unit ( Figure 5). The Tuscan Nappe Unit crops out extensively in the Northern Apennines and comprises a calcareous to shaly succession (Triassic-Oligocene) and, at the top the Macigno Fm. (Upper Oligocene-Lower Miocene), a thick arenaceous turbidite succession that is late Oligocene-Early Miocene in age. The Cervarola Unit (Lower-Middle Miocene) covers broad areas of the Northern Apennines and is mainly formed by a thick arenaceous turbidite succession. The permeability of these lithologies is mainly driven by widespread tectonic deformation, demonstrated by extensive fracturing [33]. Consequently, the hydrogeological framework consists of small springs, with a local  The first application of the model was performed on a watershed with a drainage are of roughly 39.8 km 2 , located in the highest region of the Reno river (Northern Apennines, Italy), upstream of Pracchia village (610 m a.s.l.). Its maximum elevation is approximately 1640 m a.s.l., while the basin's mean elevation is around 890 m a.s.l. From a geological point of view, the catchment is characterized by the lithologies of the Tuscan Nappe and Cervarola Unit ( Figure 5). The Tuscan Nappe Unit crops out extensively in the Northern Apennines and comprises a calcareous to shaly succession (Triassic-Oligocene) and, at the top the Macigno Fm. (Upper Oligocene-Lower Miocene), a thick arenaceous turbidite succession that is late Oligocene-Early Miocene in age. The Cervarola Unit (Lower-Middle Miocene) covers broad areas of the Northern Apennines and is mainly formed by a thick arenaceous turbidite succession. The permeability of these lithologies is mainly driven by widespread tectonic deformation, demonstrated by extensive fracturing [33]. Consequently, the hydrogeological framework consists of small springs, with a local groundwater recharge system emerging from the passage between the sandstone and marly and clay lithologies [34]. The area is characterized by uniform morphometric setting, and due to its small size and the scarce anthropization around the riverbed, it is well suited to this type of analysis. The watershed is equipped for total rainfall and temperature and river discharge measurements, and the devices are owned by Servizio Idrometeorologico-ARPA Emilia Romagna Region; the daily and the mean monthly temperature, precipitation, and river discharge have been monitored and published in the Annali Idrologici reports (Part I, Part II) since 1968. Two different, continuous discharge datasets for the Apennines watershed were selected: the first covered January 1971 to December 1976 (Series I) and the second covered January 2008 to December 2018 (Series II). A descriptive statistical analysis was conducted (Table 1). ting, and due to its small size and the scarce anthropization around the riverbed, it is well suited to this type of analysis. The watershed is equipped for total rainfall and temperature and river discharge measurements, and the devices are owned by Servizio Idrometeorologico-ARPA Emilia Romagna Region; the daily and the mean monthly temperature, precipitation, and river discharge have been monitored and published in the Annali Idrologici reports (Part I, Part II) since 1968. Two different, continuous discharge datasets for the Apennines watershed were selected: the first covered January 1971 to December 1976 (Series I) and the second covered January 2008 to December 2018 (Series II). A descriptive statistical analysis was conducted (Table 1).   To run the model and to provide an example to the WebApp stakeholders (presented in the "Methods" section of the WebApp), the LAT, SM, SRT, and beta parameters were set based on expert knowledge of the geographical, geological, and climatic features of the area [35]. Respectively, LAT = 43 degrees, the SM = 200 mm, SRT = −1 • C and beta = 70%. Starting with TOT RO (mm) obtained as output, the modelled discharge (m 3 /s) was calculated by multiplying the latter with the drainage area (39.8 km 2 ).

The Practical Case of the Savica at Ukanc Watershed (Northwestern Slovenia)
The second application of the WebApp was performed on the highest region of the Savica river (Northwestern Slovenia, Figure 6). To run the model and to provide an example to the WebApp stakeholder in the "Methods" section of the WebApp), the LAT, SM, SRT, and beta param set based on expert knowledge of the geographical, geological, and climatic the area [35]. Respectively, LAT = 43 degrees, the SM = 200 mm, SRT = −1 °C 70%. Starting with TOT RO (mm) obtained as output, the modelled discharge calculated by multiplying the latter with the drainage area (39.8 km 2 ).

The Practical Case of the Savica at Ukanc Watershed (Northwestern Slovenia)
The second application of the WebApp was performed on the highest r Savica river (Northwestern Slovenia, Figure 6). The drainage area is roughly 67 km 2 , and it extends from 520 to 2800 m a. river provides the main recharge of Bohinj Lake, the largest natural lake in Sl it is one of the two main sources of the River Sava, which constitutes the boundary river basin in the West Balkans and is part of the Danube basin [ geological point of view, the catchment is predominantly Dachstein limeston Triassic age, subordinated by a small number of dolomite beds [38]. In acco The drainage area is roughly 67 km 2 , and it extends from 520 to 2800 m a.s.l. [37]. The river provides the main recharge of Bohinj Lake, the largest natural lake in Slovenia, and it is one of the two main sources of the River Sava, which constitutes the main trans-boundary river basin in the West Balkans and is part of the Danube basin [36]. From a geological point of view, the catchment is predominantly Dachstein limestone of Upper Triassic age, subordinated by a small number of dolomite beds [38]. In accordance with many other authors [39][40][41], the main river recharge area is positioned on the high karstified mountainous plateau that extends into the rugged high mountain chain. Data on river discharge are available only at the gauging station, Savica Ukanc (Elev: 528.83 m a.s.l), which is positioned 720 m before the confluence of the river with Bohinj Lake. Rainfall measurements are provided by the Slovenian Environmental Agency, and the rainfall station gauge available in the watershed is Bohinjska Cesnjica. LAT, SM, SRT, and beta parameters were set, respectively, to: LAT = 46 degrees, the SM = 100 mm, SRT = −1 • C, and beta = 50%. Starting with TOT RO (mm) obtained as output, the modelled discharge (m 3 /s) was calculated by multiplying the latter with the drainage area.
We emphasize that in both applications, SM and beta are not calibrated. Modelled discharge values were compared to the measured values by using Pearson's coefficient of determination (R 2 ), a standard means of measuring the error of a model in predicting quantitative data. The application of the model to the Reno at Pracchia watershed was also validated in a mean annual hydrologic year. This option can be set directly through the graphical user interface (Figure 3). Moreover, to identify if the discrepancy between measured and modelled discharge is linked to the peculiar meteoclimatic conditions, the difference between measured and modelled discharge data was plotted against the mean monthly precipitation (Figure 9).

Reno at Pracchia Watershed
For each time series, mean monthly modelled discharge values with an associated error of 5% were compared to the observed values ( Figure 7). karstified mountainous plateau that extends into the rugged high mountain chain. Data on river discharge are available only at the gauging station, Savica Ukanc (Elev: 528.83 m a.s.l), which is positioned 720 m before the confluence of the river with Bohinj Lake. Rainfall measurements are provided by the Slovenian Environmental Agency, and the rainfall station gauge available in the watershed is Bohinjska Cesnjica. LAT, SM, SRT, and beta parameters were set, respectively, to: LAT = 46 degrees, the SM = 100 mm, SRT = −1 °C, and beta = 50%. Starting with TOT RO (mm) obtained as output, the modelled discharge (m 3 /s) was calculated by multiplying the latter with the drainage area.
We emphasize that in both applications, SM and beta are not calibrated. Modelled discharge values were compared to the measured values by using Pearson's coefficient of determination (R 2 ), a standard means of measuring the error of a model in predicting quantitative data. The application of the model to the Reno at Pracchia watershed was also validated in a mean annual hydrologic year. This option can be set directly through the graphical user interface (Figure 3). Moreover, to identify if the discrepancy between measured and modelled discharge is linked to the peculiar meteoclimatic conditions, the difference between measured and modelled discharge data was plotted against the mean monthly precipitation (Figure 9).

Reno at Pracchia Watershed
For each time series, mean monthly modelled discharge values with an associated error of 5% were compared to the observed values ( Figure 7). In Figure 8a,b, mean monthly measured discharge data are plotted against the modelled data. The correlation is slightly stronger for Series I (R 2 = 0.87) with respect to Series II (R 2 = 0.83). This result is also evidenced by Figure 9a, for which the difference between measured and modelled discharge is close to zero for all the observed periods. Regarding Series II, the larger differences between measured and modelled data were collected during the rainiest months (e.g., November 2009, 2014, 2016, and December 2013. In all these periods, we observe a positive difference of around 2 cubic meters, always suggesting a higher measured discharge with respect to the modelled value (Figure 9b). This finding could be connected to extreme rainfall events that occurred after prolonged dry periods. In Figure 8a,b, mean monthly measured discharge data are plotted against the modelled data. The correlation is slightly stronger for Series I (R 2 = 0.87) with respect to Series II (R 2 = 0.83). This result is also evidenced by Figure 9a, for which the difference between measured and modelled discharge is close to zero for all the observed periods. Regarding Series II, the larger differences between measured and modelled data were collected during the rainiest months (e.g., November 2009, 2014, 2016, and December 2013. In all these periods, we observe a positive difference of around 2 cubic meters, always suggesting a higher measured discharge with respect to the modelled value (Figure 9b). This finding could be connected to extreme rainfall events that occurred after prolonged dry periods.     Regarding the correlation of discharge data calculated in a mean hydrological year (Figure 8c,d), the Series I again demonstrates a slightly stronger correlation (R 2 = 0.97) with respect to Series II (R 2 = 0.95), both stronger than the monthly results.
The choice of SM and beta parameters, although not calibrated, have led to good simulation of the flow rates of the Reno at Pracchia watershed. Table 1 shows the basic statistical results for the analyzed time series, with particular attention given to the model's results and the hydrological conditions during the monitoring period. As supported by the Pearson's coefficient of determination (Figure 7), the measured and modelled statistical parameters are extremely similar to one another. For instance, the mean discharge values for both the time series are quite similar (1.572 m 3 /s vs. 1.591 m 3 /s in Series I and 1.389 m 3 /s vs. 1.599 m 3 /s in Series II), also confirmed by the median values.

Savica at Ukanc Watershed
The results for the Savica at Ukanc watershed, presented in Figure 10, highlight the good performance of the Thornthwaite-Mather method during the winter and autumn seasons, while a discrepancy between modelled and measured discharge was observed between April and June. Regarding the correlation of discharge data calculated in a mean hydrological year (Figure 8c,d), the Series I again demonstrates a slightly stronger correlation (R 2 = 0.97) with respect to Series II (R 2 = 0.95), both stronger than the monthly results.
The choice of SM and beta parameters, although not calibrated, have led to good simulation of the flow rates of the Reno at Pracchia watershed. Table 1 shows the basic statistical results for the analyzed time series, with particular attention given to the model's results and the hydrological conditions during the monitoring period. As supported by the Pearson's coefficient of determination (Figure 7), the measured and modelled statistical parameters are extremely similar to one another. For instance, the mean discharge values for both the time series are quite similar (1.572 m 3 /s vs. 1.591 m 3 /s in Series I and 1.389 m 3 /s vs. 1.599 m 3 /s in Series II), also confirmed by the median values.

Savica at Ukanc Watershed
The results for the Savica at Ukanc watershed, presented in Figure 10, highlight the good performance of the Thornthwaite-Mather method during the winter and autumn seasons, while a discrepancy between modelled and measured discharge was observed between April and June. Descriptive statistics of the temperature and precipitation data used as input in the model, coupled with basic statistics of mean monthly modelled discharge vs. measured discharge, are shown in Table 2. Considering the correlation between the mean monthly measured and modelled discharge data of the whole dataset from January 2016 to December 2019 (Figure 11a), Pearson's correlation coefficient is equal to 0.39. If the period between April and June for each year (red crosses in Figure 11b) is not considered, R 2 is equal to 0.83. This behavior can be explained by the underestimation of the precipitation that falls in solid form using the rain gauge available in the watershed. This discharge regime is classified in accordance with Figure 10. Comparison of mean monthly measured and modelled discharge, monthly precipitation, and mean monthly temperature data for Savica at Ukanc.
Descriptive statistics of the temperature and precipitation data used as input in the model, coupled with basic statistics of mean monthly modelled discharge vs. measured discharge, are shown in Table 2. Considering the correlation between the mean monthly measured and modelled discharge data of the whole dataset from January 2016 to December 2019 (Figure 11a), Pearson's correlation coefficient is equal to 0.39. If the period between April and June for each year (red crosses in Figure 11b) is not considered, R 2 is equal to 0.83. This behavior can be explained by the underestimation of the precipitation that falls in solid form using the rain gauge available in the watershed. This discharge regime is classified in accordance with [42], as predominately dominated by snow melting; then, the rainfall's contribution to the water balance is subordinated.  [42], as predominately dominated by snow melting; then, the rainfall's contribution to the water balance is subordinated. Regarding the applicability of the Thornthwaite-Mather method, although some limitations to its use are reported in the literature. For instance, the method is usually applied where the geological site is characterized by the presence of soil cover [43], but in a few cases, it has been used in soil-less environments such as karst limestone aquifers [44,45].
In our study, the discharge data for the Reno at Pracchia watershed are quite well simulated (particularly in Series I) using the Thornthwaite-Mather method. In contrast, the Savica at Ukanc watershed, which is affected by the underestimation of snowfall and snow melting, is not a suitable area for which to simulate river discharge in the period between April and June.

Conclusions
The implementation of a WebApp for automatic water balance calculation allows the users to more efficiently carry out computation for large datasets. End-users will be provided with a template where data can be easily uploaded. The use of a serverless approach also represents a new means of processing data in case of scientific use. Data (input and output) are managed through several cloud services decoupling each component, also enabling automatic scalability. An Excel spreadsheet file and a graphical plot are sent to the users by e-mail, allowing the process to be run several times using different input parameters. Thanks to this automatic procedure for water balance calculation, it is possible to more quickly test the applicability of the Thornthwaite-Mather method in different geological and hydrogeological contexts and to discuss the important issue, which deserves to be studied in greater depth. In fact, in contrast to the classic MS Excel spreadsheet file, where time is proportional to the amount of data, the use of a WebApp permits the execution of the Thornthwaite-Mather method in a few minutes, regardless of the amount of input data. Moreover, no additional software modules need to be installed, and this simplifies the interaction with the final user, who can focus on the analysis of data. The availability of the source code as a public git-hub repository is useful for users who wish to integrate the developed algorithm into their pipeline. Future improvements of the WebApp may involve consideration of fraction of monthly precipitation that becomes snow, the function of the temperature, geographic location, elevation, and the aspect, as suggested by [46], in addition to testing the method in different contexts. For example, particular attention should be paid to the infiltration process in the soil or even in soil-less Regarding the applicability of the Thornthwaite-Mather method, although some limitations to its use are reported in the literature. For instance, the method is usually applied where the geological site is characterized by the presence of soil cover [43], but in a few cases, it has been used in soil-less environments such as karst limestone aquifers [44,45].
In our study, the discharge data for the Reno at Pracchia watershed are quite well simulated (particularly in Series I) using the Thornthwaite-Mather method. In contrast, the Savica at Ukanc watershed, which is affected by the underestimation of snowfall and snow melting, is not a suitable area for which to simulate river discharge in the period between April and June.

Conclusions
The implementation of a WebApp for automatic water balance calculation allows the users to more efficiently carry out computation for large datasets. End-users will be provided with a template where data can be easily uploaded. The use of a serverless approach also represents a new means of processing data in case of scientific use. Data (input and output) are managed through several cloud services decoupling each component, also enabling automatic scalability. An Excel spreadsheet file and a graphical plot are sent to the users by e-mail, allowing the process to be run several times using different input parameters. Thanks to this automatic procedure for water balance calculation, it is possible to more quickly test the applicability of the Thornthwaite-Mather method in different geological and hydrogeological contexts and to discuss the important issue, which deserves to be studied in greater depth. In fact, in contrast to the classic MS Excel spreadsheet file, where time is proportional to the amount of data, the use of a WebApp permits the execution of the Thornthwaite-Mather method in a few minutes, regardless of the amount of input data. Moreover, no additional software modules need to be installed, and this simplifies the interaction with the final user, who can focus on the analysis of data. The availability of the source code as a public git-hub repository is useful for users who wish to integrate the developed algorithm into their pipeline. Future improvements of the WebApp may involve consideration of fraction of monthly precipitation that becomes snow, the function of the temperature, geographic location, elevation, and the aspect, as suggested by [46], in addition to testing the method in different contexts. For example, particular attention should be paid to the infiltration process in the soil or even in soil-less situations to improve the calibration of input parameters. The soil moisture storage capacity (SM) and the beta parameters, which influence the model discharge performance, should be improved by an automatic calibration procedure in order to minimize the associated mean absolute error between modelled and measured discharge. Once the calibration is performed on a basin with certain physical characteristics (e.g., soil and crop type, land use, morphometric characteristics, and lithology), the parameters obtained can aid in the simulation of the discharges of ungauged watersheds for water management.