Abstract

All early flood warning systems (FEWS) work with gauges and communications systems to collect and distribute hydro-meteorological measurements in real-time. The objective is to allow the authorities to take action before the flood reaches critical places. The FEWS of the lower Salado River basin, Argentina, were established after the flood of Santa Fe city in 2003. Frequent loss of information due to communication problems with the repository site increases the operational vulnerability of the network. First, the document analyses the flood frequency of the region using known statistical distributions. Then, it offers a low-cost solution to the loss of information problem based on an interface that transmits in parallel the network data through an electronic bypass without interfering with the FEWS satellite communication system. The tests carried out along three stations show the interface proved efficient in transmitting data via WiFi or mobile communications in real-time. The results establish a one-to-one data correspondence when the satellite system and the redundant system are active. The interface is based on low-cost single-board computers and routers. The variety of commercial sensors tested makes the developed interface portable to similar situations, and the savings achieved – maintenance cost – are significant.

INTRODUCTION

Nowadays it is common to find a wide variety of early warning systems, ranging from assessing the financial risk of bank conglomerates (Faranda et al. 2015) and famine spreading by drought (Senay et al. 2015) to volcanoes eruptions (Gregg et al. 2015) and the mitigation of the effects of natural disasters (Balis et al. 2013; Calvello et al. 2015). Nevertheless, the management of flood hazards is one of the most frequent and critical components of public safety due to its usually disruptive impact on public health and infrastructure (Plate 2007; Chen et al. 2014). Therefore, the establishment of Flood Early Warning Systems (FEWS) has been very active in the last decades to help decision makers deal with hazardous floods (Garrote & Bras 1995; Asante et al. 2007; Henonin et al. 2013; Verdin et al. 2016).

As defined by Plate (2007), a FEWS is a set of actions oriented to protect lives and properties whenever the river free surface elevation attains a pre-established threshold value. Almost all flood warning networks work with gauges and communications system to collect and distribute hydro-meteorological measurements. The information is used in real time to predict whether a flood is about to happen, when it is going to arrive at some critical points within the watershed, and how severe it is going to be.

Floods triggered by heavy rainfalls are of considerable interest in urban regions bounded or crossed by large or medium size rivers (Plate 2007; Fakhruddin et al. 2015). As such, a FEWS is irreplaceable for local authorities since it allows them to take proper action before the flood arrives (Asante et al. 2007; Henonin et al. 2013).

Consequently, an early flood warning embraces few detailed sequential steps (Plate 2007): capturing, transmitting, retrieving, forecasting, warning, and transforming. The last two stages comprise warnings to local decision makers and the population in general and then transforming the warnings into remedial actions. Figure 1 depicts the subsequent phases that make up a FEWS.

Figure 1

Sequential steps that make up a FEWS (see, e.g. Plate 2007; Henonin et al. 2013).

Figure 1

Sequential steps that make up a FEWS (see, e.g. Plate 2007; Henonin et al. 2013).

Flood warning systems that integrate rainfall monitoring with flood forecasting are now operational in many countries all over the world (Velázquez et al. 2009; Henonin et al. 2013). Indeed, any FEWS has evolved from fully integrated flood management tools involving short-term hydrological forecasting (Merkuryeva et al. 2015) to a stand-alone system that takes in-situ measurements to warn their clients via SMS (short message service) (Kuantama et al. 2013). The relevance of an operational FEWS becomes evident if the potentially avoided flood damages are computed, yielding an approximated benefit of 400€ for every invested € (Pappenberger et al. 2015).

However, the purpose of this work is not to review the state of the art underneath the operation of any FEWS, nor to go through the latest developments in technologies to ease the communications between the data capture and the required short-term flood forecasting (Guo et al. 2012; Pumo et al. 2016). Instead, this paper deals with the operation of the FEWS located in the lower watershed of the Salado River in Midwest Santa Fe Province, Argentina, and a cost-efficient solution to circumvent part of its transmission losses.

The Santa Fe City implemented its early warning network after the catastrophic flood suffered in 2003 (Vionnet et al. 2006). Nevertheless, and among other persistent problems, the network has been hampered by communication problems ever since. As a possible solution to this shortcoming, this work proposes an alternative way to transmit the data captured by the monitoring network without interfering with the proprietary hardware of the functioning FEWS, given the frequent missing of data. Although the implemented solution relies on affordable open source components, it is not similar to the alternative followed by Sadler et al. (2016), who resorted to Arduino platforms to design a low-cost data logging and transmission system for environmental sensors connected to a network. The solution consists of installing an interface that runs on a minicomputer coupled with a router to transmit the data through WiFi or mobile communications. The interface then accesses the data utilizing an electronic switch that avoids interfering with the satellite communication system embedded in the FEWS.

Thus, and according to Figure 1, the authors strictly restrict the discussion to the communication phase of a working FEWS; the low-cost solution found to circumvent the problem, and the test performed to check if the data packages transmitted by the alternative channel were indeed unaltered.

The aspects that contain the occasional or potential failure of a flood warning system are often minimized. An early and accurate warning is what defines an adequate warning network. In this work, a detailed field survey of more than seven years is presented, involving the direct action of some of its co-authors, who visited the Salado River Flood Warning Network several times, documenting the occasional and specific failures of each monitoring station. The survey is summarized in this paper, providing a clear picture about which item of the network fails most frequently. To the best of the authors' knowledge, there are few detailed statistics spanning seven years that document the failures of a flood warning system.

The survey triggered the need to find a technical solution, once it was detected that communication blockage was the most frequent failure. Therefore, the way to solve the problem of an operational Flood Warning Network, using pieces of hardware of common use combined with free software, is also a novel aspect if one takes into account that it was addressed from the academic, and not from the professional field. However, it is well-known that equipment developed by private industry for environmental applications is usually based on patented technology that manufacturers lock away from the public reach. As a result, the user is soon in a somewhat uncomfortable situation due to the impossibility of introducing changes in the hardware or software that controls the equipment.

In tune with the problems mentioned, one of the main contributions of the present work was the developed software to automatically emulate the manual process that operators generally perform in front of the station when they download data, without interfering with the normal operation of the network. The operator interacts with a graphical user interface (GUI) using images rather than commands executed line by line. The selected library (PyAutoGUI) allowed controlling, through a Python script, the mouse and keyboard to automate the interaction with the proprietary GUI software and thus emulating any desired manual operation. Such methodology was previously tested against several commercial devices such as a Campbell® station, Steven® and Spectrum® soil moisture sensors, and a Genica® phreatic level sensor and a Pegasus® station (the earlier three made in the USA, and the former two made in Argentina). The variety of commercial sensors and the scenarios tested make the proposed development easily transferable to other situations with restrictions of similar characteristics (closed software, lack of backup communication system). In this aspect, the solution proposed here is in tune with the work of Sadler et al. (2016).

