dataesr/scientific-paragraphs-categorization huggingface dataset:
A shorter compositing period is possible because a finer spatial resolution allows a better cloud decontamination. Regarding the finer frequency, it will allow, in a further evolution step, to discriminate the albedo from bare soil and from vegetation. Starting from a prototype delivered by Meteo-France, HYGEOS has developed the input and output modules able to ingest the PROBA-V Top-Of-Canopy daily synthesis and to create the albedo products according to the Global Land service specifications. It has been checked that the processing performances were compliant with the product timeliness. After verification of the output product consistency, the chain will be delivered to the Global Land service that should start the NRT production before the end of 2015.
Long-term evolution At longer term, the evolution of the Global Land Service will ensure a sustainable global monitoring of the continental ecosystems with the continuity of 1km and 333m biophysical products generated from PROBA-V and Sentinel-3. A further step towards a production at 100m could be envisaged if users expressed such requirements. In parallel, a "worldwide" monitoring of hot-spots, like the major protected areas, will be added in the service, providing biophysical products derived from Sentinel-2 data at resolution between 10m and 10m, depending of the needs. Further, the current biophysical products will benefit from the capabilities of the new sensors. For instance, a 1km resolution SWI product is in preparation, using jointly the Metop/ASCAT and Sentinel-1/SAR data. Finally, new variables will be included into the service portfolio, according to the users' requirements.
CONCLUSION The Copernicus Global Land service is operational providing sustainable NRT delivery of global products, associated with consistent historic time series. A continuous quality monitoring guaranties the product quality reached a level satisfying the users' requirements and keeps stable along time. The access to products is free and open through http://land. copernicus. eu/global/. Continuing the 1km products time series with the replacement of the SPOT/VEGETATION sensor by the PROBA-V sensor was challenging: some products are still in development. Full quality assessment of PROBA-V products is ongoing. The next major evolution of the Global Land service is the production of a number of biophysical variables at 333m resolution from the PROBA-V sensor data. This is a first step before using jointly the data of PROBA-V and Sentinel-3 that should be launch before end 2015.
With the recent advances in sensor hardware and software, architectures for virtualized Wireless Sensor Networks (vWSNs) are now emerging. Through node-and network-level virtualization, vWSNs can be offered as Infrastructure-as-a-Service (IaaS) which can aid in realizing the true potential of Internetof-Things (IoT). Cloud computing offers elastic provisioning of largescale infrastructures to multiple concurrent users where Platform-asa-Service (PaaS) interacts with IaaS in order to efficiently host and execute applications over these infrastructures. Amalgamating IoT with cloud computing potentially allows rapid application and service provisioning in an efficient, scalable and robust manner. However, interactions between vWSNs and PaaS are largely an unexplored area. Indeed, existing vWSN IaaS are not yet ready for PaaS.
The second difference is that multiple heterogeneous VMs (in terms of operating systems) can be simultaneously deployed on the same host. For instance, a host can support a Linux-based VM and/or a Windows-based VM at the same time. However, VSs are tightly coupled with their sensor OS/middleware. For example, a sensor cannot support Contikibased VS and TinyOS-based VS at the same time. The third difference is that multiple VMs can be deployed in an isolated manner. The creation, deployment, and migration of VMs does not affect the execution of existing VMs. On the other hand, the deployment of new VS may disturb the execution of existing VS(s). This is due to the limited resources and the tight coupling between the VS and the sensor OS/middleware. Similarly, migrating VS from one physical sensor to another is not a standard feature yet.
The VS Communicator supports platform-specific protocols to interact with different sensor platforms to promote platform heterogeneity. Examples of these protocols include IEEE 802. 15. 4, Bluetooth, Cellular, and RESTful. Next, we renamed the Virtual Sensor Access layer from our previous architecture to the Virtualized WSN Infrastructure Management layer to make it more appropriate for this work. It now contains several new entities in addition as well as SAs. SAs interact with the WSN PaaS components on behalf of the VS in order to provide platform independence. The additional entities are described as follows. Original vWSN Architecture The Sensor Description Repository contains all relevant information about the deployed sensors, including their type, properties (i. e. , protocol, data format, supported sampling intervals, physical location and supported units) and capabilities (i.
These tasks will be run by a given VS. VS Configurator uses platform-specific code templates that allow for configurable parameters. A code template is a skeleton code file that does nothing useful on its own but can read from a parameter list and run a desired task. An example is the skeleton code that reads a manifest file (i. e. , used in Java SunSpot platform) to initialize parameters such as sensor type, sampling interval, desired unit, and an end-point address to send data output. Creating these manifest files on the fly is programmatically simple and can be easily achieved. The VS Configurator should ideally be implemented in a modular fashion to allow for the possibility of adding future code templates when new types of sensors are deployed. Additionally, VS Configurator compiles and generates the final executable code (e.
B. Implementation Choices and Prototype Setup The WSN infrastructure consists of Java SunSpots, which have multiple on-board sensing capabilities. Unlike the earlier generation of sensor nodes, Java SunSpots are quite capable and are based on Java 2 Micro Edition (J2ME), which makes them easier to program. The Squawk VM supports multithreading, making them suitable for our work. We used two Java SunSpot kits: two base station nodes and four SunSpots with on-board sensors. The vWSN IaaS layers were implemented as a standalone application. We programmed a simple PaaS, as a standalone Java application. Eclipse IDE and JDK 1. 7 were used for the application development. The application code was annotated with a description of the VS services and was given to the developers beforehand. The smart home application was developed as a simple Java application.
C. Performance Metrics The performance of the prototype was assessed in terms of the following metrics: VS Creation Delay (VSCD) and VS Start Time (VSST). The time spent between the moment the developer sends the application code to the PaaS for deployment and the moment the PaaS sends the creation requests to the vWSN IaaS was found to be negligible. VSCD is the time spent between the moment the WSN infrastructure receives the VS creation request from the PaaS and the moment the VS is successfully created. Because it is required to create a shared base station instance to communicate with remote Java SunSpot OTA, we measured two types of VSCD. In the first type, the shared base station instance is created once and used repeatedly for VS creation, hence it only shows VS creation delay. In the second type, a shared base station is created every time a VS creation request is received from the PaaS, hence it shows VS creation delay plus the delay to create the shared base station instance.
Introduction In the last years we have seen how Concurrent Constraint Programming  [20, 21]  (ccp) has been extensively used to specify and program concurrent systems. The increasing interest in the community for this powerful model of concurrency is perhaps due to its simplicity and tight connection to logic: processes tell and ask information (formulas in logic) in a store of partial information; moreover, processes can be seen as both computing agents and as logic formulas. The use of ccp models has pervaded different areas in science (e. g. , biochemical systems), engineering (e. g. , security protocols, mobile and service oriented computing and social networks) and even the arts (e. g. , tools for multimedia interaction)-see a survey in  [17]. Nevertheless, in spite of the many semantic and logical frameworks designed to reason about ccp processes, the automatic verification of ccp programs has received little attention so far.
Process Syntax The ntcc calculus  [16]  extends ccp with time-units for the specification of reactive systems, i. e. , systems that continuously interact with the surrounding environment. In this language, time is conceptually divided into discrete intervals (or time-units). Intuitively, in a particular time interval, a process P receives a stimulus (i. e. , a constraint) from the environment, it executes with this stimulus as the initial store, and when it reaches its resting point, it responds to the environment with the resulting store. The resting point also determines a residual process Q, which is then executed in the next time interval. Untimed processes. The process tell(c) adds the constraint c to the current store, thus making c available to other processes in the current time interval.
The set of free variables in d (resp. P ) is denoted as fv (d) (resp. fv (P )). P is executed in the next time-unit only if the guard c cannot be entailed from the current store. This is known as a negative ask or the preemption of P. The process ! P represents unboundedly many copies of P but one per timeunit. This is, ! P can be seen as P next P next 2 P • • •. This construct is powerful enough to encode some forms of recursive definitions in ntcc as shown in  [16]. Finally, the process P represents an arbitrary long but finite delay for the activation of P. This process can be viewed as P + next P + next 2 P +.
Structural Operational Semantics (SOS) The SOS of ntcc consists of two kind of reductions: the internal transition (-→) representing the evolution of processes during a time-unit and the observable transition (=⇒) representing the evolution of processes between time-units. The internal transition relation γ -→ γ satisfies the rules in Figure  1. Here we follow the formulation in  [10]  where the local variables created by the program appear explicitly in the transition system and parallel composition of agents is identified as a multiset of agents. More precisely, a configuration γ is a triple of the form (X; Γ; c), where c is a constraint representing the store, Γ is a multiset of processes, and X is a set of hidden (local) variables of c and Γ. The multiset Γ = {P 1 , P 2 ,. , P n } represents the process P 1 P 2.
The Language of Properties Constraint Temporal Logic (CLTL). Since ntcc processes manipulate constraints, it is reasonable to think that system properties must be stated in a logic able to deal with constraints. Hence, we shall use CLTL  [16] , a Linear Time Temporal Logic  [14]  where atomic formulas are constraints. Formulas in propositional CLTL are built from the grammar below: F ::= • true | • false | c | F • ∧ F | F • ∨ F | • ¬F | • F | 3F | 2F where c is a constraint. • true, • false, • ∧, • ∨ and • ¬ represent the linear-temporal logic true, false, conjunction, disjunction and negation respectively. These symbols should not be confused with their counterpart in the constraint system (i. e. , true, false and ∧). Symbols •, 2 and 3 denote the LTL temporal operators next, always and eventually.
Concluding Remarks In this paper we introduced a symbolic model to capture the behavior of ntcc processes. We showed that the internal and the observable transition relations in ntcc can be neatly captured as temporal formulas. Such a compact representation was shown to be adequate to use standard techniques in model checking to automatically verify concurrent systems programmed in ntcc. We implemented a tool in Ocaml (http://ocaml. org) to execute our verification process automatically. The power of functional programming, the compilation process and the type system of Ocaml, made possible to quickly develop such prototype. Moreover, we provide to users a more friendly way for writing programs in ntcc by parsing their syntax with ocamllex and menhir. The tool receives as input the ntcc program and recursively computes its symbolic representation.
Automatic verification techniques for languages based on the ccp model have been also studied in  [1, 2, 12]. In those works, the target language is tccp  [8]. Unlike ntcc, tccp does not consider constructs for asynchronous behavior ( P in ntcc). Moreover, the notion of time is identified with the time needed to ask and tell information to the store and the information in the store is carried through the time-units. Note that in ntcc the output in a time-unit is not related to the output in the previous time-unit. For this reason, the SOS of ntcc requires both an internal and an observable transition relation and thus, the above techniques for tccp cannot be used for the verification of ntcc programs. Finally, we refer to the work in  [18]  where the authors use a symbolic representation based on LTL formulas to give meaning to temporal ccp processes.
In this paper we present and discuss the performance of the procedure for earthquake location and characterization implemented in the Italian Candidate Tsunami Service Provider at the Istituto Nazionale di Geofisica e Vulcanologia (INGV) in Rome. Following the ICG/NEAMTWS guidelines, the first tsunami warning messages are based only on seismic information, i. e. , epicenter location, hypocenter depth, and magnitude, which are automatically computed by the software Early-est. Early-est is a package for rapid location and seismic/tsunamigenic characterization of earthquakes. The Early-est software package operates using offline-event or continuous-real-time seismic waveform data to perform trace processing and picking, and, at a regular report interval, phase association, event detection, hypocenter location, and event characterization.
The Istituto Superiore per la Protezione e Ricerca Ambientale (ISPRA) maintains the national sea level network and provides real-time data to the INGV monitoring room. The implemented tsunami warning procedure uses the Earlyest software developed by  Lomax and Michelini (2009a , b, 2011 , 2012)  to rapidly detect, locate, and determine the magnitude for large to great regional and teleseismic earthquakes. The purpose of this paper is to analyze the performance of Early-est regarding past events, in order to evaluate its reliability for the near-real-time tsunami warnings disseminated by the INGV, and eventually tune the procedure as a whole. INGV CTSP follows the ICG/NEAMTWS guidelines. ICG/NEAMTWS rules establish that a CTSP must disseminate a tsunami message, with warning levels that depend on location, magnitude, and depth of the earthquake according to a decision matrix, for all earthquakes with magnitudes M ≥ 5.
Early-est algorithm description Early-est is a software package for rapid location and seismic/tsunamigenic characterization of earthquakes. The Early-est software package operates using offline-event or continuous-real-time seismic waveform data to perform trace processing and picking, and, at a regular report interval, phase association, event detection, hypocenter location, and event characterization. This characterization (Table  A1 ) includes mb and M wp magnitudes, the determination of apparent rupture duration, T 0 , large earthquake magnitude, M wpd , and the assessment of tsunamigenic potential using T d and T 50 Ex, as described in  Lomax and Michelini (2009a, b, 2011). The Early-est program reads Mini-SEED data packets from a file or a SeedLink server (http://ds. iris. edu/ds/nodes/dmc/services/seedlink, http://www.
seiscomp3. org/wiki, doc/applications/seedlink), and passes each packet to a trace-processing module. The program also runs an associate/locate-reporting module at regular reporting intervals (e. g. , after all data are read by Mini-SEED; every 1 min for SeedLink). The Early-est software maintains a persistent pick list for the current reporting window (e. g. , the last hour before real time) and an event list for a specified archive interval (e. g. , the last 10 days). The pick list is updated continuously as picking and trace processing are applied to new data packets. The event list is updated at each reporting interval as new event locations are found or previous locations are deleted. At each reporting interval, the associate/locate module processes the current pick list from scratch, without making use of previous associations or location information from the event list; this memory-less procedure simplifies the associate/locate module and makes it very robust with respect to changes in the pick list, but increases the computational load.
Trace-processing module The trace-processing module processes each new data packet passed by the Early-est program. This processing includes channel identification, quality control, filtering for picking, picking, and further filtering and pre-processing as required for seismic and tsunamigenic event characterization (Table  A1 ). Picking in Early-est is performed by FilterPicker  (Lomax and Michelini, 2012; Vassallo et al. , 2012) , a general purpose, broadband, phase detector and picker which is applicable to real-time seismic monitoring and earthquake early warning. FilterPicker uses an efficient algorithm which operates stably on continuous, real-time, broadband signals, avoids excessive picking during large events, and produces onset timing, realistic timing uncertainty, onset polarity, and amplitude information.
In practice, it operates on a predefined number of frequency bands by generating a set of bandpassed time series with different center frequencies. Characteristic functions are determined for each frequency band and a pick is declared if and when, within a window of predefined time width, the integral of the maximum of the characteristic functions exceeds a predefined threshold. After picking for each new data packet, for each pick in the pick list for the current packet channel, the trace-processing module applies various analyses on the channel data and updates values needed for event characterization. Recursive, time-domain algorithms are used for all filtering and other time-series processing.
Associate/locate-reporting module The Early-est associate/locate-reporting module runs an octree associate/locate module with the current pick list, and then the reporting module which determines event characterization results and generates graphical and alpha-numeric reporting output. The octree associate/locate module efficiently and robustly associates picks, and detects and locates seismic events over the whole Earth from 0 to 700 km depth using the efficient, nonlinearized, probabilistic and global, octree importance-sampling search  (Lomax et al. , 2001 (Lomax et al. , , 2009)). See Appendix A for more details. The Early-est reporting module processes the current pick list and event list to determine event characterization results (Table  A1 ) and generate graphical, alpha-numeric, XML, HTML, and other reporting output for events, picks, stations, etc.
Data set The Early-est catalog (EEc in this paper) includes fully automatic and unrevised location and magnitude estimations for 5449 events from around the globe recorded at regional and teleseismic distance with magnitude M 5. 0. The current major version release of Early-est has been running since the beginning of March 2012. Our analysis will use locations and magnitudes for events which occurred between the beginning of March 2012 and the end of December 2014. At the beginning of March 2012, Early-est was using about 300 seismic broadband stations. The number of stations has continuously been increasing, and at the end of September 2014 the Early-est software was using a virtual station network of 494 stations (Fig. 1 ). We use the following as reference catalogs: (i) the catalog provided by GEOFON project of the Deutches GeoForschungsZentrum (Gc in this paper, http://geofon.
Generally our analysis showed that earthquakes with M ≥ 5. 5 can be located by using seismic data from global networks, with an empirical uncertainty, defined as the mean location difference with respect to the reference catalogs, of about ν ≈ 20 ∓ 25 km. The locations provided by Early-est show differences to the locations from the reference catalogs, that are comparable to the location differences among the reference catalogs. A similar conclusion is valid for the mean Early-est focal depth difference for global M ≥ 5. 5 earthquakes, which is about ν ≈ 0 ∓ 25 km, which is also coherent with the focal depth differences between the reference catalogs. Early-est uses only a subset of all worldwide, public, realtime stations, and the fact that the available number of stations sometimes may be reduced because of latencies does not seem to affect the quality of the estimated epicenter coordinates and hypocenter depth.
Since the assignment rules for the best magnitude depend on the number of stations measuring reliable mb, M wp , and M wpd and the magnitude value for each one (Table  3 ), the assigned best magnitude may vary between mb, M wp , and M wpd at each run. This is particularly true within the first few minutes after the event origin time, when the number of available waveforms may still be small, and the magnitude values may not be stable yet (Fig. 10 ). The linear correction for mb and the distance-dependent correction for M wp will thus produce a stable and reliable best magnitude useful for seismologically based tsunami early warning procedures. The CAT-INGV provides seismologically based tsunami early warnings when earthquakes with magnitude M ≥ 5. 5 occur in the Mediterranean region. Such tsunami warning messages are based on the fully automatically location and magnitude estimations provided by the Early-est software.
F. Bernardi: Early-est performance Appendix A: Octree associate/locate module The octree associate/locate module (Fig. A2 ) efficiently and robustly associates picks, and detects and locates seismic events over the whole Earth from 0 to 700 km depth using the efficient, nonlinearized, probabilistic, and global octree importance-sampling search  (Lomax et al. , 2001 (Lomax et al. , , 2009)). The objective function for the octree search is a probability function, P (x), based on the stacking of implicit origin times for each pick for each potential source x test. Given a seismic wave velocity model (currently ak135  Kennett et al. , 1995) , a pick time t p at a seismic station, and assuming a seismic phase type that may have produced the pick, the phase traveltime from the source x test to the station T x can be calculated and thus the implicit origin time T 0 for the source and phase can be determined by back projection (e.
The precise octree results provide uncertainty measures (e. g. , PDF scatter samples, uncertainty ellipsoid) for the location. When the octree associate/locate module returns an event, the associated picks for this event are masked in the pick list and the octree associate/locate module is run again using the remaining, non-associated picks, until no further events are returned. Thus multiple events can be associated and located within a report interval, and, in general, the events are identified in order of the number of associated picks and better location constraint. Early-est runs the octree associate/locate module every 1 min using all picks from the past hour, without knowledge of or preserving information from previously associations and event locations. This procedure makes Early-est relatively simple algorithmically, and robust with regards to changes in the set of available picks and the number of associated picks defining locations.