dataesr/scientific-paragraphs-categorization huggingface dataset:
The snap2stamps scripts are available via the Zenodo repository  [10]. Latest versions of the scripts (not verified by the developing team) can also be found on the GitHub repository (https://github. com/mdelgadoblasco/ snap2stamps). The authors had released a first version of the snap2stamps package in July 2018, which automates the TOPSAR single master Differential InSAR (DInSAR) processing, fully compatible with StaMPS PSI  [9] , allowing the creation of stacks of single master interferograms in batch mode, just by defining some simple settings such as project folder, subswath to process and defining the bounding box coordinates of the area of interest. Additionally, for the removal of the Atmospheric Phase Screen (APS), we have employed the Toolbox for Reducing Atmospheric InSAR Noise (TRAIN)  [22]  and applied the linear approach (topography versus phase) integrated in the aforementioned open source package.
Copernicus Sentinel-1 Data We limited our analysis to Sentinel-1A data only (12-days repeat cycle) (Table  1 ), which is sufficient given the expected magnitude of ground displacements and the availability of a large number of acquisitions over the area of interest. Some details on the Sentinel-1 data employed for the processing are shown in Table  1. It should be noted that since Sentinel-1 products are not spatially synchronized, meaning that their starting and ending times may vary within each orbit, often more than one scene is required to fully cover our area of interest. This introduces additional storage and computational requirements, as consecutive scenes, for the same acquisition date, need to be downloaded and assembled into single products before proceeding with the interferometric processing.
Our area of interest (AOI) and the extent of Sentinel-1 ascending (A117) and descending (D022) orbits is illustrated in Figure  1. Among the different options, we have selected ascending and descending tracks, 117 and 022, respectively, for which the area of interest is mapped with comparable incidence angles. By ensuring combination of similar viewing geometry, i. e. , sensitivity to vertical motion, we facilitate a more robust extraction of the vertical motion component, of interest for our investigation. Remote Sens. 2018, 10, x FOR PEER REVIEW 4 of 18 number of acquisitions over the area of interest. Some details on the Sentinel-1 data employed for the processing are shown in Table  1. It should be noted that since Sentinel-1 products are not spatially synchronized, meaning that their starting and ending times may vary within each orbit, often more than one scene is required to fully cover our area of interest.
Firstly, the master scene is selected from the beginning of the data series, as Sentinel-1 has orbit control which guarantees any interferometric combination among the data. Additionally, as we want  The PSI processing is split into two independent workflows: (i) single master DInSAR processing using ESA SNAP; and (ii) the PSI processing using StaMPS. Firstly, the master scene is selected from the beginning of the data series, as Sentinel-1 has orbit control which guarantees any interferometric combination among the data. Additionally, as we want to obtain PS points over urban infrastructure, we expect that temporal baseline will not greatly affect the number of PS obtained. Master image splitting and update of orbit state vectors follow, also using the SNAP Graphical User Interface (GUI), to ensure proper selection of bursts covering our AOI.
dhald is the projection of horizontal displacement in descending azimuth look direction (ALD). θ is the incident angle. Δα is the satellite heading, difference between ascending and descending orbit. The combination of ascending and descending PS points was performed in the vector domain avoiding any rasterization option, as described in  [30]. The method combines PS targets based on their geographic proximity, while attributes transfer and decomposition of motion is done within the features geodatabases. This leads to a higher number of final PS points and reduction of error budget introduced by spatial interpolation and rasterization procedures. PS points of one geometry having no neighbouring targets by the opposite geometry, within a defined search radius, are being excluded. The selection of the maximum search radius for the combination, in our case 40 m, was based on the statistical analysis of the distances between PS targets from the independent LOS solutions.
e. buffer zones do not exceed the segments' start and end points. Since StaMPS does not update PS heights, inaccuracies in the geolocation of PS targets over urban environments, especially for high buildings, might occur. To compensate for the above mentioned issue, during the calculation of the deformation statistics for each vector element (road, buildings etc. ) a 20 m buffer was considered. The choice of the buffer distance was based on the visual interpretation of the results. The combination of ascending and descending PS points was performed in the vector domain avoiding any rasterization option, as described in  [30]. The method combines PS targets based on their geographic proximity, while attributes transfer and decomposition of motion is done within the features geodatabases. This leads to a higher number of final PS points and reduction of error budget introduced by spatial interpolation and rasterization procedures.
Results We have obtained the average PSI LOS deformation rates for both ascending and descending tracks (Figure  4 ). An indicator of the compatibility of solutions between acquisition geometries is the standard deviation of the mean LOS deformation velocities, which correspond to 1. 04 mm/yr and 1. 17 mm/yr for A117 and D022 tracks, respectively. Given the difference in area covered by each track, the relatively larger number of PS points in the descending solution could be explained (Table  3 ). Apart from the effect of area coverage, it seems that the overall numbers of PS points is comparable. We attribute this to the common observation period and incidence angles considered for both ascending and descending datasets. We have obtained the average PSI LOS deformation rates for both ascending and descending tracks (Figure  4 ).
An indicator of the compatibility of solutions between acquisition geometries is the standard deviation of the mean LOS deformation velocities, which correspond to 1. 04 mm/yr and 1. 17 mm/yr for A117 and D022 tracks, respectively. Given the difference in area covered by each track, the relatively larger number of PS points in the descending solution could be explained (Table  3 ). Apart from the effect of area coverage, it seems that the overall numbers of PS points is comparable. We attribute this to the common observation period and incidence angles considered for both ascending and descending datasets. After decomposing the ascending and descending LOS measurements, we obtained the vertical deformation rate map presented in Figure  5. It can be easily seen that various deformation patterns exist, attributed mainly to the different subsidence mechanisms acting in the metropolitan area of Rome.
There are several areas undergoing significant subsidence, such as i) FCO airport; ii) along the Tiber River; iii) the coastal zone of Ostia; iv) Ostiense quarter within Rome and; v) Tivoli area, while the rest of the region exhibits relatively low ground deformation rates. In the following sections we provide a more detailed analysis of the PSI results. As we ran StaMPS using different merging options, we obtained different numbers of PS points for each solution. In Table  3 , we summarize the total points obtained for each merging configuration and those remaining after the vertical decomposition. It should be noted that, for the decomposition, only the overlapping area between ascending and descending results is exploited. For the full resolution datasets, we obtained over 1 million point targets for both orbits (Table  3 ), a fact which poses some difficulties in handling the dataset for post analysis purposes.
In the following sections we provide a more detailed analysis of the PSI results. As we ran StaMPS using different merging options, we obtained different numbers of PS points for each solution. In Table  3 , we summarize the total points obtained for each merging configuration and those remaining after the vertical decomposition. It should be noted that, for the decomposition, only the overlapping area between ascending and descending results is exploited. For the full resolution datasets, we obtained over 1 million point targets for both orbits (Table  3 ), a fact which poses some difficulties in handling the dataset for post analysis purposes. The decision to reduce the initial number of PS points or not depends actually on the application at hand. For example, while working on infrastructure monitoring, it may be relevant to maintain full resolution results, as the number of points decreases rapidly after merging.
Similar patterns over these alluvial deposits are present in our results (Figure  8 ). It is difficult to compare the deformation velocities between the studies, due to the different datasets employed and periods analyzed. We measure strong subsidence in several areas such as Ostiense and Santa Victoria quarter, with maximum vertical deformation rate of -7. 2 mm/yr. Also remarkable is the subsidence along the Tiber River and its tributaries (with more than 52k PS points), with a maximum deformation rate of -8. 7 mm/yr and an average of -1. 4 mm/yr.
Similar patterns over these alluvial deposits are present in our results (Figure  8 ). It is difficult to compare the deformation velocities between the studies, due to the different datasets employed and periods analyzed. We measure strong subsidence in several areas such as Ostiense and Santa Victoria quarter, with maximum vertical deformation rate of -7. 2 mm/yr. Also remarkable is the subsidence along the Tiber River and its tributaries (with more than 52k PS points), with a maximum deformation rate of -8. 7 mm/yr and an average of -1. 4 mm/yr. Figure  8. Average vertical deformation rates along the Tiber River and its tributaries (left) and detailed views presenting the estimated maximum deformation rates per building block within the center of Rome (right). The selected reference point (M0SE00ITA EUREF station) is shown in the black square.
Discussion We present ground deformation in the Rome metropolitan area for the first time, using Copernicus Sentinel-1 mission data and open source toolboxes, paving the way for the broader utilization of the proposed chain by EO practitioners in geohazards applications. Despite the availability of additional satellite data, limiting the analysis to Sentinel-1A acquisitions (repeat of 12 days) was considered sufficient, given the relatively low deformation rates in the area and the expected linear behavior of motion in time. The area exhibits diverse deformation patterns, the spatial expression of which indirectly suggests, at least for some cases, the underlying deformation mechanism. The demonstrated quality of interferometric products obtained by Sentinel-1, both in terms of spatial density and uncertainties of displacement estimates is of key importance for the interpretation of motion and the phenomena involved.
Acknowledgments: The authors would like to acknowledge the  ESA Research and Service Support  for the provisioning of the employed computer resources with collocated Copernicus Sentinel-1 data. The suggestions and recommendations by anonymous reviewers that contributed to improving the manuscript are also acknowledged. ALOS World  3D DSM (AW3D30 ) was downloaded from The  Japan Aerospace Exploration Agency (JAXA)  and CartoSat-1 DSM was obtained from  ESA  through the  Category-1 research project  with  ID 42428. Extracted OpenStreetMap layers over Lazio region downloaded from [31].
Conclusions We have demonstrated the utilization of open and free data from the Copernicus Sentinel-1 mission using open source toolboxes for advanced interferometric processing. We provide details on a dedicated package for the automation of SNAP-StaMPS PSI processing, which we make available to EO practitioners in response to the growing need for EO-based solutions for monitoring geohazards. The integration of such a chain on a cloud processing environment will enable EO practitioners to respond to the ever-increasing volume of satellite data and high processing capacity requirements. We verified the results by inter-comparison with previously published studies. To facilitate openness, we have made the PSI measurements over Rome available online, encouraging further analysis and interpretation as well as promoting collaboration between research communities.
Examples include the many forms of encapsulation that have been studied under the topic of aliasing control and ownership types in object-oriented programming  [14]. By architectures with sharing, we understand architectures where components can take part in different ensembles, compositions or aggregations, possibly with different attendant properties, e. g. in terms of encapsulation, lifetime and existential dependencies  [2]. Examples include architectures featuring common services, such as databases or logs, that can be used by software components at different levels in a software structure, and architectures featuring shared resources such as virtual machines or operating system processes. An example can illustrate the questions we are concerned with. Consider the architecture depicted in Figure  1.
The Fractal component model  [8]  is one of the rare software component models that allows the description of component configurations with sharing, and that has been formally defined  [27]. The architecture in Figure  1  can readily be described in Fractal, with encapsulation scopes captured by Fractal composites. But we do not have a formal operational semantics for Fractal that would allow us to define the exact semantics of these scopes, nor do we have a proper behavioral theory for Fractal architectures. Interesting approaches to enforcing encapsulation policies are works that rely on dynamic access protection instead of aliasing control. These include notably the Siaam actor abstract machine  [15] , which relies on runtime checks to enforce actor encapsulation in a Java virtual machine, and access contracts  [39]  which provide dynamic access protection to Java objects that can support a wide range of encapsulation policies, including encapsulation policies with sharing as in the small architecture depicted in Figure  1.
Contributions. In this paper, we combine ideas from SHR systems  [19] , from location graphs  [36] , as well as Siaam  [15]  and access contracts  [39]  dynamic approaches to encasulation enforcement, to define a formal operational framework, called the Hypercell framework. This framework allows the definition of different software component models (hypercell models), that support the modelling of dynamic component ensembles (hypercells) with sharing and encapsulation. The Hypercell framework can be seen as a conservative extension and generalization of the BIP and Fractal components models  [6, 8]. A main contribution of the Hypercell framework is how it handles encapsulation policies: to allow for maximum flexibility, they are enforced by runtime checks (authorizations), that prevent transitions of component ensembles that would violate the chosen policies.
The DIRAC project is developing interware to build and operate distributed computing systems. It provides a development framework and a rich set of services for both Workload and Data Management tasks of large scientific communities. DIRAC is adopted by a growing number of collaborations, including LHCb, Belle2, CLIC, and CTA. The LHCb experiment will be upgraded during the second long LHC shutdown (2019)(2020). At restart of data taking in Run 3, the instantaneous luminosity will increase by a factor of five. The LHCb computing model also need be upgraded. Oversimplifying, this translates into the need for significantly more computing power and resources, and more storage with respect to what LHCb uses right now. The DIRAC interware will keep being the tool to handle all of LHCb distributed computing resources.
Within this contribution, we highlight the ongoing and planned efforts to ensure that DIRAC will be able to provide an optimal usage of its distributed computing resources. This contribution focuses on DIRAC plans for increasing the scalability of the overall system, taking in consideration that the main requirement is keeping a running system working. This requirement translates into the need of studies and developments within the current DIRAC architecture. We believe that scalability is about traffic growth, dataset growth, and maintainability: within this contribution we address all of them, showing the technical solutions we are adopting.
A yearly user workshop and weekly open developers meetings gather together users and experts. The project counts about five core programmers, and a dozen contributing developers. The DIRAC consortium has been established in 2014 as a representing body for the development and maintenance of the DIRAC software. The consortium counts a small set of active members, each of which elects a representative, while consortium members elect a Director, and a technical Director. Institutes that are part of the consortium engage in the maintenance and in the promotion of the DIRAC software.
The LHCb upgrade and DIRAC The LHCb Upgrade [2] will operate through LHC Runs 3 and 4. The instantaneous luminosity will increase by a factor of five, from 4 × 10 32 to 2 × 10 33 cm -2 s -1. The event selection and processing at the software level with this increase have a major impact on software and computing systems. LHCb has implemented an extension of DIRAC, called LHCbDIRAC  [3, 4]  and uses fully the functionalities that DIRAC provides. LHCb has customized some of the DIRAC systems, and created two new ones: the Bookkeeping [5] (a provenance and metadata catalog) and the Production Management  [6]  (a high-level system for managing all LHCb productions). They both provide Web User Interface (WUI) extensions within the LHCbWebAppDIRAC (the LHCb extension of WebAppDirac, which is the DIRAC portal, based on Tornado  [7] ).
The Pilot project is extended within the LHCbPilot project. The LHCb computing team wrote a computing TDR for the LHCb upgrade  [8]. In that document, we recognized the need for two complementary adaptation strategies: a revolution in some part of the LHCb software, and an evolution for other parts. DIRAC and LHCbDIRAC fall in the second category, and within this paper we will explain why. With DIRAC, LHCb operates a service, and it is mandatory for us to keep a running system working, with continuity. It will become clear, by reading further, that, while several changes will be needed to DIRAC and LHCbDIRAC, we don't see the need for a revolution, so the system will keep evolving gradually, in a backward compatible way.
Exploiting computing resources The Grid model was initially conceived as a "push" model, where jobs were submitted from a queue of jobs, managed by each and every experiment in an independent way through their WMS software. The "push" model proved to be inefficient and error prone. To face these issues DIRAC introduced, back in 2006, the so-called pilot jobs, which are not real payload jobs but rather the startup scripts which land at the worker node, perform sanity checks and then pull payload jobs from the central queue: this action is often called "matching" a job. A pilot job that fails prior to having matched a job causes no particular troubles. The advantages of the pilot job concept are now well established: pilots are not only increasing the aggregate users' job throughput efficiency, but also helping to manage the heterogeneous computing resources presenting them to the central services in a uniform coherent way.
Each community found ways to exploit non-reserved CPUs (or even GPUs), often not supported resources and computing elements. Such resources may be private to the experiment (e. g. the "online" computing farm -often simply called "High Level Trigger" farm) or public; resources may sometimes be donated free of charge, like in the case of volunteer computing, or not, like public commercial cloud providers. Integrating non-grid resources is an ongoing activity for all communities that have been using WLCG in the past, and still do. Communities that use DIRAC want to exploit all possible CPU or GPU cycles. Software like DIRAC aims to make this easy, and the DIRAC pilot is the federator of each and every computing resource. The DIRAC pilot has the following characteristics: • a DIRAC pilot is what creates the possibility to run jobs on a worker node; • it is a standalone python script, that can be easily extended by communities which want to provide their own commands; • it can be sent, as a "pilot job", to all types of GRID Computing Elements (CEs); • can be run as part of the contextualization of a Virtual Machine, or whatever machine; • can run on almost every computing resource, provided that: -Python 2.
Traffic growth The DIRAC architecture is a web service architecture. In this sense, approaching traffic growth means, mostly, making sure that messages can be treated by the system in a reasonable time, and that the system can react to a growing number of messages without being affected, performance-wise. Web services based software architectures have been an exhaustively discussed topic in the vast web community. Various architectures have been proposed and implemented within the HEP community, but mostly outside of it. The DIRAC architecture and framework have been designed and implemented more than ten years ago. So, first of all we asked ourselves whether the DIRAC architecture needed, or not, an upgrade.
DIRAC architecture analysis The basic DIRAC components are Services, Agents, and Executors. • Services are passive components listening to incoming client requests and reacting accordingly by serving requested information to or from the Database backend. Services themselves can be clients of other Services. DIRAC provides the end users and administrators with dozens of specialized services. • Agents are active components, similar to cron jobs, which execution is invoked periodically. Agents are animating the whole system by executing actions, sending requests to the DIRAC or third party services. DIRAC provides the end users and administrators with dozens of specialized agents. • Executors are also active components, similar to consumers of a message queue system, which execution is invoked at request.
Executors are used within the DIRAC Workload Management System (WMS). DIRAC components are combined together to form Systems. A DIRAC system is delivering a complex functionality to the rest of DIRAC, providing a solution for a given class of tasks. Examples of systems are the Workload Management System (WMS) or the Configuration System (CS) or the Data Management System (DMS). And then there are databases, which keep the persistent state of a System. They are accessed by Services, Agents and Executors as a kind of shared memory. A trendy approach for modern Service Oriented Architectures (SOA) is the so-called "microservices" based architecture. Within a microservices architecture services are small, self-contained, single-responsibility units that can be independently developed, tested, and deployed.