In summary, the novelty of this work relies on three well-separated aspects; first, a detailed field survey of more than seven years detected that communication blockage of the flood warning system was the most frequent failure of the network. Second, the automatic manipulation of a GUI is a technical contribution that emerged due to the impossibility of accessing the manufacturer's application of each data unit of the network, with an end product that sends the data with incredible fidelity. Last but not least, the testing of the methodology with different devices and environments ensures a trouble-free and transferable product, making it attractive to similar systems or situations.

The remainder of the paper describes the main floods of the Salado River throughout the 20th century to present days, including a brief description of the damage suffered by the two bridges that cross the river since their construction in 1972. Then, the document continues with the method developed to solve the problem mentioned above. It includes a description of the FEWS of the Salado River, and the architecture of the proposed alternative to transmitting the data of the network without using the satellite communication system. The following section presents the results, which are mainly based on the comparison between several data packets sent simultaneously through the satellite and redundant communication systems. The paper ends by discussing the results and the far-reaching implication of the proposed solution. Finally, and to keep text to a minimum, the previous research conducted on commercial devices is summarized in Supplementary material, Appendix A. There, it is possible to find out how the developed interface interacts automatically with the proprietary GUI software of some devices. All developments are freely available to the reader in a Web repository.

MATERIAL AND METHODS

The major floods of the Salado River, Santa Fe, Argentina

The design of a FEWS requires the estimation of maximum water levels attained for floods corresponding to given return periods. This information is crucial for the city authorities and people located on the floodplain, along the riverbanks. Nonetheless, it is not the purpose of this work to carry out an exhaustive statistical analysis of the extreme floods of the Salado River. This section offers a brief account of the historical floods of the river, with an overview of the frequency distribution of the water heights. The flood of 2003 caused, for the first time, loss of human life besides severe damage to the public and private infrastructure. The official death toll was 23 (Vionnet et al. 2006). The serious consequences of the flood were the reasons behind the decision that pushed forward the local authorities to establish an early warning system.

The Salado River crosses several provinces of Argentina. It flows for about 1,150 km from the northwest of the country to its central part, near Santa Fe City (Figure 2(a)). The city borders on the west with that river, and to the east with the Paraná alluvial system (Figure 2(b)). Table 1 shows the great floods of the Salado River that affected the city in the last 100 years. The listed floods were generated in the lower watershed of the Salado River (Figure 2(a)). The region comprises a relatively flat area of approximately 30,000 km2. This region is located in the mid-west of the Province. In the last fifty years, the basin has undergone modifications in land use, as well as the development of a wide network of drainage channels. Areas with frequent flood risk have been occupied by the population over the years, increasing the vulnerability of the region. Despite these periodic setbacks, the lower river watershed supports a healthy economy that is vital for the region and the country.

Table 1

Major floods recorded on the Salado River, Santa Fe, Argentina

Year1914197319771998200320142016
Q (m3/s) 2,750 2,451 1,701 2,513 3,980 1,747 2,080 
Year1914197319771998200320142016
Q (m3/s) 2,750 2,451 1,701 2,513 3,980 1,747 2,080 
Figure 2

The Salado River, Santa Fe, Argentina. (a) The network and limits of the lower watershed; (b) the Santa Fe-Rosario Highway (satellite imagery source: Google Earth).

Figure 2

The Salado River, Santa Fe, Argentina. (a) The network and limits of the lower watershed; (b) the Santa Fe-Rosario Highway (satellite imagery source: Google Earth).

The Santa Fe-Rosario Highway (Province of Santa Fe) was inaugurated at the end of 1972. It was necessary to construct two bridges to cross the Salado river, stretching 157 m each in a place where the alluvial valley was 2,000 m wide (Figure 2(b)). At that time, the wetted cross-section was about 500 m2 under the bridges. Both structures were destroyed during the 1973 flood. Surveys carried out after the flood revealed that the cross-section had tripled its size, with erosions deeper than 5 m from the initial bed level. The bridges were rebuilt with a pile foundation placed at a much greater depth but still the same span, 157 m. The flood of 2003 again affected the bridges, collapsing one of the abutments (Figure 3(a)). The bridges were rebuilt once again, this time stretching a total of 578 m (Figure 3(b)).

Figure 3

Bridges of the Santa Fe-Rosario Highway over the Salado River during and after the 2003 flood. (a) Collapse of the westward abutment; (b) Reconstruction after the flood.

Figure 3

Bridges of the Santa Fe-Rosario Highway over the Salado River during and after the 2003 flood. (a) Collapse of the westward abutment; (b) Reconstruction after the flood.

It is possible to infer the statistics of extreme floods of the Salado River by looking at the 1953–2019 daily water level data. The records correspond to the Santo Tomé station by the Salado River outlet at the Paraná alluvial system, and the cross-section SR70, located 25 km upstream (Figure 2(b)). The data set comprises 22,327 readings of the river stage, which were converted to water surface elevation above sea level (the official datum of the Argentine Republic (IGN: www.ign.gob.ar/)). The 67-year long record has missing readings between the years 1988–1992.

Figure 4 shows the histogram of the water level readings at both stations. The histogram describes not only the spread of the data but also the disparate behavior of the water surface elevation at both sites. The hydrology regimes of the Salado and the Paraná rivers are independent. The histogram of the water height at the Santa Tomé station, located nearby the Salado River mouth, is affected by the backwater effects induced by the water surface elevation of the Paraná River. Consequently, it is unable to spot the two peaks of the bi-modal distribution of the SR70 station, which is 25 km upstream. These two peaks correspond to periods of low water, or dry seasons, and medium to high water, or periods of wet seasons. However, the relevance of the Santo Tomé scale to the warning system is crucial. The failure of the protection levee, built to protect people living in lowlands from the periodic flooding of the Salado River, was so dramatic during the 2003 flood that at one point the water was 2.48 m higher within the city than on the riverside, near the location of the Santo Tomé scale (Vionnet et al. 2006).

Figure 4

Histogram of river stages at the Santo Tomé station and the State Road 70 (SR70) station. The zero level for both scales is 8.07 m for the Santo Tomé station, and 11.09 m for the SR70 station.

