dataesr/scientific-paragraphs-categorization huggingface dataset:
The MIROVA archive now embeds 65 of 72 volcanoes that after 2002 produced at least one VEI 3 eruption  (Global Volcanism Program database, accessed on 26 June 2019). A preliminary analysis suggests that only 4 to 5 volcanoes of these 65 MIROVA targets, displays anomalies that can be considered as a thermal precursor of the upcoming VEI 3 eruption (Figure  7 ). This number possibly increases if we consider less explosive eruptions and changes from background activity at persistently active volcanoes. However, from our analysis, only 6-8% of the volcanoes seem to develop thermal unrest before a VEI 3 eruption detectable by MIROVA. It is interesting to note that the thermal unrest observed at these volcanoes shows unique behavior in terms of duration, pre-and post-eruption trends, as described below (Figures  7a-e ): Sabancaya, Perú (Development of Fumarole Fields -Figure  7a ) This is the archetype of thermal unrest consisting of the gradual appearance of very low-level thermal anomalies (< 1MW) localized at the bottom of a summit crater.
This small thermal precursor was the unique sign of renewed eruptive activity at this remote volcano and preceded by only 2 days the large VEI 3 explosion which occurred on 21 October  (Global Volcanism Program, 2018; Laiolo et al. , 2018). This short unrest is probably a limit case for MIROVAtype systems (i. e. , based on Moderate Resolution data) and suggests that the first thermal anomaly, detected after a several year-long period of quiescence, must be seriously evaluated and can represent a solitary short-term precursor of an incoming major eruption. On the other hand, it also outlines the need to have thermal satellite data with a high temporal resolution by keeping a high efficiency and a very limited number of false alerts. In the specific case of Tinakula it was necessary the post-event supervision (e.
With the exception of these five cases, our data suggest that most of VEI 3 eruptions are not preceded by thermal anomalies detectable by monitoring systems such as MIROVA. This is possibly due to the sensitivity of this type of systems that fail to detect small, low-intensity thermal anomalies. Indeed, the percentage of thermal unrest rises considerably if thermal data with higher spatial resolution are used as suggested by  Furtney et al. (2018)  and  Reath et al. (2019a). On the other hand, it cannot be excluded that the appearance of thermal precursors and the explosivity index of the subsequent eruption are somehow related to the degree of openness of the shallow magmatic system. A more detailed analysis, which also considers the possible appearance/variation of thermal anomalies before the numerous VEI 1-2 eruptions that have occurred in the MODIS era, will surely help to clarify whether there is a correlation between the timing and intensity of thermal unrest and the magnitude of the explosive eruption.
, 2019) , and currently no operative system exists that systematically provide this integrated information on the web (Supplementary Table  S2 ). Moreover, given the variability of wavelengths at which these sensors operate (from SWIR to MIR and TIR), the thermal information retrieved display different sensitivities to the wide range of temperatures of volcanological interest (i. e. , from 50 to 1200 • C) and is often inhomogeneous between the different datasets (for example, spectral radiance, hotspot area, temperature, radiative power). A preliminary comparative study between MODIS-MIROVA and SENTINEL2  (Massimetti et al. , 2018; Valade et al. , 2019)  showed that the two systems provide extremely coherent and complementary information. The example of Figure  11  shows what could be an integrated output of these two datasets  (Massimetti et al.
, 2018)  for the case of Agung volcano. The frequent acquisition of SENTINEL2 images (every 5 days) allows the tracking of the evolution of the area of the thermal anomaly inside the Agung crater, with a discrete temporal detail (red circles in Figure  11 ). The latter is in excellent agreement with the thermal flux measured by the MODIS (blue stem in Figure  11 ) to which it adds a high spatial resolution (20 m in the NIR/SWIR) that allows the location and mapping of the thermal anomaly inside the crater with great detail. Small changes in the location, area and or temperature of the hot feature are thus easily tracked by SENTINEL 2 data, and are coherent with MIROVA dataset. An additional improvement can be obtained by integrating also the data provided by Landsat8-OLI sensor (30 m), considering the appropriate spectral bands in NIR/SWIR.
Improve Temporal Resolution of MIR Data The temporal resolution is also extremely important to promptly detect a thermal anomaly, as well as to follow the course of an eruptive crisis. Increasing the frequency of thermal observations can be achieved through two ways: (i) adding new coherent datasets, from other similar polar sensors, and (ii) processing geostationary data. The acquisition, processing and integration of thermal data from other sensors having MIR channels, such as the VIIRS or the SENTINEL 3, constitutes a relatively simple step to implement the VRP time series provided by MIROVA. In fact, these sensors have spatial and spectral characteristics very similar to MODIS  (Blackett, 2015)  that allow the direct application of the algorithms behind MIROVA on the new acquired data.
Their processing would therefore allow thermal anomalies to be detected more frequently and with a greater probability of acquisition in optimal conditions. The main obstacle for such implementation remains the quantity of data to be analyzed and the storage capacity of the local server. These problems require the development of a more complex infrastructure than the existing one or, alternatively, the use of cloud computing services such as those provided by Google Earth Engine 6  or Amazon Web Services 7. However, the products useful for the application of the MIROVA algorithm (geolocated, corrected spectral radiances) are not yet available on these platforms in near real time, making this option currently impossible. Given the low spatial resolution of geostationary platforms (Supplementary Table  S1 ), the hot spot detection systems based on these sensors are generally not able to detect low intensity thermal precursors.
However, once an eruption has begun, it is possible to follow the event with temporal resolutions up to 5-15 min which make them extremely useful during crisis management (i. e. ,  Ganci et al. , 2011; Schneider et al. , 2014; Gouhier et al. , 2016; Lombardo, 2016; Patrick et al. , 2016). The analysis of these data at high temporal frequency and their integration with systems based on polar satellites (such as MODIS) is not trivial and requires the processing of data in virtually streaming mode. The recent availability of geolocated and radiometrically pre-processed geostationary image data, provided by systems like EUMETVIEW 8  in near real time, is certainly a first fundamental step which needs further efforts and development to integrate these high-frequency datasets into an multiplatform satellite volcanic monitoring systems.
It is hoped that with the continuous technological development, future satellite missions will be specifically dedicated to volcanic monitoring, or at least will be characterized by sensors with appropriate features that would make a breakthrough in volcanic monitoring. In particular, it is absolutely necessary to maintain the continuity of observations in the MIR (such as MODIS and VIIRS), to continue the almost 20-years-long dataset, provided by MIROVA and MODVOLC, possibly improving both spatial and temporal resolution. The presence of SWIR and TIR data, co-registered with MIR and not saturated, would also be a significant improvement for future sensors that would permit the coverage, in a single system, of the wide range of temperature observed on volcanoes. This would allow a detailed characterization of thermal anomalies, potentially useful for real-time determination of the eruption style and composition of terrestrial lavas  (Wright et al.
Data/Image Availability, Archive and Sharing The availability of data and the possibility of them being searched, displayed and downloaded in real time is another important element to make a volcanic hot spot detection system fully operational. Currently, MIROVA does not allow this possibility, which is compensated by sharing data via email in the case of need. This step requires considerable and continuous efforts by the system developers, but allows the checking of the dataset for the presence of any false alerts, to remove other thermal emitters, such as fires, and to provide support for the interpretation of the data, which in some cases can be ambiguous for non-experts. It can therefore be considered a sort of quality control service of the data that reduces the uncertainty (including cleaning of data sets of unreliable or untrustworthy data points) and any indirect, incidental or consequential damages arising out of any use of, or inability to use, the data.
Nevertheless, the creation of a web-based database for the entire MIROVA archive (time series) remains a task for future development to ensure faster information flow. The development of the apps (for mobiles and desktop pc) is an additional data sharing method, which would allow each individual user to select only the volcanoes of interest observed by MIROVA. Updates could be available through real-time notifications. The system could be also improved by providing a simple display of daily, monthly and annual values (including cumulative curves) that could be easily accessed by volcano observatories for research/monitoring purposes. Although the time series plots of VRP and distance are very useful for ongoing situation information, visualization of the image is useful to get the full sense for the spatial pattern of the thermal anomaly, or to verify the presence of clouds or ash plumes above the volcano.
MIROVA offers the ability to check the latest 10 images on the web site, but is not possible to go back days, months, years and visualize the archived images, thermal alerts and hotspots. In addition to the time series, a data archive of thermal images, searchable and downloadable on line, is certainly a useful tool for the post-event analysis, but also for real-time assessments. Comparison of older data to the near-real time scenes allows for a quick reality check of the current situation to the last thermal events to see whether this is a repeat of normal behavior of whether this new thermal pattern is anomalous and atypical. The integration of the thermal dataset with the satellite image viewing capabilities offered by cloud platforms such as WorldView 9  could be a particularly interesting solution to greatly simplify the visualization of MODIS images by local systems (such as MIROVA), by maintaining the possibility of linking the VRP time series with an independent image browser.
This major limitation, essentially technological, could possibly be overcome by a hardware upgrade of the current system, allowing the inclusion of all the Holocene volcanoes (about 1500) currently present in the Global Volcanism Database. This option would limit the amount of data to be analyzed only to areas of volcanic interest (not to the whole Earth's surface as it is done for MODVOLC or for FIRMS), retaining the possibility to add, in few hours at most, new targets in areas not yet covered. Alternatively, the development of 5 or 6 local systems (MIROVA clones), hosted by respective volcanological observatories, and focused only on regions (e. g. , Asia, Africa, Europe, etc. ) or countries can be a technologically easier solution to implement (it simply requires settling MIROVA on different targets in each region), which however involves an adaptation of the system to the specific hardware and networking requirements of each observatory.
FUNDING This research has benefited from funding provided by the  Italian Presidenza del Consiglio dei Ministri, Dipartimento della Protezione Civile (DPC)  as part of the  DEVnet Program  (2014Program ( -2016) ) that includes a collaborative project between the  Earth Sciences departments of the University of Florence  and the  University of Turin. This research was partially supported by the  Italian Ministry for Universities and Research (MIUR).
A second scalability issue arises when LCDPs need to manipulate large instance models of data, e. g. , as it happens today in several (automotive, aeronautics, civil) engineering domains. In this paper we will consider a running case where a ( ctional) company in social networking provides a LCDP to its users. rough the LCDP, users will be able to write their own apps over a huge social graph  [15] , represented as a model. Because of the sheer size of the model, providing an e cient solution is necessary. e third reason for the need of e cient model-management in LCDPs is the number of concurrent operations on the platform. Due to the potential massive use of LCDPs, there is a need to run a big number of operations in parallel for many users. In the context of a PaaS, numerous customers may query models, thus servers or shared databases.
Hence, e cient concurrent execution of modelmanagement operations is necessary. To improve e ciency and scalability, recent research on modelmanagement studied parallel and concurrent programming as well as speci c execution models for model-management languages. ese techniques range from implementing speci c execution algorithms (e. g. , RETE) to compiling toward distributed programming models (e. g. , MapReduce). In this paper we use the term execution strategies and (or just strategy) as a general way to denote these techniques. ese techniques are sometimes quali ed as paradigms in the literature, but this term may lead to confusion with programming paradigms (functional, logic, etc. ). e diversity of strategies that have been employed poses several scienti c challenges. Most model-management languages implement a single execution strategy with speci c strengths and weaknesses depending on the use case.
In addition, the tracking system keeps information about already executed rules to avoid recomputation. Other engines, such as ETL (Epsilon Transformation Language), from the Epsilon framework, implements a similar approach. Besides model transformation, laziness is also used in model querying. In  [38] , Tisi et al. rede ne OCL features with laziness aspects. For instance, operations of the language are rede ned to be evaluated with a lazy strategy. Also, the work proposes lazy collections that respect the OCL speci cation. e la er is similar to the collections proposed by Willink in  [46]. e OCL collections are implemented as generic Java classes, with lazy operators. ese approaches aim at tackling OCL related e ciency issues. For example, because of the OCL collections are immutable, the successive add of elements in a collection would create intermediate data structures.
2. 1); task-parallelism (Section 3. 2. 2), both of them being synchronous strategies; and one example of asynchronous strategy (Section 3. 2. 3). 3. 2. 1 Data-Parallelism. In a data-parallel approach, data is split and distributed across several computation units. en, the same piece of program (from a single basic operation, to a complex function) is applied simultaneously on each part of data by each processing unit without synchronization. Furthermore, additional synchronizations and communications may be needed between processing units to correctly compute the overall result. For instance, data may need to be merged into a single result. is computation strategy is the one followed by the parallel algorithmic skeletons  [16]  on data structures  [19, 35]. MapReduce  [20]  is a an example of programming model, designed for parallelism, that takes advantage of this strategy.
However, MapReduce is mainly adapted and implemented for distributed arrays or lists, and the approach is not directly suitable for all types of data structures. For instance, Pregel  [31]  is a strategy that aims at easing parallel computations on graphs by using a vertex-centric approach. In Pregel, graphs are speci ed by their vertices, each of them embedding information on their incoming and outgoing edges. A Pregel program is iterative, and is decomposed in three main phases: a computation on top of a vertex value, a generation of messages, and the send of messages through the edges of the vertex. is process is simultaneously applied to each vertex of a graph (such as a map in MapReduce). Data-parallelism is adapted and adopted in case of large datasets. Indeed, to make pro table the parallel execution of a single computation on data, the data chunks must be large enough, otherwise an overhead has to be paid without much bene ts from the parallelization e ort  [2, 17].
Considering a model as a graph data-structure, the graph technologies can directly be applied to models. For instance, Imre et al. e ciently use a parallel graph transformation algorithm on real-world industrial-sized models for model transformation  [24]. In  [34] , Mezei et al. use graph rewriting operations based on task-parallelism to distribute matching operations in large models in their transformation tool Visual Modeling and Model Transformation (VMTS). e Henshin framework  [26]  proposes to extract the matching part of its transformation rules into vertex-centric code (i. e. , Pregel). Another possibility to use Pregel in model transformation is by using a DSL, such as  [42]  for graph transformation. e proposed compiler transform the code wri en with the DSL into an executable Pregel code.
e. , hardware). [43] proposes a formal description of parallelism opportunities in OCL. Two main kinds of operation are targeted: the binary operations that can have their operands evaluated simultaneously, and the iterative processes of independent treatments. In  [30] , Madani et al. use multi-threading for "select-based" operations in EOL, the OCL-like language of the Epsilon framework, for querying models. e extension of the language with parallel features for selective operations have shown a non-negligible speed-up (up to 6x with 16 cores) in their evaluations on a model conform to the Internet Movie Database (IMDb) metamodel 1. Next to query evaluation, 1 h p://www. imdb. com/interfaces multi-threading is also used for model transformation. In  [40] , Tisi et al. present a prototype of an automatic parallelization for the ATL transformation engine, based on task-parallelism.
Instead, it aims at illustrating the diversity of solutions, that each have its own advantages depending on the use cases. To do so, we implemented several solutions using di erent parallel strategies and compared them. Also, this section only illustrates the variability of single solution, and not their possible combination. Our prototype is built on top of Spark 2  , an engine designed for big data processing. In addition to parallel features of Spark on data structures, called Resilient Distributed Datasets (RDDs), the Scala implementation of Spark proposes several APIs including a MapReduce-style one, an API for manipulating graphs (GraphX  [22]  that embeds the possibility to de ne Pregel programs), and a SQL interface to query data-structures. Because the framework proposes di erent parallel execution strategies, we only focused on parallel approaches to illustrate the need of a multi-strategy approach.
Direct naive implementation e rst implementation, namely direct-naive, shown in Listing 3, directly follows the OCL helpers from Listing 1. e rst auxiliary function countLikes, corresponding to the homonym helper, sums the number of like relations for each comment of a given post (lines 17 to 21). e second auxiliary function score (lines 23 and 24) is also a direct Spark translation from the OCL query. It uses parallelism, coupled with the lazy evaluation provided by Spark. Indeed, the execution of operations on RDDs is not started until an action is triggered. In our example, collect and count are these actions. Finally, the allComments function is de ned recursively using GraphX features. e direct-naive implementation of score uses three functions that are inspired by functional languages: filter which removes all the elements of a list that do not respect a given predicate; map that applies a function to every element; and flatMap which is a composition of map and flatten.
With this value, messages are generated with sendMs and sent to vertices through edges for the next iteration. Because the stucture which stores the message must be iterable, all the messages must be of type Iterator. An empty message is then produced by Iterator. empty. e program stops when no message is produced for the next iteration. In our implementation, messages are tuples of two values. e rst one is an integer value for specifying which vertices should compute and send messages. Besides, if the integer is negative, then all the vertices should compute. e second one aims at precising what. flatMap(_. dstAttr compose getComments). collect) value must be incremented (either the number of comments (false), or likes (true)). e initial step of the execution questions the model to get the id of the vertex containing the Post we want to score (line 3 and 4).
For example, give the right level of parallelism by providing an approximation of the optimal number of mapper and reducer in a MapReduce job  6. More formal approaches can also be used to estimate the cost of parallel programs (e. g. , cost model for GraphX  [27] ), and compare the di erent solution using additional parameters such as hardware con guration (e. g. , the bridging Bulk Synchronous Parallel cost model  [44] ). Using formal approaches to estimate the cost of a parallel program such as BSP cost model  [44]  or Pregel cost estimation  [27]. Finally, as for the combinatorial problem of choosing the right strategy, machine learning techniques could be adopted  [32].
Thus, the A3F-CTD form of the loop 1 diverged little from the ancestral chemistry and possibly maintained the ancestral function, while the release in conservation pressure on A3D-CTD allowed the enzyme loop 1 to accumulate mutations and diverge from the ancestral state. In turn, A3C was rapidly engaged into a distinct evolutionary pathway, which is unique due to the highly divergent chemistry of loop 1 but also because A3C is the only A3Z2 monodomain enzyme of the A3 family. It must also be noted that among the descendants of the ancestral A3C in Catarrhines, only extant A3C forms a well-supported monophyletic clade (Suppl. Figs. S8  and S9 ). Instead, in several instances and for different species, sequences annotated in the databases as A3D-CTD clustered together with sequences annotated as A3F-CTD, and vice versa, and the same is true for the corresponding N-terminal domains (see tanglegram Suppl.
Fig. S8 ), overall resulting in a lack of support for common ancestry for the individual moieties of A3C and A3F, and preventing us from inferring the ancestral forms of the loop 1 in A3D-CTD and A3F-CTD. This lack of monophyly could simply reflect the lack of power of phylogenetic reconstruction or the potential for database misannotations when applied to genes undergoing complex evolution, including a full panel of duplications, deletions, adaptive radiation, differential selection among paralogs and Red Queen dynamics  [3, 6, 92, 94, 95]. In this respect, the field is wanting for a systematisation of protocols and procedures for identifying selection signatures in genes with complex evolutionary histories  [96]. This lack of resolution could also reflect a biological basis of read-through of unmatured mRNAs resulting in differentially edited or in naturally chimeric mRNAs  [9, 97, 98] , which can hamper phylogenetic inference.