dataesr/scientific-paragraphs-categorization huggingface dataset:
The land cover maps were created based on the combined historical cropland and pasture distribution from SAGE  [1]  and the History Database the Global Environment (HYDE)  [3]  datasets (see Figure  1 ). SAGE has developed a "data fusion" technique to integrate remotely sensed data on the world's land cover with administrative-unit-level inventory data on land use (see  [1, 48, 49] ). The HYDE database was originally carried out for testing and validation of the IMAGE 2 model  [50]. The Land cover map for agricultural land is based on a combination of a georeference dataset and national land use statistic (please see  [3] ). Pre-industrial (PI) and present-day (PD) experiments are driven by prescribed data for the corresponding period. Inter-annual variability is solely prescribed in the SSTs and SIC forcing; the land use and greenhouse gases forcings are kept constant for a particular year (Table  2 ).
The PD V experiment was carried out using the present-day SST, SIC and [CO 2 ] (hereafter CO2SST) and pre-industrial vegetation conditions (set to 1870). The PI V experiment is forced by pre-industrial CO 2 and SST with the current vegetation conditions (1992). All simulations have been run in an ensemble mode (n = 5 ensembles per model, by perturbing the initial atmospheric conditions) to include more robustness in the results reported herein. a Each experiment includes five members of ensemble simulations. For further details about the prescribed forcing (land-cover data, sea-surface temperature/sea-ice concentrations data (SST/SIC) and atmospheric CO 2 concentrations) and the experiment setup and model descriptions, please see  [13].
Observation-Based Data Sets To evaluate the performance of the seven climate models used in LUCID simulation, several climate observation datasets were used. Rainfall and surface air temperature simulated by the LUCID climate models were compared to observational data from the Climatic Research Unit (CRU) which is available at spatial resolution of 0. 5 × 0. 5°from 1901 to 2016 (http://www. cru. uea. ac. uk,  [67] ). The Leaf Area Index (LAI) satellite derived dataset from the Geoland2 project (http://www. copernicus. eu/projects/ geoland2,  [68] ) is used to assess the reliability of LSMs to simulate realistic LAI. The LAI dataset is available at 0. 5 × 0. 5°spatial resolution with a 10 days temporal resolution for the period 1982-2000. All climate model outputs and observational data set were linearly interpolated to a common rectilinear grid at 2.
Changes in Land Cover Fraction between 1870 and 1992 The changes in the extent of crops and pastures cover between the PD (1992) and PI (1870) periods are not homogeneous over West Africa (Figure  1 ). In the Sahel zone, LULCC increased over northwestern Senegal, Mauritania, parts of Mali, central Burkina Faso, the north of Nigeria, southern Niger, Chad and Sudan. In the Guinea zone, the extension of cropland and pasture is located in the South of Ivory Coast, Ghana, Guinea Conakry and Liberia. Although all LSMs embedded in the LUCID climate models used the same crop and pasture extents for 1870 and 1992, modelers have implemented them using different procedures to incorporate the agricultural data into their own standard vegetation maps. In other words, the various LSMs used different way to characterize the subgrid land cover heterogeneity.
For example, all of them have defined a number of plant functional types (PFTs) to parameterize specific vegetation types, but share a different number of them within the grid-cell (see Table  1  for more details). This can induced significant differences in the deforestation rates that each LSM deduced between the preindustrial times and present-day and, therefore, in the simulated climate responses to LULCC. The land cover maps prescribed in the seven LSMs is consistent with our knowledge of agricultural geography even if there are some limitations about the uncertainties to identifying what has been the actual anthropogenic LULCC. This dataset is similar to the data which is now being used for producing historical simulations  [8]  (Figure  1 , Table  3 ) of the Intergovernmental Panel on Climate Change (IPCC) Coupled Model Intercomparison Project phase 5 (CMIP5).
In order to have a closed SEB relation, Q G is derived explicitly from the other terms in Equation (3), and accounts for the energy fluxes which are not considered here (the flux of heat being transmitted to deeper soil layers). The LUCID models are compared to observed rainfall and surface air temperature data for the Sahelian and Guinean zones. Results for the rainy season solely are depicted in Figure  3  and Table  3  provides a summary for rainy season and annual means as well as information regarding inter-annual variability (estimated from standard deviation). Observed mean daily rainfall in summer (from June to September) is respectively 2. 7 mm/day and 6. 4 mm/day in the Sahel and Guinea zones (Table  4 ). Three out of seven LUCID models underestimate observed rainfall in the Sahel zone (ECHAM, IPSL, SPEEDY), three tend to overestimate it (CCAM, CCSM, ECEARTH), while one simulates about the right amount of rainfall (ARPEGE).
Those results are confirmed in Table  6. The standard deviation represents the inter-annual variability of mean regional summer LAI. All models except ECHAM5 strongly underestimate the observed inter-annual variability. Such feature is quite normal for models that impose a mean climatological LAI (CCAM, ARPEGE, CCSM, ECEARTH). They present no correlation with the observed LAI because they simply have no inter-annual variability. The discrepancies in LAI from one model to another results from the differences in prescribed land cover, but also from differences inherent to the land surface models. For instance, the LAI values imposed to ARPEGE or CCSM do not come from the same database. IPSL and ECHAM5 calculate their LAI as the result of net primary production and allocation processes to various parts of the plants.
Acknowledgments: This work is a contribution to the complex modeling systems program PDI-MSC. This investigation was supported by funding from  IRD  and  Université Pierre et Marie Curie (UPMC). The authors are grateful to the gouvernment of Grand-Duche of Luxembourg through the Reference Office in  Climate Change of the Centre de Suivi Ecologique  and for  LMI-ECLAIRS  project for facilitating travel from Dakar to Paris, which permitted stronger interactions between the principal investigators of this study. The authors are also grateful to all LUCID participants for providing modeling data as well as for the anonymous reviewers and the academic editor for their constructive comments.
Since characterisation of these emissions and their impacts is limited by a lack of in situ data collected in close proximity to sources under Arctic conditions (e. g. stable boundary layers, cold temperatures), new aircraft data were collected along the Norwegian coastal region, and used, together with modelling, to examine the impacts of local emissions on Arctic atmospheric composition and climate in the European Arctic. In addition, as part of ACCESS, present-day and future impacts of local pollution on climate, as well as potential impacts on regional air quality, were estimated over the Arctic using regional and global modelling. Global modelling studies were carried out in collaboration with the Norwegian project ArcAct (unlocking the Arctic Ocean: the climate impact of increased shipping and petroleum activities)  (2012).
Improved estimation of local Arctic emissions ACCESS aircraft campaign data provided valuable new insights into atmospheric compounds emitted from shipping and oil/gas extraction under summertime Arctic conditions and was used to validate recent emission inventories. Figure  2  shows plume snapshots for pollutants in the Arctic lower troposphere (below 600 m). It can be seen that significant local enhancements in nitrogen oxide (NO) and SO 2 are present in cases when pollution from shipping, petroleum extraction or metal smelting activities were sampled downwind of the emission source (0-50 km). These elevated plumes mix into background air which may also be impacted by pollution transported from mid-latitudes. During the campaign, CO was enhanced in the middle and upper troposphere (5-10 km; Fig.
From  Roiger et al. (2015). ÓAmerican Meteorological Society. Used with permission 2013) to derive independent estimates of NO x and SO 2 emission fluxes. These estimates were used to validate emissions for sampled ships from a high-resolution inventory-ship traffic emissions assessment model, version 2 (STEAM2) based on AIS data and taking into account individual ship characteristics (e. g. speed, engine/fuel type)  (Jalkanen et al. 2012). Overall, STEAM2 NO x emissions were biased high (four cases) and SO 2 emissions both low and high (two cases) (see Table  4  in  Marelle et al. 2016). Large biases in emission estimates by STEAM2 were attributed to incomplete technical data or implementation of emission reduction technology not yet taken into account in STEAM2. At the same time, the regional WRF-Chem model was run with and without STEAM2 emissions for July 2012 and compared to average vertical profile data from the ACCESS airborne campaign.
Forschungsgemeinschaft under Grant SPP1294/SCHL1857/2-2 (H. Schlager), the Helmholtz Association under Grant Number VH-NG-606 (Helmholtz-Hochschul-Nachwuchsforschergruppe and European Research Council (ERC) Grant Agreement 640458 (A-LIFE) under EU Horizon 2020/ERC Weinzierl). CICERO scientists also acknowledge support from Norwegian Research Council (Project Number 184873/S30, ''Unlocking the Arctic Ocean: the climate impact of increased shipping and petroleum activities (ArcAct)''. We acknowledge ozone data from National Oceanic and Atmospheric Administration (NOAA)-Earth Systems Research Laboratory (ESRL) Global Monitoring Division (GMD) and Physical Sciences Division (PSD), Boulder (USA) at Barrow, Alaska (USA), NOAA-ESRL GMD/PSD and Rushydrometeorology at Tiksi (Russia) and NILU (Wenche Aas) at Zeppelin (Norway).
Introduction With the progressive adoption of MDE techniques in industry  [10] , existing model persistence solutions have to address scalability issues to store, query, and transform large and complex models  [13]. Indeed, existing modeling frameworks were first designed to handle simple modeling activities, and often rely on XMI-based serialization to store models. While this format is a good fit for small models, it has shown clear limitations when scaling to large ones  [11]. To overcome these limitations, several persistence frameworks based on relational and NoSQL databases have been proposed  [5, 7, 11]. They rely on a lazy-loading mechanism, which reduce memory consumption by loading only accessed objects. These solutions have proven their efficiency compared to state-of-the-art tools, but they are often tailored to a specific data-store implementation.
In these approaches, the choice of the datastore is totally decoupled from the expected model usage (for example complex querying, interactive editing, or complex model-to-model transformation): the persistence layer offers generic scalability improvements, but is not optimized for a specific scenario. For example, a graph-based representation of a model can improve scalability by offering a lazy-loading mechanism, but will have poor execution time performance in scenarios involving repeated atomic value accesses. Our previous work on model persistence have shown that providing a well-suited data store for a specific modeling scenario can dramatically improve performance. Based on this observation, we present in this article NEOEMF, a scalable model persistence framework based on a modular architecture enabling model storage into multiple data stores.
Once the core component has received the modeling operation to perform, it forwards the operation to the appropriate database driver (Map, Graph , or Column), which is in charge of handling the low-level representation of the model. These connectors translate modeling operations into Backend API calls, store the results, and reify database records into EMF EObjects when needed. NEOEMF also embeds a set of default caching strategies that are used to improve performance of client applications, and can be configured transparently at the EMF API level. In addition to this transparent integration into existing EMF applications, NEOEMF provides a specific API, which targets advanced users / high-performance applications. This API provides utility methods which overcome EMF limitations, allow fine-grained tuning of the databases, and access to internal caches.
By using this API, NEOEMF can be tuned to improve execution time and/or scalability of a specific modeling scenario. To provide this smooth integration into the EMF infrastructure, the NEOEMF core component redefines the behavior of several EMF classes. For instance, each NEOEMF driver defines a specific implementation of PersistenceBackendFactory that is responsible of the concrete data store creation. This factory creates an instance of the data store that corresponds to the Resource options. Once the data store has been created, the driver instantiates a specific implementation of the EStore interface-also depending on the Resource options-that translates the delegated method calls into datastore specific API calls. This architecture allows to change the underlying data store by simply updating the Resource options.
-Reflexive/Dynamic API: reflexive and dynamic EMF methods (eSet, eGet, eUnset, eDynamicGet, eDynamicSet. ) can be used on NEOEMF objects, and behave as their standard implementations. -Resource API: NEOEMF also implements the resource specific API, such as get-Contents, getAllContents, save, and load. In addition, NEOEMF takes advantage of the flexible save and load options to enable backend-specific customizations. As other model persistence solutions  [5, 11] , NEOEMF achieves scalability using a lazy-loading mechanism, which loads into memory objects only when they are accessed, overcoming XMI's limitations. Lazy-loading is defined at the core component: NEOEMF implementation of EObject consists of a simple wrapper delegating all its method calls to an EStore, that directly manipulates elements at the database level.
Advanced Features In addition to its compliance with the EMF API, NEOEMF provides specific utility features to tackle EMF's limitations, such as the List <EObject> allInstances(EClass eClass ) method, which is accessible through the PersistentResource interface. This feature tackles the problem of allInstances computation in EMF  [14]  by delegating it to the data store, allowing to retrieve requested element fastly, using data store indexes, or specific data representation. NEOEMF also includes an io module, providing a scalable Model Importer, that consists of an event-based XMI parser that bypasses the EMF API to efficiently store the model in a dedicated database with a low memory footprint. The importer is designed to be generic and can be implemented in each backend component. We also plan to add an efficient Model Exporter module that would allow to produce optimized model serializations from their database representation.
Finally, NeoEMF contains a set of caching strategies that can be plugged on top of the data store according to specific needs. Note that these caches are available for all connectors, unless otherwise stated. -EStructuralFeaturesCaching: a LRU cache storing loaded objects by their accessed feature. -IsSetCaching: a cache keeping the result of isSet calls to avoid multiple accesses to the database. -SizeCaching: a cache keeping the result of size calls on multi-valued features to avoid multiple accesses to the database. -RecordCaches: a set of database-specific caches maintaining a list of records to improve execution time. These caches can be configured using the save and load Resource methods, which allows to add specific options which are then forwarded to the appropriate Persis-tenceBackendFactory.
NEOEMF/MAP NEOEMF/MAP  [7]  has been designed to provide fast access to atomic operations, such as accessing a single element/attribute, and navigating a single reference. This implementation is optimized for EMF API-based accesses, which typically generate atomic and fragmented calls on the model. NEOEMF/MAP embeds a key-value store, which maintains a set of in-memory/on disk maps to speed up model element accesses. The benchmarks performed in previous work  [7]  show that NEOEMF/MAP is the most suitable solution to improve performance and scalability of EMF API-based tools that need to access very large models on a single machine. NEOEMF/MAP data model is composed of three different maps that store model information: (i) a property map, which keeps all objects data in a centralized place; (ii) a type map, which tracks how objects relate to the meta-level (such as the instance of relationships); and (iii) a containment map, which defines the model structure in terms of containment references.
NEOEMF/GRAPH NEOEMF/GRAPH  [2]  persists models in an embedded graph database that represents model elements as vertices, attributes as vertex properties, and references as edges. Metamodel elements are also persisted as vertices in the graph, and are linked to their instances through the INSTANCE_OF relationship. Using graphs to store models allows NEOEMF to benefit from the rich traversal features that graph databases usually provide, such as fast shortest-path computation, or efficient complex navigation paths among several vertices/edges. These advanced query capabilities have been used to develop the Mogwaï  [4]  tool, that maps OCL expressions to graph navigation traversals. On the other hand, graph databases are not well-suited to compute atomic accesses of single elements or attributes, which are typical queries computed in interactive model edition.
NEOEMF/COLUMN NEOEMF/COLUMN  [6]  has been designed to enable the development of distributed MDE-based applications by relying on a distributed column-based datastore. NEOEM-F/COLUMN uses a single table with three column families to store model information: (i) a property column family that keeps all objects data stored together; (ii) a type column family that tracks how objects relate to the meta-level (such as the instance of relationships); and (iii) a containment column family that defines the model structure in terms of containment hierarchy. In contrast with Map and Graph implementations, NEOEMF/COLUMN offers concurrent read/write capabilities and guarantees ACID properties at model element level. It exploits the wide availability of distributed clusters in order to distribute intensive read/write workloads across datanodes.
Implementation NEOEMF has been implemented as a set of open source Eclipse plugins distributed under the EPL license. The NEOEMF website  6  presents an overview of the key features and current ongoing work, and the source code repository is fully available on GitHub (https://github. com/atlanmod/NeoEMF). NEOEMF has been released as part of the MONDO platform  [8]. The NEOEMF/GRAPH implementation relies on Blueprints  [12] , an interface designed to unify graph databases under a common API. Blueprints has been implemented by a large number of databases, such as Neo4j, OrientDB, and Titan. The use of this abstraction layer on top of graph databases enable client applications to use the graph implementation of their choice, as long as it implements the Blueprints API. For now, NEOEMF/GRAPH embeds Blueprints 2.
5. 0 and provides a convenience wrapper for Neo4j 1. 9. 6. An implementation relying on the new Blueprints API (called Tinkerpop3) is under study for now, as well as the creation of additional database wrappers. NEOEMF/MAP embeds the key-value store MapDB 1. 0. 9. MapDB provides Maps, Sets, Lists, Queues and other collections backed by off-heap or on-disk storage, and describes itself as a hybrid between Java Collections and an embedded database engine  [9]. It provides advanced features such as ACID transactions, snapshots, and incremental backups. NEOEMF/MAP relies on the set of Maps provided by MapDB and uses them as a key-value store. NEOEMF/COLUMN is built on top of Apache HBase  [1]  0. 98. 13-hadoop2, a nonrelational wide column database providing distributed data storage on top of HDFS.
To elicit complex and rich graphical displays, and record neuronal phenomena ofinterest while all simultaneously being capable to interact in a closed-loop with external devises is a challenging task to all neurophysiologists. To facilitate this process, we have developed an Open-Source software system using a single computer running a well established Linux architecture (Ubuntu) associated to a kernel duo providing hard real-time support (Xenomai). We show that a single computer using our API is capable, for any tasks that require OpenGL displaying, to acheive millisecond accuracy programmed events. In this report, we describe the design of our system, benchmark and its performance in a real-world setting, and describe some key features.
INTRODUCTION Eliciting graphical displays, while simultaneously recording neuronal phenomena ofinterest and interact in a closed-loop with some external devises is a challenging task to realize in a standertized commonly used computer. One of the first well-known systems to accomplish this task was the complex UNIX-based real-time ( RT ) application developed for oculomotor experiments by  Hays et al. (1982). As new applications have continued to emerge, however, many have forsaken true (or hard) real-time control and response in favor of simplicity, extended functionality, alternative operating systems, and /or user-friendly design. Those systems that have maintained real-time support (e. g. , TEMPO, ePrime, Matlab Psychtoolbox) are often costly, proprietary, and require additional code in order to define specific experiments.
Rexeno is a software we developed that seeks to bind all these characteristics into a single piece of program, using a single computer, taking advantage of the best Open Source ressources available. The main charactestic of this program is that it will be able to interract in real-time with every ressources connected to it (Screens, A/D cards, Hard Drive, etc. ). Our tested system was composed of a Dell Computer with an Intel Duo processor (model E5405) running at 2. 00 GHz and containing 2048MB of RAM (Dell Inc. , Round Rock, TX). The graphics hardware in this machine consisted of an nVidia ENGT250 silent with 1024MB of video RAM. Output from this dual-headed graphics card was split to two subject displays running in full-screen mode at pixel resolutions of 1024 768. The displays were standard cathode-ray tubes mea-suring 19 inches in the diagonal, also from Dell.
The refresh rate for the tests reported here was 60 Hz and the experimenters display window was set to update every 16. 6 ms during behavioral monitoring to allow near-real-time (< 1msec) observation of the subjects performance. To assess the performance of our software, we first collected data from a photodiode coupled with our neurophysiological recording system (Plexon Inc, TX, USA). Thus, we analyzed data simple from the on-going training of two rhesus monkeys (macaca mulatta, male, respectivelly 10. 5 and 16 Kg) in a saccade inhbitory task. For the animal testing and in order to allow eye-tracking, head fixation was achieved using a titanium head-post system (Crist instrument, Hagerstown, MD, USA). Visual fixation was required for a total of 3s (about 1 s of initial fixation followed by a 1-1.