Figure 4

Histogram of river stages at the Santo Tomé station and the State Road 70 (SR70) station. The zero level for both scales is 8.07 m for the Santo Tomé station, and 11.09 m for the SR70 station.

Finally, the available data set allowed the estimation of the return period of the 2003 flood using traditional two- and three-parameter distributions (Supplementary material, Appendix B).

The FEWS at the lower watershed of the Salado River, Argentina

After the catastrophic flood suffered by the area and the Santa Fe City in 2003 (Vionnet et al. 2006), the Government of the Santa Fe Province called for the implementation of a FEWS, a bid awarded to a joint venture between a Buenos Aires-based company and a firm in charge of the hydro-meteorological measurements nationwide (Tecmes & Evarsa 2006).

The network initially consisted of 41 stations, with only 36 fully operational until now (Figure 2(a)). Among them, 24 measure river stages, nine rainfall and soil moisture, and five rainfall, soil moisture, relative humidity, atmospheric pressure, phreatic levels, solar radiation, evaporation, and wind speed (Contini et al. 2014).

Each station has an outer enclosure which protects an inner cabinet that complies with the IP65 standard (water-dust resistant) and hosts the datalogger with the Remote Transmission Unit (RTU), the wiring of the terminal blocks, the satellite module transmitter and the power system (battery, charger, and voltage regulator). In turn, each unit also has a service port allowing in-situ manual management, so providing access to data already stored in the datalogger with the aid of the proprietary software.

All stations, either fed with solar energy or from the power grid, measure the state-of-charge of their batteries, log the information internally, and whenever there is storage capacity available, upload and transmit the collected data to the final government repository site through the Orbcomm satellites (LEO – low Earth orbit satellites operated by the company Orbcomm, www.orbcomm.com).

Failures in any FEWS are mostly due to flaws in the functioning of sensors and data-loggers, as well as a power outage and transmission losses or environmental factors (e.g. lightning strikes). Vandalism is another source of partial or total failure. However, the incidence of any factor does not always end in complete data loss.

In other to analyze the occurrence of those factors, the FICH at the UNL and the Ministry of Public Works of the Government of Santa Fe Province signed an agreement for surveying the network performance for the period 2008–2013 (Macor et al. 2016). It was possible to totalize 2573 visits, with an average of 11.9 per station per year (Table 2, Contini et al. 2014). The lower number of visits in 2011–2012 was due to insufficient funds to afford the field trips.

Table 2

Number of visits to the Salado River FEWS network (2008–2013)

Year080910111213
Visits 538 502 449 309 303 472 
Year080910111213
Visits 538 502 449 309 303 472 

During the field campaigns, the FEWS' companies supplier (Tecmes & Evarsa 2006) and the labor inspectors (Macor et al. 2016) agreed to fill out several surveys throughout the elapsed time of the consulting contract, and so they obtained a database organized according to the detected fault of each station:

  • sensors: when observing unstable readings or losses of the parametrization settings,

  • dataloggers: due to flaws in the proprietary software or connection problems which nullify the data reception,

  • power outage: related to missing or broken panels, or to a faulty voltage controller of a battery close to its useful life,

  • transmission losses: triggered by missing or broken antennas, a coaxial cable deterioration, or with the Orbcomm system,

  • bugs: due to the presence of bees, wasps, ants and nests that could damage the electronic components,

  • weather: produced as a result of some extreme weather events (hail, lightning, or high winds), and

  • vandalism: damages provoked by antisocial behavior (e.g. gunfire, robbery, or fire).

Table 3 shows the number of failures observed in the years 2008–2013. Figure 5 depicts a stacked frequency histogram, which makes it easier for the quantitative comparison among the contributing factors to failure. The most frequent failure was the transmission losses, with an annual average of 22.6% occurrences. This flaw manifests itself as a delayed reception of the information or the eventual absence of the data package in the final repository site. The frequent repetition of this failure determines the operational vulnerability of the FEWS network, a critical aspect when the watershed is under extreme weather conditions or heavy rainfall (when certain thresholds are exceeded, and the network must activate warning alerts to local authorities).

Table 3

Factors affecting the Salado's River FEWS (2008–2013)

Failure080910111213Total
Sensors 13 16 12 18 70 
Datalogger 11 37 
Power 14 16 10 22 74 
Bugs 10 16 11 14 29 88 
Atmosphere 14 
Vandalism 46 
Transmission 36 17 14 11 13 96 
Total 85 79 60 56 56 89 425 
Failure080910111213Total
Sensors 13 16 12 18 70 
Datalogger 11 37 
Power 14 16 10 22 74 
Bugs 10 16 11 14 29 88 
Atmosphere 14 
Vandalism 46 
Transmission 36 17 14 11 13 96 
Total 85 79 60 56 56 89 425 
Figure 5

Frequency of factors affecting the FEWS performance.

Figure 5

Frequency of factors affecting the FEWS performance.

The second factor affecting the FEWS was the presence of bugs, with an average frequency of 20% followed by the failure of sensors with a mean of 16%. The losses attributed to vandalism were steady and around 10% yearly.

Despite the significant drop in transmission losses observed in 2013 (only 6% of the total, Figure 5), an extension of the consulting study with the Ministry of Public Works allowed the testing of this issue once again for the whole network during 2015. Figure 6 depicts, in solid lines, the continuous transmission of the referenced station, whereas the blanks indicate periods of silence with no link between the station and the Orbcomm satellites. The Orbcomm system is in charge of uploading and forwarding the information to the final repository site. The loss of information due to transmission problems was still there.

Figure 6

Signaling of 36 stations of the Salado River’ s FEWS network during 2015.

Figure 6

Signaling of 36 stations of the Salado River’ s FEWS network during 2015.

Functioning of the FEWS' network

Each station of the network acquires the hydro-meteorological data through a current loop working in the range 4–20 mA or 0–4,000 mV of voltage. The readings go in through a channel datalogger and convert to digital within the RTU according to a previously stipulated agenda. Then, a fixed and removable internal memory stores the data. If the measured value is above a preset risk threshold value; it broadcasts an immediate alarm. Otherwise, it is put on hold until the time for its transmission is attained.

The feeding of the Tecmes® acquisition and recording unit (RTU) depends on the installation site. The two options are: (1) a 12 Vdc battery to 220 Vac with automatic charger; or (2) a 12 Vdc battery with charge controller and solar panel. This unit is responsible for managing the data acquired by sensors, and transferring them to a communication module satellite of the Orbcomm network. The module continues to receive data until it has communication with the satellite.

