dataesr/scientific-paragraphs-categorization huggingface dataset:
Satellite based monitoring techniques are nowadays an emerging tool for structural health monitoring. In this work, we are interested in the study of the deformations of a cable-stayed bridge using both PsInSAR and GNSS techniques. The content of this paper is mainly dedicated to the development and optimization of GNSS and PsInSAR equipments installed on the bridge. We also present the data processing tools with the aim of providing accurate and reliable measurements that will be used to understand the structure behaviour in medium and long terms. We are dealing also with the uncertainty of PsInSAR measurements points localisation to determine accurately where structural motions occur. Results from GNSS show that the bridge undergoes reversible daily and seasonal displacements in the order of few centimetres.
Low-cost monitoring system The use of GNSS for displacement monitoring of such large structures can enhance the knowledge and understanding of the real behaviour of the bridge, both in terms of 3D time series and in terms of frequency responses. Such measurements can also aid the early detection of faults in bridge structures. This technique allows a 3D monitoring of bridges dynamic and static behaviour with high temporal frequency and millimetre accuracy of a limited, but accurately defined, number of points. This technique is used to survey the static behaviour of the bridge components for long-term period. For this purpose, a GNSS monitoring system (Figure  2 ) has been developed based on low-cost single-frequency GNSS receivers and antennas for data acquisition and the open source RTKLIB software for data processing  (Takasu et al.
To minimise these effects, which are common in such environment  (Moschas, Stiros, 2014) , the locations and the heights of the antennas (relative to the bridge deck) have been adapted depending the surrounding environment. A fully automated processing chain was developed to calculate the coordinates of the monitoring receivers using the RTKLIB software. It uses the classical fast static differential method, as for this structure, the maximum baseline length is of about 800 meters, short enough to minimise common errors affecting GNSS differential positioning such as troposphere, ionosphere and orbit errors. To reduce multipath and atmospheric refraction effects, a 10 degrees elevation cut-off angle is applied. Positioning time series are computed using a 30-minutes time step, allowing to cut off high frequency displacements due to traffic and wind loads, but not to omit bridge's displacement due to thermal expansion.
PsInSAR processing 20 CosmoSkyMed stripmap images in descending orbit are used for this study through a processing chain based on SNAP as INSAR processor and StaMPS  (Hooper et al. , 2007)  for PsInSAR processing. The dataset covers a period of 11 months beginning from December 2018 to November 2019 with a mean temporal baseline of 17 days. The maximum perpendicular baseline is about 1154m in the dataset (Figure  6 ). to their amplitude dispersion. Then phase analysis is applied to select only PS with stable phase. During this step, the phases are assumed spatially correlated only on a small range of the bridge width. Consequently, we reduced sampling grid and filter window sizes to include only pixels with the same deformation pattern during the phase stability estimation. DEM error threshold is increased to avoid dropping PS located on the bridge where this parameter is expected to be higher due to the used DEM low resolution and uncertainties.
, 2019). However, in absence of such data, we exploited residual DEM errors from PsInSAR processing to update PS geocoding  (Crosetto et al. , 2010). This is achieved by estimating vertical and horizontal PS shifts associated to DEM errors and by updating PS coordinates as mentioned above. As we used SRTM DEM with a resolution of 30m, the bridge heights were not included (Figure  7 ). Therefore, we implemented this approach as final step in StaMPS to update PS geocoding. Results are exported to GIS format allowing overlying PsInSAR deformation map on other data types (satellite and aerial optical imagery, bridge model, corner reflector locations…). The developed codes for the geocoding update and GIS export are in Matlab and will be available for public on GitHub. Figure  7. A subset of the used SRTM 1 DEM showing that bridge (in blue) heights are not included.
CONCLUSION This paper has highlighted the study of cable-stayed bridge deformations using PsInSAR and GNSS techniques. For that purpose, we have managed to develop a GNSS monitoring system providing accurate 3D displacements using ublox lowcost mono-frequency receivers and antennas. We have developed also a a homemade compact multi-pass corner reflector, designed to be easily manufactured and installed in the field, and to colocate a GNSS and PsInSAR measurements with minimal and fixed offsets. The developed instruments were installed on the bridge key points. Three monitoring corner reflectors and GNSS antennas are installed on the pylons and the mid-span and two reference points are chosen on the bridge abutment as a stable area. Data processing workflows were detailed beginning by GNSS data processing made in fast static differential mode each 30min for continuous monitoring and synchronised with PsInSAR measurement time for comparison.
For PsInSAR, 20 CosmoSkyMed stripmap images from descending orbit was processed with SNAP and StaMPS and automated by snap2stamps codes. Considerable progress is made in this work on PSs 3D location correction using DEM error residuals from StaMPS and data export to GIS. GNSS measurements for one year showed that the bridge undergoes daily and seasonal deformations related to thermal expansion. Horizontal displacements are in the order of 40mm and vertical displacements of about 60mm that can be detected and confirmed by PsInSAR measurements. CRs and bridge radar signal is obscured by surrounding scatterers and first PS processing steps confirmed that pixel on bridge footprint have a low amplitude dispersion, but their phase is dominated by noise. Hence, they are not selected as PS. Several explanations related to the bridge particular environment and the PS detection algorithm are made.
The OpenSky Network is a non-profit association that crowdsources the global collection of live air traffic control data broadcast by airplanes and makes it available to researchers. OpenSky's data has been used by over a hundred academic groups in the past five years, with popular research applications ranging from improved weather forecasting to climate analysis. With the COVID-19 outbreak, the demand for live and historic aircraft flight data has surged further. Researchers around the world use air traffic data to comprehend the spread of the pandemic and analyze the effects of the global containment measures on economies, climate and other systems. With this work, we present a comprehensive air traffic dataset, derived and enriched from the full OpenSky data and made publicly available for the first time (Olive et al.
a non-profit organisation, OpenSky then grants researchers from academic and other institutions direct access to this database on request  (Schäfer et al. (2014) ). Along with the global sensor coverage, the database has initially grown exponentially since its inception on 2014 (see Fig. 1 ) and currently comprises over 23 trillion messages, taking up around 2 Petabytes. In peak pre-pandemic times, almost 100,000 flights were tracked per day. The raw data available in the Impala database has been used in more than 100 academic publications as of July 2020. However, despite available application programming interfaces and third-party tools, the access to this data requires significant investment of time and resources to understand the availability and underlying structure of the database. With this data set and its accompanying descriptor we want to address this accessibility issue and make a relevant part of the OpenSky Network flight meta data accessible to all researchers.
Crowdsourced Collection The raw data used to generate the dataset was recorded more than 3000 crowdsourced sensors of the OpenSky Network. The  As the data comes from a crowdsourced system of receivers, it is dealing with numerous challenges and difficulties found in such an organically-grown, non-controlled set of receivers. However, it is the only feasible option for the large-scale collection of open research data as collecting data from a synchronized and controlled deployment would be less flexible and less widely applicable, in particular for a non-profit research endeavour. Conversely, due to the high sensor density and high level of redundancy in the OpenSky Network, many well-covered regions of this data achieve the quality of controlled deployments on a nation-wide level in many countries.
Derivation of Flights We define a flight for the purpose of this dataset as the time between the first received ADS-B contact of one specific aircraft and the last. A flight must be of at least 15 minutes. If a flight leaves OpenSky's coverage range for more than 10 minutes, it is principally considered finished at the point of last contact. To prevent counting flights multiple times if they return into the coverage range after more than 10 minutes (e. g. , for any flight over the Atlantic Ocean), we apply a simple check: if time, distance and reported velocity match, they will be considered segments of the same flight. If not, it is assumed that the aircraft has landed at some point. The destination airport candidates are received from these identified flight trajectories as follows. If the last position seen is above 2500 meters, no candidate is defined and the value is set to 'NULL'.
Data Cleaning To make the data accessible and meet the requirements, complex pre-processing is needed to abstract from most system aspects, reduce the data volume, and to eliminate the need to understand all system aspects in order to use the data. Moreover, the information quality needs to be assessed and indicated, allowing researchers to choose subsets that match their own require-ments. Therefore, we performed the following processing steps to prepare the unstructured OpenSky Network data and create a well-defined dataset for scientific analysis.
Quality Assurance Crowdsourcing creates potential issues regarding the quality and integrity of location and timing information of certain aircraft and sensors. Such issues can range from faults in the transmission chain (i. e. , aircraft transponder, ground station) to malicious injection of falsified aircraft data. To allow researchers to ignore these effects while still preserving them as a potential subject of research, OpenSky offers integrity checks to verify and judge the data correctness (see  Schäfer et al. (2018) ). We also note that the abstracted nature of this dataset makes it more robust to any issues in the first place as low-quality data will be averaged out over time by the many involved receivers.
Data Enrichment We use the OpenSky aircraft database to add aircraft types to our flight data, and access publicly available open application programming interfaces (API) to match the commercial flight identifier, where available. Ireland and Switzerland, which is downloaded and incorporated daily. Besides these, it relies on enthusiast knowledge based on live observations and third-party sources. These are integrated opportunistically; the database is editable by any registered user of the OpenSky Network. A static snapshot of the database from June 2020 is provided with this record, regular updates are made available at https://opensky-network. org/datasets/metadata/.
Data Records Overall, the archive includes 41,900,660 flights, from 160,737 aircraft, which were seen to frequent 13,934 airports in 127 countries. One file per month is provided in the comma-separated values (CSV) format. Table  1  provides a breakdown of the included CSV files and their contents, broken down into size, number of flights, number of unique aircraft, unique origins and destinations. Note the significant reduction in size and flights since the beginning of pandemic measures in March 2020. We describe the columns of the dataset in the following: 1. callsign: The identifier of the flight used for display on the radar screens of air traffic controllers or communication over voice. For commercial flights, the first three letters are typically reserved for an airline, e. g. AFR for Air France, DLH for Lufthansa.
firstseen: The UTC timestamp of the first message received by the OpenSky Network. 8. lastseen: The UTC timestamp of the last message received by the OpenSky Network. 9. day: The UTC day of the last message received by the OpenSky Network. In the following, we provide some statistics showing that our flights dataset reflects the air traffic reality as different time series showing the effect of the COVID-19 pandemic at different airports and for different airlines. January to 30 April 2020. The impact of the pandemic (or rather the measures to contain it) can be seen clearly in all four. For example, the data shows: a slow decrease from February in several East-Asian airports (even earlier in Hong Kong); -European airports decreasing sharply from early March onward; In a similar fashion, Figure  5  shows COVID-19's normalized impact on different airlines across the globe.
The integration of aircraft types enables additional analysis such as gauging the popularity of different types and manufacturers across time, regions and use cases. Aircraft type designators follow the International Civil Aviation Organisation's (ICAO) convention (International Civil Aviation Union (2020)). The OpenSky aircraft database was created in 2017 as an additional crowdsourcing project. It joins different data sources, official and unofficial ones. The official sources include the registration information from the flight authorities in the US, UK,.
shows the distribution of the top 20 airports types in the flight dataset in January 2020 (based on recorded flight destinations). Reflecting both global air traffic realities and OpenSky's coverage focus, 13 of these airports are in the United States, including the 7 busiest with regards to landings. Several of the major hubs in Europe (Frankfurt, London Heathrow, Paris Charles de Gaulle) and Asia (Kuala Lumpur, Dubai and Delhi) make up the remaining six.
Conclusions Air traffic and flight data is needed for effective research in many areas of Earth Systems Science and related fields. We presented an openly accessible, specifically crafted dataset based on crowdsourced data obtained through the OpenSky Network and validated it successfully. From January 2019 to July 2020, the archive includes 41,900,660 flights, from 160,737 aircraft, which were seen to frequent 13,934 airports in 127 countries. As it is updated monthly, this dataset will be growing significantly and provide deeper insights into flight behaviour before, during, and after the COVID-19 pandemic.
Specifically, the proposed technique depends on the concept of abstract interpretation to analyze the hot loops at runtime. This process is done by firstly computing the abstract domain for each hot loop program points. Each abstract domain is incrementally computed, till a fixpoint is achieved for all program points, and correspondingly the analysis terminates in order to consecutively detect the existence of data dependence. Once the analysis result reports a parallelization possibility for the finished hot loop, the interpreter invokes the compiler to resume the execution in a parallel fashion as recommended by our proposed approach. The proposed technique is implemented on LLVM compiler, then used to test the dependence detection for a set of kernels on the Polybench framework, and the data dependence analysis required for each kernel is studied in terms of the computation overhead.
We propose to extract hot loops (HLs) in order to be analyzed at runtime, during interpretation. The HLs are represented by the most seen strongly-connected iterated basic blocks. The analysis is applied on the hot trace of HLs' program points. Our system mainly employs AI during execution to compute abstract states, abstract intervals, correctly. Therefore, the analysis will then use the computed abstract states to detect dependence correctly. Moreover, our dependence approach would recommend parallelizing/serializing the currently executed analyzed HL. The interpreted code would pause till invoking the compilation using JIT compiler to run the analyzed HL using SP exploiting the produced analysis during interpretation without requiring further compilation analysis pass, as in typical interpretation/compilation systems.
Our approach is fully automatic, so there is no need to stop the current run to insert any safeguards or directives manually. Therefore, the system could be used with SP without re-compilation or re-execution. This approach receives the source code to analyze, then SP system could proceed with parallelization within the same run  1. The AI dependence at runtime subsystem is implemented using the LLVM Compilation Framework. LLVM is able to support programs with lifelong analysis and transformation for arbitrary programs by supplying the compiler transformations with high-level information. This information could be provided at compile-time, link-time, runtime, or at idle time. The main privileges of using this compiler are its open-source property and platform independence. Therefore, it could be run by different front-end, high-level programming languages and it is used with a wide range of hardware architectures.
Moreover, our technique is applied on LLVM Intermediate Representation (IR) which is a powerful code representation. The IR is human-readable, so it is able to supply the means to debug and display the performed transformations  [8]. The system could detect the loop-carried dependencies and intraiteration dependencies. The main contributions of our paper are as follows: • A dynamic dependence analysis method based on AI on interpreter and compilation styled system. • Implement the corresponding analyzer into the LLVM compilation framework (for the interpreter engine). • Conduct an initial study about the performance of the analyzer in terms of correctness and overhead. The paper also explains how our system would be exploited by the speculative parallelizer to execute the parallel loops. We propose to resume executing HLs using a speculative parallelizer JIT compiler.
This analysis is accurate for the current loop execution, but not necessarily for future loop executions. However, we could guarantee the correctness by inserting guards on the trace entry. These guards check whether the current input trace as well as the program state (or procedure input), etc, are changed or not. If there is a change, the analysis should be redone, taking into consideration both current and earlier collected abstract semantics. The remainder of the paper is organized as follows: Section II is for the work related to the dependence analysis at compile-time and runtime. Section III provides the required background of parallelization, AI, and LLVM. Section IV explains the core concept proposed by our approach of dynamic AI analysis. Section V explains the main proposed system design and the implementation details for our dependence detection technique.
The technique is implemented using the Program Analyzer Generator PAG  [19]  which includes set of codes to facilitate the application of the technique. Furthermore, Tzolovski et al. [20]  have initially studied some properties of abstracting dependence such as the iteration data dependence graphs and dependence distance. However, the practical implementation details are missed in this study. Unlike the previously mentioned works, our approach is both automatic and dynamic. Our system conducts AI analysis at runtime which in turn makes it able to provide accurate dependence detection. Moreover, our technique does not restrict the speculative system to re-compile or re-execute. Also, the framework is implemented using LLVM which can be used with various hardware architectures and front-end programming languages.
C. LLVM Compilation Framework LLVM is an open source compilation framework. LLVM includes high-quality components with interfaces to be appropriate the different purposes in wide range of architectures. LLVM includes transformation passes which are exploited to be applied on Intermediate Representation, IR, in different levels, for example Modules, Functions, BasicBlocks, etc, to perform some computations and tasks  [27]. The IR is a well-defined representation for programs which is language independent, architecture independent, humanreadable and easy to use. IR is used for analysis and optimization. Furthermore, this representation provides Static Single Assignment (SSA) which guarantees that each variable is assigned once. In LLVM, each variable is assigned to a typed register. The main benefit of SSA is the simplification of variables properties in different compiler optimization levels  [28].
LLVM Transformation Pass is an important part of LLVM. It provides the compiler with different optimizations and transformations applied on code which enables the compiler to compute instrumentation results. Clearly, a transformation pass can mutate and modify IR code according to the pass functionality. Furthermore, the pass can extract information from IR to compute some specific details. Every transformation pass is implemented by overriding some methods included in LLVM. These methods are determined and implemented depending on the corresponding pass operation and the required changes  [29].
The intervals for a_ai6=[A+1,A+199] and a_aj6=[A+201,A+499] are showing that there is no intersection and therefore no loop carried dependence. In Section V, we explain the main points of our proposed system. Therefore, we need to clarify the main targeted code part in our method, the hot loop. Hot Loops (HLs) are the loops which contain strongly connected basic blocks. These blocks are repeatedly executed during runtime in the visited trace. We target the visited program points during the execution. We use a transformation pass to instrument the loop during early execution. Therefore, HLs are extracted as a preparatory step before the execution. After execution, every HL basic blocks are provided with special titles/names that are identified by our modified LLVM interpreter. V. PROPOSED DYNAMIC AI SYSTEM Section IV has provided a conceptual view of our proposed method.
In this section, we illustrate our system design and implementation details. Briefly, we could explain the main steps as follows: 1) The input source code is compiled by LLVM compilation framework to generate the corresponding IR. 2) The generated IR is inserted to an LLVM transformation pass to extract the HLs according to the number of execution for each basic block in IR to generate a new annotated IR with HLs. 3) The annotated IR is executed by LLVM interpreter till reaching entry basic block for HL. 4) Our approach in LLVM modified interpreter is applied to the current HL at runtime to analyze the main trace for this HL and construct the AI equations at each program point to compute abstract intervals. 5) The fixpoint is checked on the produced intervals of all passed program points after each iteration.
The SP would resume execution of the rest of iterations of the current HL using JIT compiler. 9) Finally, the execution of the rest of code is resumed using LLVM interpreter till reaching a new HL. These steps can be decomposed into two main subsystems. The first subsystem is dynamic data dependence from step 1-7 which is implemented by modifying the interpreter of LLVM compilation framework. The main acquired information during runtime is the variables abstract intervals in the early iterations. After reaching the fixpoint, the dependence check is applied using the intersection. The second subsystem is SP, step 8-9, which is proposed to be implemented by mingling the LLVM interpreter and JIT compiler. Our framework is depicted in Figure  1. For clarification, we use the example explained in Section IV.