dataesr/scientific-paragraphs-categorization huggingface dataset:
Description The HEC-RAS software package is developed and maintained by the Hydrologic Engineering Center (HEC) of the US Army, and further support is provided by means of a documentation website [21] and a discussion forum (https://www. kleinschmidtgroup. com/the-ras-solution, accessed on 7 March 2021). An HEC-RAS Application Programming Interface (API) simplifies the one-dimensional (1D) water system project development task and has three classes: HEC-RAS geometry, HEC-RAS flow, and HEC-RAS controller. • HEC-RAS geometry allows creating models of hydrographical systems based on their geometrical features and other physical parameters, e. g. , roughness coefficient. • HEC-RAS flow aims at reproducing the dynamics of water systems in steady and unsteady flows using specific information, e.
g. , boundary and initial conditions and hydrographs. • HEC-RAS controller allows to automate tasks such as running projects, data retrieval, postprocessing output data, and, in a future release, computational tools such as Monte Carlo Simulations. However, there exists no official supporting documentation for the HEC-RAS controller, being  [22]  the most complete document regarding such class. The proposed procedure consists in coding the HEC-RAS controller using VBA (Visual Basic for Applications) and automating HEC-RAS using Excel. HEC-RAS provides objects, e. g, classes, functions, and methods, that can be used by many object-oriented programming languages, enabling their interfacing. This allows the developer to govern HEC-RAS from an external source, using the programming language of choice.
Although these functions work well and are reliable, the possibilities offered by this approach may be somewhat limited. For instance, there is no available method to edit boundary conditions directly from the code when this object is used in MATLAB. However, the structure of the HEC-RAS files allows to overcome this issue. Even though the HEC-RAS controller deals mainly with binary files, HEC-RAS projects can always be edited using plain text files. Indeed, text files are easier to manage and deal with than binary files. Moreover, the parameters that the user might be interested in modifying are usually stored in plain text files. Consequently, reading and editing HEC-RAS projects from MATLAB can be performed in a straightforward manner. Table  1  presents a list of important HEC-RAS files, where X can be any digit.
HEC-RAS API Stability The HEC-RAS controller, as part of the HEC-RAS API, is subject to changes with every release of a new HEC-RAS version. Moreover, new MATLAB releases come out periodically, a fact that causes some functions in  [22]  not to be available in certain MATLAB releases. This issue might lead to errors during the interfacing of HEC-RAS and MATLAB. If such an error arises, the MATLAB function methodsview yields a list of HEC-RAS controller methods supported by MATLAB, which can be used to check whether a certain MATLAB version is compatible with an HEC-RAS controller version. The same function displays information about variables that need to be adapted in MATLAB. As a side note, the code given in  [18]  to control HEC-RAS with MATLAB R2015b  [24]  has an upward compatibility with more recent MATLAB releases.
Interface Design The main goal of the proposed interface is to allow the performance of step-bystep simulations. Indeed, while HEC-RAS offers an accurate simulation of the dynamics of water systems, MATLAB enables implementing advanced control algorithms. Thus, the performance of closed-loop control algorithms can be tested on a simulator while considering the real dynamics. It is therefore necessary that HEC-RAS sends the values of certain variables, e. g. , water levels, at regular intervals to MATLAB. Then, based on this information, the control algorithm can determine the suitable actions to be applied next by the available hydraulic devices, e. g. , gates and pumps, in HEC-RAS, taking into account the control frequency. Both software tools must run in parallel, exchanging information at fixed time intervals.
Overall Functioning The MATLAB HEC-RAS interface performs a step-by-step simulation, dividing a long simulation into a set of smaller ones, which will be computed one at a time, one after the other. Figure  1  presents a simplified diagram of the interface operation. Note that a model of the water system is required by the HEC-RAS geometry and flow classes, which are encapsulated in the HEC-RAS process block. The directory tree of files that constitute the model is called the HEC-RAS project. The file settings. ini defines the HEC-RAS and MATLAB project path; the start and end time of the simulation; the points of interest in the water systems, e. g. , location of sensors and actuators; and the type of data which will be saved in the results array, e. g. , flow and level. When the interface is launched, the master function master.
m instantiates several variables. A part of this function, which is dedicated to the preparation of the first computation step in HEC-RAS, is presented in Listing 1. Note that the management policy for the rest of iterations is not included. The HEC-RAS controller manages the ON/OFF switch for the HEC-RAS process. Moreover, the latter requires information contained in the HEC-RAS text files. Text file functions in MATLAB are dedicated to edit and set HEC-RAS text files, guaranteeing the conditions for the first simulation step. After the initialization, the simulation starts with the first computation. The HEC-RAS controller informs the interface once the computation has been performed. The results can be requested from the HEC-RAS controller and exported into a MATLAB cell array. Prior to the execution of the second step, the interface edits the HEC-RAS text files to shift the simulation date forward in time, and eventually apply a control action, if required by the user custom code.
Consider again Figure  1 , which features two of the four scripts that can contain user custom code. The script input_before_step is called before each simulation step, and can be used to modify gate openings according to the water stage elevation (WSE) value provided by the script output_after_step (not included in Figure  1 ). Then, a change can be made to the current gate opening by editing the corresponding value in the HEC-RAS files, which will be taken into account at the next step. The simulation is resumed after the modifications have been completed. This iterative process continues until the end date specified by the user (in hours, minutes, and seconds) in settings. ini. Note that the sampling time is also selected by the user. Thus, each simulation step starts with the results of the previous step as the initial condition.
To illustrate this simulation process, an example is depicted in Figure  2 , where a master script is executed during the entire simulation. The HEC-RAS process is paused at the end of each step and restarted at the beginning of the next. The user custom scripts are called regularly, with the exception of input_init and output_after_all, which are called only once. More precisely, input_init is called after the first start of an HEC-RAS process and before any HEC-RAS computation. Its purpose is that of specifying the boundary and initial conditions, or to reset any hydrograph. On the other hand, output_after_all is called once the simulation has been completed, and is employed to analyze the simulation results. Furthermore, the files input_before_step and output_after_step are run throughout the simulation, between two consecutive simulation steps.
Some Specifications of the Proposed Approach The interface consists in several MATLAB functions that are sorted by type in a directory tree, presented in Figure  3. Relevant documentation is provided so that each function can be understood and called directly without using the master script. Moreover, Table  2  provides a short description of each important folder in the directory tree. Note that the MATLAB scripts in the parent folder have already been presented in the previous section, with the exception of installer. m in the installation folder. This script is designed to allow for the installation of multiple interface versions and verify that every required file is present.
Utility Low-level functions used to avoid code repetition for specific tasks However, to avoid further coding work from the user, the interface has been coded to be used directly. Indeed, it is only necessary to specify the HEC-RAS data that are required by the control algorithms, as well as the control setpoints that must be sent to the hydraulic devices in HEC-RAS. Therefore, it is recommended to use the master script as a pattern, to identify which functions must be called, and the execution order. The reader is referred to the interface documentation  [27]  for detailed information on possible workarounds using the interface. Moreover, further insight on how to edit the interface is also provided.
Case Study The MATLAB HEC-RAS interface is tested first on an academical example, a rectangular canal, and then on a model of Beaver Creek to set up a control rule in the spirit of the work in  [22]. The first goal is to show that the automated start and stop simulations performed thanks to the designed interface lead to the same results as a manual simulation without restart. The second objective is that of defining closed-loop control rules for gates using the automated start and stop simulation to validate the approach. Moreover, the onestep simulations are performed by assuming that all hydrographs and control operations of gates are known beforehand for the whole simulation. Furthermore, note that no sudden modification of the input/output flows occurs during the one-step simulations.
Nevertheless, the interface allows to consider the desired sampling time. Moreover, and while MATLAB scripts are executed every hour, the computation interval in HEC-RAS is equal to ten minutes. This means that the HEC-RAS process is executed six times per one MATLAB execution. The initial condition considered downstream, i. e. , XS 0, is given in Table  3  as a stage hydrograph. The simulated upstream hydrographs, i. e. , XS 1000, are defined according to two scenarios. The first one, labeled as scenario1, is defined based on the pattern given in Table  3. At the initial time, the upstream flow is equal to zero during ten minutes, then it is equal to 10 m 3 /s for the next ten minutes, and so on. The second scenario, labeled as scenario2, corresponds to a constant upstream inflow of 25 m 3 /s, which can only cause the water level to increase.
The HEC-RAS results with automated start and stop simulations are depicted in dashed red, while the results without restart correspond to the continuous blue line. Note that the results obtained are identical for both methods, confirming that the MATLAB HEC-RAS interface approach performs as desired. Regarding the second scenario, i. e. , scenario2, the gate control rule is implemented in input_before_step. m as shown in Listing 3. This script is executed every hour, in accordance with the defined sampling time. Note that the variable ws_elev is assigned the current WSE (read from HEC-RAS), and xs{3} corresponds to an offtake flow, which is applied at the next steps of HEC-RAS. On the other hand, Listing 4 shows how to access the WSE information from HEC-RAS using output_after_step. m. Figure  6a  depicts the level at XS 700 for scenario2, when the control rule is implemented.
This rule requires to withdraw water from the canal whenever the level exceeds a height of 9. 3 m. The lateral inflow hydrograph applied by the control rule to the offtake gate at XS 500 is presented in Figure  6b. Note again that both approaches yield the same results. Thus, scenario2 demonstrates the effectiveness of the control approach defined in MATLAB and its application in HEC-RAS thanks to the interface. The most interesting feature of the first case study is that it allows to demonstrate the coordination possibilities between MATLAB and HEC-RAS. Moreover, advanced control algorithms can be easily implemented instead of the simple control rules, which only requires replacing the latter with the algorithm of choice. Indeed, this first case study depicts the basic functioning of the interface.
Second Case Study: Beaver Creek The Beaver Creek case study was proposed in  [22]  (p. 116), and is based on the Bridge Hydraulics project, available for download on HEC-RAS website  [21]. Further information on how to set up and run this case study can be found on the MATLAB HEC-RAS interface documentation (  [27] , Tutorial 1: simple automation example), which provides a step-by-step explanation to build a simplified version of this project. Figure  7  presents the Beaver Creek HEC-RAS model with the cross sections and the locations of the measurement stations and the two gates, i. e. , XS 5. 61 and XS 5. 44. The offtake gate located at XS 5. 61 is used to withdraw water from the canal. Conversely, the inflow gate located at XS 5. 44 is used to supply the canal with water. The initial and boundary conditions are summarized in Table  4 , and consist of a constant stage downstream hydrograph at XS 5.
0 and a modification over time of the upstream flow at XS 5. 99. Initially, the upstream flow is equal to zero, then it increases to 50 m 3 /s for the next period, and so on. The sampling time for the HEC-RAS project and MATLAB are equal to twelve hours and one day, respectively. The user must define, in settings. ini, the control points XS1 and XS2 that correspond to the cross sections XS 5. 61 and XS 5. 44, respectively. This is shown in Listing 5. A new scenario is defined for the Beaver Creek case study, i. e. , scenario3, which modifies the upstream hydrograph and implements a control rule in MATLAB. The rule controls the two gates based on conditions on the WSE value at XS 5. 61. When this value exceeds a height of 65 m, the offtake gate located also at XS 5. 61 opens, withdrawing 100 m 3 /s.
As soon as the WSE is lower than 65 m, this gate is closed. On the other hand, when the WSE is lower than 64. 5 m, the inflow gate opens to supply the canal with 20 m 3 /s. These control rules are summarized in Algorithm 2. Moreover, the file input_before_step. m is used to implement Algorithm 2, as shown in Listing 6. Figure  8a  shows the automated start and stop results in dashed red, and the results without restart using a continuous blue line. Moreover, Figure  8b ,c depicts the lateral inflow hydrographs applied at XS 5. 61 (offtake gate) and XS 5. 44 (inflow gate), respectively. scenario3 shows that the upstream flow modification and control of the several gates based on one or several measurements of WSE are enabled by the MATLAB HEC-RAS interface. This approach can be easily extended to deal with advanced control algorithms for more complex systems, benefiting from the multiple functionalities offered by MATLAB and HEC-RAS.
Conclusions The work performed in this paper aims at contributing to the issue of providing an appropriate interface between HEC-RAS and MATLAB, bearing in mind the first steps carried out in  [18]. More precisely, a MATLAB HEC-RAS interface has been designed to allow for closed-loop simulations of hydraulic systems that make use of advanced control algorithms. The proposed solution is coded as a series of simple MATLAB scripts. The main objective is that researchers in the Automatic Control and Artificial Intelligence communities can focus on testing control approaches. At the same time, it also aims at providing hydraulic researchers and engineers with a tool to include MATLAB functionalities in their simulations. In particular, the proposed interface allows one to read and write HEC-RAS files, perform fully automated step-by-step simulations, extract and save HEC-RAS results using the HEC-RAS controller, and apply MATLAB code to hydrographs or hydraulic devices.
To illustrate the performance of the interface, two case studies and three scenarios have been considered. The comparison of the accuracy yielded by manual and automated simulation approaches allows to validate the design and performance of the interface. The considered examples are representative in that several different possibilities of the MATLAB HEC-RAS interface are tested. Moreover, the proposed scripts can be easily adapted to deal with any HEC-RAS project and MATLAB control algorithm. Furthermore, documentation, tutorials, and a website have been created and made accessible to all users. One of the most sensitive issues linked with environmental systems is that of parameter uncertainty. A typical example of this is the roughness coefficient of the river bed. Indeed, the exact value might be hard to define in certain scenarios, and tables of values are used instead, resulting in small, unavoidable errors.
Then, the trade-off between the level of modeling detail put in the, e. g. , bathymetry and terrain, and the required computational time needs to be considered. Short-term perspectives regard the implementation and testing of model predictive control (MPC) strategies such as those proposed in  [28, 29] , but using an accurate HEC-RAS model of a real canal in the north of France. Such models are based on precise geographic information systems (GIS), whose data are provided by the Institut Géographique National (IGN), a French organization that manages a highly accurate geographical database of the French territory. In doing so, it will be possible to assess the performance of the MPC with a more realistic model.
Furthermore, in consonance with article 10 of the Directive, MS must organize the use of the best available data and the sharing of information, necessary for maritime spatial plans. Data used may include environmental, social and economic data related to activities and uses, and marine physical data about marine waters. Moreover, MS shall make use of relevant instruments and tools, including those already available under the Integrated Maritime Policy, for example, EMODnet data portals  34  , and under other relevant EU policies, such as those mentioned in the Inspire Directive 2007/2/EC  35. In this respect, the European Commission through the Directorate-General for Maritime Affairs and Fisheries (DG MARE) co-funded the project "Supporting Implementation of Maritime Spatial Planning in the Northern European Atlantic region (SIMNORAT)" 7 aimed to support the implementation of the MSPD  3  establishing a framework for MSP in the European North-Atlantic waters, and to establish a concrete cross-border MSP cooperation between countries involved.
Data collection and information requirements for MSP Data use and sharing is required to implement the MSPD. In particular, to fulfil the requirement of coherence of MSP plans along sea basins, data and information sharing should be approached at transboundary level, to take into account issues of transnational nature. Data collection and information requirements for MSP have been another aspect of the MSP process studied on SIMNORAT project. The work has focused on a technical study aiming to support access to and use of maritime spatial data in France, Portugal and Spain at regional level and has been organized differently depending on the initial, middle or final state of the project, to address the requirements of each phase. In general, it has been focused on data exchanges aspects using a Maritime Spatial Data Infrastructure and INSPIRE protocols regarding interoperability of data, metadata, data portals and Web Services.
Initially, a review of the available public and institutional data portals with relevant information in the North Atlantic basin along the maritime territories of the three involved countries was undertaken. From the data collected, an inventory of the relevant available data for MSP in the North Atlantic basin was prepared, processed and stored in a data portal. The data themes selected were governance (limits of jurisdictional waters, regulations at international, national, regional and local levels, etc. ), environmental data (characterization and pressures, etc. ) and human activities (uses and activities, conflicts, pressures, etc. ). Finally, a pilot interoperable data portal was developed with all information and data compiled as web map services (WMS) to achieve the objective of facilitate interoperability of data.
The research work carried out in the project is a combination of bibliographic analysis and the capitalization of interviews carried out through the activity on stakeholder engagement of the project: Desk analysis was conducted for each of the eight sectors (Fisheries; Aquaculture and fish farming; Commercial transport and ports; Marine renewable energies; Aggregate extraction; Gas and oil; Yachting and recreational activities; Underwater cables) and at the level of the 3 member states, focused mainly on the expected evolution of each sector, the interaction among and between sectors and the environment and to characterize the expression of spatial needs by representatives of the sector. Regarding MPA polices, a review to describe the management processes was carried out, and an update of the North East Atlantic MPA database 37 , developed by a previous Interreg Project (MAIA Project -Marine protected areas in the Atlantic arc  38  , for the 350 MPAs of the SIMNORAT project area).
Before starting a massive data collection, it is important to have identified the most relevant data to address the MSP process to prioritize and manage efforts. In general terms, without going into details of each of the three countries, since it is not the objective of this study to explain this highly technical work, the main problems identified when compiling the existing spatial information from the different national and regional data portals or databases is the non-harmonization of information and the lack of interoperability. The information needs to be not only comparable but spatially continuous to be useful for analyses. It makes also the analysis of transboundary data very time consuming. Another challenge identified related to the access to certain sensitive information from some sectors, both at private and public environments.
This issue is particularly relevant in cross-border areas, where each country establishes its standards in those data sets outside the framework of INSPIRE. As a first step after compiling all the available information was to establish a data model and organize it in a common database classifying it according to the different thematic cartography related to MSP, and its associated metadata, implementing the INSPIRE guidelines to ensure interoperability between databases. In this way, the project has developed the SIMNORAT Data Portal 51 (SDP) to share and exchange spatial data for the project area, compiling a relevant spatial data for MSP from the three involved countries, targeting both, general stakeholders and policy-makers. The MSP Directive indicates the kind of data may be used for maritime spatial plans elaboration, but no established classification of data of reference exists.
Nevertheless, in 2016, a MSP data study 50 established a detailed categorization of MSP data related used by MS. Using this study as the basis, the initial inventory of gathered data was organized as: Administrative boundaries (terrestrial and maritime boundaries). Physical, chemical, biological information (physical characteristics, type of habitat, biological characteristics, pressures and impacts). Spatial policy (spatial policy, land use). Activities/uses (aquaculture, fishing, marine renewable energies, installations and infrastructures, maritime transport routes and traffic flows, ports, nature and species conservation and protected areas, military, raw material extraction, scientific research, submarine cable and pipeline). An important imbalance is evident between categories. The Human activities category gathers half of the selected datasets.