The data uploaded to the satellite transponder is stored until there is communication with the Earth station in charge of managing the Orbcomm network. At that moment, the information is sent to the servers, and from there, to the data recipients through a directory with the clients' email addresses. Then, an email enters the central station of the FEWS through a specific software that decodes the information, which deploys the value of each remote station on a watershed map.

A low-cost interface to solve the transmission lost shortcomings

An interface software which runs on some added hardware was installed on three selected stations of the network to upload the measured data to an Internet server without affecting the pre-established link between the nodes and the repository site.

The expected operations to be executed by the interface were: (i) to set up or modify the working parameters for each installed sensor device, and (ii) to upload the recorded data to an Internet server which stores the measurements of the monitoring station.

Towards that aim, the work was broken down into successive stages: (1) conditioning the added hardware, (2) interacting with the proprietary software, (3) automating the download of historical or real-time data and reconfiguring sensors, (4) submitting data to the web through a VPN (virtual private network), and (5) viewing the data on a website.

This interface was used before to drive remotely commercial equipment purchased without the wireless communication module supplied by the manufacturer (López 2012).

Conditioning the added hardware

The interface works as a multi-platform Common Datalogger Interface (CDI) with minimal software dependencies. Figure 7(a) depicts the interface architecture layout.

Figure 7

(a) System architecture (in red): isolated stations (in black), stations within reach of an access point of the existing network. (b) The RTU with the MiniPC. Please refer to the online version of this paper to see this figure in colour: http://dx.doi.10.2166/hydro.2020.216.

Figure 7

(a) System architecture (in red): isolated stations (in black), stations within reach of an access point of the existing network. (b) The RTU with the MiniPC. Please refer to the online version of this paper to see this figure in colour: http://dx.doi.10.2166/hydro.2020.216.

The system has two critical constituents: (1) a host program used for uploading and transferring the data from the station dataloggers; and (2) a server, which receives, stores and finally re-transmits the data originated at each site belonging to the FEWS' network.

The interface requires two small devices to run, a SOHO (Small Office/Home Office) router and a general-purpose minicomputer (called MiniPC hereafter), the latter connected by USB or serial wire to the datalogger (Figure 7(a)). Consequently, a bundle of devices was ensemble first with the following features (Figure 7(b)): (1) one MiniPC equipped with a processor INTEL 2.41GHZ J1800 DC, a motherboard AsRock, Memory RAM 4 GB DDR3 1,600 MHz, a solid state disk (SSD) with a capacity of 128 GB, and a Mini-ITX cabinet with a power source of 60 W; (2) one SOHO router with an average power consumption of 0.6 W, equipped with a processor Atheros 400 MHz, Memory RAM 32 MB, 100 Mbps WAN/LAN Port, Wireless standard IEEE 802.11 ngb, and USB 2.0 Port.

It was essential to count with motherboards equipped with: (i) Real time clock alarm which allows the MiniPC to turn on automatically at any preset date and time, and (ii) Wake on LAN (WoL), which allows the MiniPC to be turned on remotely. The configuration of the former functionality is carried out in the power management section of each motherboard BIOS. For that reason, the network cards of the motherboards must support this protocol (this feature must be enabled from the BIOS). Also, it was vital to link the MiniPC to the Internet; a critical step since the proprietary software only works under Microsoft Operating System (OS), previously installed in each MiniPC. The task scheduler was duly programmed to run the developed interface automatically.

Depending on the FEWS' station locations, two options were considered as a function of the available power supply: one for those that have access to the grid power and are close to an Internet connection, and the other for the remote which are fed by a photovoltaic system. For the first alternative, an 802.11 wireless network was implemented that connects to the Internet access point existing at the location (Figure 7(a), in black). For the second option, the Internet access was achieved through a mobile phone (3G/GPRS/GSM, Figure 7(a), in red).

The MiniPC was installed at each station, always off albeit with a self-start according to a preset schedule. The router, of low consumption, has dual functionality. On the one hand it provided access to the Internet (WiFi or 3G/GPRS/GSM) while at the same time it offered an environment for a general purpose embedded GNU/Linux for remote access.

As previously indicated, some stations are powered by solar panels. For this reason, a battery of 12 V was attached to connect the MiniPC and the router, and a timer, with a voltage regulator to cut the battery power for the added router, with a window of 30 min for downloading and transmitting the data as a preset scheduled task.

Interaction with the proprietary software

Due to the impossibility of establishing direct communication with the RTU of each station without using the proprietary application, a software was developed to simulate the manual process performed by the network operators. It was crucial to avoid any interference with the proper functioning of the FEWS. The procedure yields an alternative dual route for wireless transmission, either for sending the records to the Internet or for receiving instructions remotely to modify the sensors parameters.

The software acts as an interface between the proprietary application provided by the manufacturer and the actions executed from a configuration file that is updated and modified from the Internet. The different functions that drive the interface resemble a layered architecture where each establishes some degree of communication with the underlying layer, known as a Common Datalogger Interface (CDI) (Figure 8).

Figure 8

Common data-logger interface (CDI).

Figure 8

Common data-logger interface (CDI).

The organization of the CDI relied on a single configuration file consisting of subsections, each containing the necessary specifications for each equipment to which the station is connected. For the present situation, the configuration file was adapted to work with a FEWS station. There are several subsections for managing commercial devices of different brands when more than one sensor is connected at the same time. In the current implementation, the interface software runs in Python. Consequently, and depending on the ASCII configuration file, the adopted design invokes one by one the Python module corresponding to each sensor.

Several languages allow manipulating GUI applications, such as PyAutoGUI (http://pyautogui.readthedocs.io) which was finally adopted, and whose purpose is to provide cross-platform Python modules for their automatization. PyAutoGUI offered the best possible interaction with the RTU software. One of the main advantages is that it provides a Python library with an automation environment which, in turn, allows the use of the language's benefits, such as object orientation, easy reading, and writing of configuration files. It simulates movements and mouse clicks, keystrokes combinations and also a search of images on the screen (Figure 8).

Automating the data download

The design of the monitoring station posed a difficulty from the start. Whenever an operator connects a laptop to the service port of any station of the network (e.g. in a maintenance visit, Figure 7(b)), it automatically overrides the satellite transmission module. Since the service port of the RTU was the natural choice to plug in the MiniPC to upload the data through the interface, it was necessary to build an electronic switch (on/off) to avoid the permanent overriding of the Orbcomm module (Figure 9).

Figure 9

Electronic switch circuit diagram.

Figure 9

Electronic switch circuit diagram.

The switch is energized with a 12 V Molex connector from a motherboard and connected to pin 3 of the parallel port of the MiniPC. Through the operating system, the switch is set in the high state to close the relay and to enable the communication between the MiniPC and the RTU, and in the low state when all tasks end. In this way, the in-situ manual connection and disconnection for downloading data is emulated.

The operation of the implemented system consists of a series of steps, some of which are configurable, ranging from setting the power-on to the automatic shutdown of the MiniPC (Figure 10). Briefly speaking, they amount to:

  • Self-starting: by using the MiniPC real time clock alarm Protocol (configurable from the BIOS).

  • Connection: by using the electronic switch (the software sets in a high state a pin of the parallel port so closing the circuit and thus emulating a manual connection).

  • Extraction: by downloading the data stored in the RTU and then by re-configuring the station.

  • Disconnection: by setting in a low state the pin of the parallel port so leaving the circuit open and thus emulating a manual disconnection.

  • Transmission: by using the Rsync protocol to transmit to an Internet server.

Figure 10

Operation workflow.

Figure 10

Operation workflow.

Uploading data to the web via a VPN

The use of a VPN enables remote access to computers that have a private IP from the Internet. For the current development, the VPN was set up in the MiniPC, which together with the TeamViewer package (www.teamviewer.com/es), allowed the remote access to the stations to perform unscheduled tasks (Figure 7(a)).

Then, and whenever scheduled, the acquired data are uploaded to an Internet server using the remote synchronization protocol Rsync to avoid loss or duplication of data. It uses an algorithm to reduce the amount of data sent over the network, transmitting only the differences between the source files and the destination files (Zhou et al. 1994).

Once a station node awakes, it downloads a configuration file if it has been changed remotely since the last login, and then uploads the associated data files to the cloud following a preset schedule. Listing 1 shows the associated bash commands for Station 32 (see Figure 6). 
formula
 
formula

Listing 1: Rsync commands: the first uploads the data to the internet server, and the second downloads the configuration files from the server.

The information then integrates a database for further processing before being transmitted to the final official repository site.

Viewing the data on a website

Most web services report according to the concepts of two layers; the front-end layer and the back-end layer which includes all the logic processes in charge of generating the results. The front-end layer is an outlet to portray the notifications produced by the backend. The backend layer uses a GNU/Linux server (www.tektonic.net) that hosts the data processing system consisting of a MySQL database, a Rsync daemon and Apache web server with PHP module and Python.

For the front-end layer, a dynamic website allows end users to obtain the information using customized queries. Furthermore, the raw files are available in a public repository using the original data format of each commercial device.

Once the interface synchronizes each field data, a set of Python scripts parses and stores them in a database. The system relies on the utility pyinotify (https://github.com/seb-m/pyinotify) that automatically executes when it detects any change in any directory. A Python script looks for new data files, and if they are present, the processing starts. It reads line by line getting the timestamp and the hydro-environmental recorded variable to put them all into the designed database.

Preliminary testing

The proposed alternative communication system sought to link a station of the FEWS network to a nearby stakeholder, or to a rural school having Internet access, otherwise through mobile technology. Consequently, some performance and stability checks were first run at laboratory scale to continue then at the field before moving the equipment to the selected monitoring sites.

An internal test brought by Ubiquiti equipment reaches speeds of about 180.39 Mbps in mixed transfer mode and 148.76 Mbps in one direction, so in the transmission to the terminal devices, the 100 Mbps RJ-45 interface reaches the limit before the maximum WiFi speed. The result showed a state of a permanent link, with no fall or reconnection and with a constant speed over time. Therefore the connection results were satisfactory against a certified WiFi access point 820.11n. Also, since for WiFi dish antennas the communication path must be a line of sight, to prove its duplex capacity a test was made in the laboratory by connecting a satellite dish directly to the rear connector of the router.

The second test consisted of placing the antenna on the first floor of the FICH Department, connected in turn to its Internet network, and putting the TP-Link MR3420 router with an antenna at two distant points (Figure 11). This device was configured to connect automatically at a different point to the signal emitted by the antenna. To verify the connection; the TP-Link MR3420 router was connected to a laptop computer, to which a few sample files were downloaded from a PC linked to the department's local network. Once the communication between the antennas was verified, both were taken to the field to establish the distance of reach between them. With that objective, one of them was held fixed to one side of the road while the other was carried in a vehicle until the signal faded (Figure 11).

Figure 11

Preliminary tests in lab and field.

Figure 11

Preliminary tests in lab and field.

In the field, the group also tested other types of WiFi antennas depending on the type of power supply available. Thirteen visits were made to the selected stations along the project, seven to Santa Fe, two to Santo Tomé and four to Flesia (see Figure 2(a) for locations).

The Santa Fe station (Figure 12) feeds from the power grid with AC. On the contrary, the Flesia station, which is on an isolated field site by the Flesia Creek, and the Santo Tomé station located by the Salado River (Figure 13), are fed by batteries powered, in turn, by solar panels without access to the Internet. In these cases, a 3G modem was used instead for the remote connection.

Figure 12

Setting up the redundant transmission system on the Santa Fe station.

Figure 12

Setting up the redundant transmission system on the Santa Fe station.

Figure 13

The Santo Tomé station.

Figure 13

The Santo Tomé station.

The Santa Fe station is located in the northwest part of the city, on premises owned by the Ministry of Public Works, and it has free access to the Internet. There, an 802.11 wireless link between two Ubiquiti antennas was installed, one of them adjacent to the administrative office and connected via Ethernet to the available network.

The TP-Link MR3020 was configured with OpenWRT (Holt & Huang 2014), which allowed remote access and to power on the MiniPC. Then, the remaining antenna was installed together with the MiniPC in the FEWS station. The Santa Fe station was frequently visited, given its convenient location, to verify the operation of the redundant communication system during the tests.

RESULTS

Both raw and verified data are uploaded and archived within the public server system as comma-separated, ASCII text files. Superusers or administrators can set the configuration parameters for each datalogger, to enable/disable sensors, and to increase/decrease the sampling and the data uploading frequency. The website allows users to access and send their customized queries. Then, users can choose different observation points and types of hydro-environmental variables between dates to download the information, or plot the temporal evolution of the records.

Although the system can preview filtered comma separated values from any formatted file, the relevance of the proposed solution is better appreciated whenever the transmitted data through the Orbcomm and the redundant channel are contrasted one against the other.

All sensors at the Santa Fe station were malfunctioning, except for the temperature sensor (Figure 14). The parity between both registers is visible, with five different and lasting gaps throughout the official record filled correctly by the backup system.

Figure 14

Orbcomm vs redundant transmission system on the Santa Fe station.

Figure 14

Orbcomm vs redundant transmission system on the Santa Fe station.

Figure 15 depicts the river stage evolution on the Flesia station over approximately 7 weeks. The data transmitted by the redundant system was one by one with the official record when both channels were on and correctly filled in the gaps left by the Orbcomm system in the three field experiments conducted.

Figure 15

Orbcomm vs redundant transmission system on the Flesia station.

Figure 15

Orbcomm vs redundant transmission system on the Flesia station.

Similarly, Figure 16 displays the outcome of one month of recording of the river stage at the Santo Tomé station; in coincidence with the peak of an ENSO (El Niño-Southern Oscillation) anomaly in the region. In this opportunity, in addition to failures in the Orbcomm system for periods that vary between 1 and 6 days, the RTU failed for about 3 days. The redundant system interrupted its transmission only once during a short period, less than a day on January 4, 2016. The developed interface could recover the data; but just the previous recorded day. Once again, a one-to-one correspondence is appreciated when both communication systems are active, as well as the achievement of the interface to fill in the missing information gaps.

Figure 16

Orbcomm vs redundant transmission system on the Santo Tomé station.

Figure 16

Orbcomm vs redundant transmission system on the Santo Tomé station.

DISCUSSION

Table 4 summarizes the total number of test days when both systems were working simultaneously, and their failure rates. Surprisingly, the official system exhibits a similar average failure rate (here weighted by observation days) to that detected in the consulting work carried out by FICH (Table 3 and Figure 5), while for the developed interface, the failure rate was lower than 1%.

Table 4

Failure rate of both systems

StationNumber of daysOfficial FEWS %Redundant system %
Santa Fe 13 18.0 0.0 
Santo Tomé 29 38.0 1.7 
Flesia 47 10.0 0.0 
Weighted average 89 20.3 0.7 
StationNumber of daysOfficial FEWS %Redundant system %
Santa Fe 13 18.0 0.0 
Santo Tomé 29 38.0 1.7 
Flesia 47 10.0 0.0 
Weighted average 89 20.3 0.7 

Without discussing the fact that, in the end, what matters most is the cost of maintenance, it is relevant to emphasize here that the proposed interface is based on affordable hardware parts in some cases and open source components in others. This is in sharp contrast to the costly monthly service imposed by the Orbcomm satellite system, necessary to make data available in real-time.

Each station would require one MiniPC (cabinet, motherboard, and processor), with one solid state disk of 120 Gb, 4 Gb of RAM DDR3, an electronic switch, a waterproof resistance cabinet, a Tp-Link MR3020 router, and a voltage regulator, all totaling €295 approximately (Table 5). The WiFi option will require two Ubiquiti NanoStation M5 antennas, two Ubiquiti Loco M5 antennas, and several meters of outdoor UTP cable CatE (about 15 m), all adding up to approximately €186 (Table 6). On the contrary, the 3G alternative will demand a 3G Modem Huawei, one timer, USB cable (around 5 m or so), and a 12 V battery, totaling approximately €53. The latter will add up to €168 of the annual mobile or cellular service charge, totaling €220 approximately (Table 7).

Table 5

Required hardware components for each station

Common componentsCost (€)
MiniPC (Cabinet + Motherboard + Processor) 143 
Solid state disk SSD 120 Gb 67 
Memory RAM 4 GB DDR3 28 
Key 14 
Waterproof cabinet 19 
Router Tp-Link MR3020 17 
Voltage regulator 
Subtotal 295 
Common componentsCost (€)
MiniPC (Cabinet + Motherboard + Processor) 143 
Solid state disk SSD 120 Gb 67 
Memory RAM 4 GB DDR3 28 
Key 14 
Waterproof cabinet 19 
Router Tp-Link MR3020 17 
Voltage regulator 
Subtotal 295 
Table 6

WiFi components

WiFiCost (€)
Antenna Ubiquiti NanoStation M5 111 
Antenna Ubiquiti Loco M5 70 
Outdoor cable UTP CatE S7 (15 meters used) 
Total WiFi alternative 186 
WiFiCost (€)
Antenna Ubiquiti NanoStation M5 111 
Antenna Ubiquiti Loco M5 70 
Outdoor cable UTP CatE S7 (15 meters used) 
Total WiFi alternative 186 
Table 7

Mobile components

3G CommunicationsCost (€)
Modem release 3G Huawei 13 
Annual Mobile provider service 168 
Timer 12 
USB cable (5 m) 
12 V Battery 23 
Total 3G Alternative 221 
3G CommunicationsCost (€)
Modem release 3G Huawei 13 
Annual Mobile provider service 168 
Timer 12 
USB cable (5 m) 
12 V Battery 23 
Total 3G Alternative 221 

In summary, in round figures, the alternatives successfully tested in the current configuration correspond to an initial investment that could add, per station, up to €480 for the WiFi alternative, or up to €516 for the 3G option. In the latter case, the annual cost of the cellular telephone service provider was included. These figures should be compared with the annual expenditure of €13,000 for having the Orbcomm system in operation, a system that fails, on average, 20% of the time.

The redundant communication system could be located in four or five key stations to have a reliable backup system whenever necessary.

Maintenance of the redundant system

The test period of the three stations together does not span more than three months. It is a very short period to obtain conclusions or reliable data on inherent system failures that would require the replacement of some or all of its components. However, based on previous and ongoing work carried out by the research group, which was the basis for the software development later transferred to the FEWS of the Salado River, it was possible to extract the following failure frequency of low-cost devices used in outdoor environments:

  1. Ten months of data collection in the agro-technical school of Santo Domingo (Figure 2(a)), operating phreatic level, soil moisture and temperature sensors (https://www.specmeters.com, www.genica.com.ar/);

  2. Seventeen months of observation with heat, water vapor, and carbon-dioxide flux sensors (Campbell eddy covariance (www.campbellsci.com));

  3. Three years of water level collection (acoustic sensor device (www.maxbotix.com/)),

  4. Five years of observation of hydro-meteorological data with a Pegasus station (www.tecmes.com/wpcontent/uploads/2014/12/Folleto-PEGASUS-2010-VIGENTE.pdf; http://fich.unl.edu.ar/cim/).

Overall, the operation of the experiments detailed in the above list just served to provide a glimpse of the occasional failure of the low-cost components used in different outdoor settings, either by natural causes or by inherent faults (Table 8). The weighted average of the values shown in Table 8 yields a yearly maintenance cost for the low-cost system on the order of €104 (Table 9). The observed failures were always attributed to an electrical fault, which constitutes the Achilles' heel of low-cost systems.

Table 8

Observed failures during GUI-testing, sensors, and other alternatives

SensorReason of failureComponent lostCost (€)
1. Santo Domingo Power outage MiniPC 143 
2. Eddy covariance Lightning Antenna Ubiquiti 70 
3. Water level Power outage Voltage regulator 
4. Pegasus station Power outage MiniPC 143 
SensorReason of failureComponent lostCost (€)
1. Santo Domingo Power outage MiniPC 143 
2. Eddy covariance Lightning Antenna Ubiquiti 70 
3. Water level Power outage Voltage regulator 
4. Pegasus station Power outage MiniPC 143 
Table 9

Maintenance costs between the official and the alternative network, on a unit basis

ItemOfficial FEWSRedundant system
Communication €1,405 (Orbcomm) €168 (3G) 
Replace of components €712 €104 
Total annual cost €2,117 €272 
ItemOfficial FEWSRedundant system
Communication €1,405 (Orbcomm) €168 (3G) 
Replace of components €712 €104 
Total annual cost €2,117 €272 

Before applying the interface to the FEWS problem, all field experiments detailed in Table 8 served to test the development of the software with different devices and environments to ensure a portable and trouble-free product. In Supplementary material, Appendix A, the reader will find a block diagram explaining how the interface works, and a repository address with the Python scripts where all the examples are readily available.

With the weighted average cost to replace damaged components for the low-cost system, plus the cost of communication (Table 7), it is possible to set up the following comparison between both systems on an annual basis (Table 9).

These numbers should be taken with caution since there are always hidden costs, expenses not contemplated, or changes in technology that can push the figures 20–25% above or below the initial estimate. Nevertheless, the low-cost system is, on average, eight times cheaper to maintain than the equipment of the official network.

Finally, the backup system was transferred to the local authorities of the Province of Santa Fe at the end of 2015. A technical talk was given to the technicians and the authorities in charge of the alternative network (https://www.santafe.gov.ar/noticias/noticia/220436/). The system was easy to operate since, among other things, it relied on a dynamic website to visualize the data downloaded and transmitted through the redundant system. Unfortunately, immediately after transferring the product, there was election time in the Province, and new authorities took over the State, freezing the collaborative effort for a while. Nowadays, there is a renewed interest by the state authorities after the devaluation of the Argentinian currency, given the high cost to replace damaged components and the obsolescence of the official network.

CONCLUSIONS

The Flood Early Warning System (FEWS) of the lower-catchment of the Salado River, Argentina, was set after the catastrophic flood suffered by the Santa Fe City, in 2003. A quick flood frequency analysis estimated the return period of the flood as around 130 years. However, the frequent loss of information due to communication problems in the final repository site of the FEWS has affected the network operational vulnerability ever since.

This paper proposes a solution based on a developed interface to transmit the data in parallel, previously captured by the monitoring network, through a dual channel that uses an electronic bypass without interfering with the original satellite communication system employed by the FEWS.

Several laboratory-scale trials were performed first to test the feasibility of the interface to transmit the data stored by the proposed redundant communication system. Three field experiments later complemented these tests carried out at lab scale. During the testing phase, the official communication system exhibited an average failure rate of the order of 20% compared to the developed interface, which was less than 1%. In all cases, the results had shown not only the consistency of the information transmitted by satellite and the proposed alternative, when both were active, but also the achievement of the latter to fill in the information gaps when the official system experienced a ‘blackout’ for some reason.

The automatic manipulation of a GUI was a technical contribution that emerged due to the impossibility of accessing the manufacturer's application of each data unit of the network, with an end product that sends the data with incredible fidelity. Moreover, the testing of the methodology with different commercial devices and environments ensures a trouble-free, portable product, making it attractive to any FEWS with similar characteristics. The software was designed to add support to other commercial devices. All software of the developed interface was uploaded to a public site, where the readers can study the source code, modify it, and use it the way they want.

The interface relies on low-cost, single open source board computers and routers that eventually reduce the maintenance cost of the satellite-based FEWS system significantly. This aspect of the proposed solution, in turn, can increase the reliability of any FEWS with similar characteristics.

ACKNOWLEDGEMENTS

Support from the National Council for Scientific and Technical Research (CONICET), research grant no. 112-201100100384, and from the Universidad Nacional del Litoral, research grant CAID 279/013-I + D 1-11, are greatly acknowledged. Thanks are also given to Senior Eng. Ricardo Giacosa and other authorities of the Ministry of Public Works of the Province of Santa Fe for their financial assistance and encouragement during the execution of this project. The authors also thank three anonymous reviewers for their useful criticisms and comments that helped to improve the first version of the manuscript.

SUPPLEMENTARY MATERIAL

The Supplementary Material for this paper is available online at https://dx.doi.org/10.2166/hydro.2020.216.

REFERENCES

REFERENCES
Asante
K. O.
,
Macuacua
R. D.
,
Artan
G. A.
,
Lietzow
R. W.
&
Verdin
J. P.
2007
Developing a flood monitoring system from remotely sensed data for the Limpopo basin
.
IEEE Trans. Geosci. Remote Sens.
45
(
6
),
1709
1714
.
Balis
B.
,
Bartynski
T.
,
Bubak
M.
,
Dyk
G.
,
Gubala
T.
&
Kasztelnik
M.
2013
A Development and execution environment for early warning systems for natural disasters
. In:
2013 13th IEEE/ACM International Symposium on Cluster, Cloud, and Grid Computing
,
Delft
, pp.
575
582
.
Calvello
M.
,
d'Orsi
R. N.
,
Piciullo
L.
,
Paes
N.
,
Magalhaes
M.
&
Lacerda
W. A.
2015
The Río de Janeiro early warning system for rainfall-induced landslides: analysis of performance for the years 2010–2013
.
Int. J. Disaster Risk Reduct.
12
,
3
15
.
Chen
N.
,
Wang
K.
,
Xiao
C.
&
Gong
J.
2014
A heterogeneous sensor web node meta-model for the management of a flood monitoring system
.
Environ. Modell Software
54
,
222
237
.
Contini
G. F.
,
Carrillo
E. R. E.
,
Ferreira
G.
,
Macor
J. L.
,
Veizaga
E. A.
2014
Types of faults detected in a telemetric network. Case study: Salado River Basin, Province of Santa Fe, Argentina (in Spanish)
. In:
2nd Int. Congress on Plain Hydrology (E-Book)
(
Venturini
V.
,
Rodríguez
L.
&
Cello
P.
, eds).
UNL Press
,
Santa Fe
,
Argentina
.
Fakhruddin
S. H. M.
,
Kawasaki
A.
&
Babel
M. S.
2015
Community responses to flood early warning system: case study in Kaijuri Union, Bangladesh
.
Int. J. Disaster Risk Reduct.
14
(
4
),
323
331
.
Faranda
D.
,
Pons
F. M. E.
,
Giachino
E.
,
Vaienti
S.
&
Dubrulle
B.
2015
Early warnings indicators of financial crises via autoregressive moving average models
.
Commun. Nonlinear Sci. Numer. Simul.
29
(
1–3
),
233
239
.
Gregg
C. E.
,
Houghton
B.
&
John
W. E.
2015
Volcano warning systems
. In:
The Encyclopedia of Volcanoes
, 2nd edn,
chapter 67
(
Haraldur
S.
, ed.).
Academic Press
,
Amsterdam
, pp.
1173
1185
.
Guo
Z.
,
Chen
P.
,
Zhang
H.
,
Jiang
M.
&
Li
C.
2012
IMA: an integrated monitoring architecture with sensor networks
.
IEEE Trans. Instrum. Meas.
61
(
5
),
1287
1295
.
Henonin
J.
,
Russo
B.
,
Mark
O.
&
Gourbesville
P.
2013
Real-time urban flood forecasting and modelling – a state of the art
.
J. Hydroinf.
15
(
3
),
717
736
.
Holt
A.
&
Huang
C. Y.
2014
OpenWRT
. In:
Embedded Operating Systems: A Practical Approach
.
Springer
,
London
, pp.
161
181
. https://doi.org/10.1007/978-1-4471-6603-0_8
Kuantama
E.
,
Mardjoko
P.
&
Saraswati
M. A.
2013
Design and construction of early flood warning system through SMS based on SIM300C GSM modem
. In:
2013 3rd International Conference on Instrumentation, Communications, Information Technology and Biomedical Engineering (ICICI-BME)
,
Bandung
, pp.
115
119
.
López
E. P.
2012
Captura y transmisión automática de datos hidro-meteorológicos (Capture and Automatic Transmission of Hydro-Meteorological Data)
.
MSc Thesis
,
Universidad Nacional del Litoral
,
Santa Fe
,
Argentina
.
Macor
J. L.
,
Contini
G. F.
,
Veizaga
E. A.
,
Morresi
M. V.
,
Carrillo
E. R. E.
&
Ferreira
G.
2016
Asesoramiento a la Inspección de Obra de las Redes de Monitoreo de Cuenca del Río Salado en la Prov. de Santa Fe y su Ampliación a la Prov. de Sgo. del Estero, de los A Saladillo y Ludueña y en la Cuenca del Río Carcarañá (Advice to the Construction Inspection of the Monitoring Networks of the Salado River Basin in the Prov. of Santa Fe and its Extension to the Prov. of Sgo. del Estero, of the Saladillo and Ludueña Streams and in the Carcarañá River Basin)
.
Report for the Ministry of Public Works and Transportation
,
FICH-UNL
,
Province of Santa Fe Argentina
.
Merkuryeva
G.
,
Merkuryev
Y.
,
Sokolov
B. V.
,
Potryasaev
S.
,
Zelentsov
V. A.
&
Lektauers
A.
2015
Advanced river flood monitoring, modelling and forecasting
.
J. Comput. Sci.
10
,
77
85
.
Pappenberger
F.
,
Cloke
H. L.
,
Parker
D. J.
,
Wetterhall
F.
,
Richardson
D. S.
&
Thielen
J.
2015
The monetary benefit of early flood warnings in Europe
.
Environ. Sci. Policy
51
,
278
291
.
Pumo
D.
,
Francipane
A.
,
Lo Conti
F.
,
Arnone
E.
,
Bitonto
P.
,
Viola
F.
,
La Loggia
G.
&
Noto
L. V.
2016
The SESAMO early warning system for rainfall-triggered landslides
.
J. Hydroinf.
18
(
2
),
256
276
.
Senay
G. B.
,
Velpuri
N. M.
,
Bohms
S.
,
Budde
M.
,
Young
C.
,
Rowland
J.
,
Verdin
J. P.
2015
Drought monitoring and assessment: Remote sensing and modeling approaches for the famine early warning systems network
. In:
Hydro-Meteorological Hazards, Risks and Disasters
(
Shroder
J. F.
,
Giuliano
P. P.
&
Di Baldassarre
G.
, eds).
Elsevier
,
Boston
, pp.
233
262
.
Tecmes
S. R. L.
&
Evarsa
S. A.
2006
Joint Venture to Operate the Flood Early Warning System in the Lower-Catchment of the Salado River, SFe Prov, Arg
.
Available from: www.tecmes.com/empresa-4 (accessed 25 May 2020)
.
Velázquez
J. A.
,
Petit
T.
,
Lavoie
A. R.
,
Boucher
M.-A.
,
Turcotte
R.
,
Fortin
V.
&
Anctil
F.
2009
An evaluation of the Canadian global meteorological ensemble prediction system for short-term hydrological forecasting
.
Hydrol. Earth Syst. Sci. Discuss.
13
,
2221
2231
.
doi: 10.5194/hess-13-2221-2009
.
Vionnet
C. A.
,
Tassi
P. A.
,
Rodriguez
L. B.
&
Ferreira
C. G.
2006
Numerical modelling of the catastrophic flooding of Santa Fe City, Argentina
.
Int. J. River Basin Manage.
4
(
4
),
301
314
.
Zhou
B. B.
,
Brent
R. P.
&
Tridgell
A.
1994
Efficient implementation of sorting algorithms on asynchronous distributed-memory machines
. In:
Proceedings of 1994 International Conference on Parallel and Distributed Systems
,
Hsinchu, Taiwan
, pp.
102
106
.

Supplementary data