dataesr/scientific-paragraphs-categorization huggingface dataset:
Calibration of models Mechanistic model calibration. The GR3D calibration was based on simulating a stable allis shad distribution around 1900; consistent with the observed distribution of the species over the 1851-1950 period as described in the EuroDiad 3. 2. database (hereafter: 'historical distribution'). From this, three simulation summary statistics were designed. The first two Summary Statistics (SS 1 and SS 2 ), were defined according to observed historical distribution patterns. In SS 1 , a predicted probability of each basin j to sustain a stable allis shad population p sust1900,j was recorded. This probability relied on the amount of reproduction in the basin j, N rep,j , over the last 10 years of simulation (1891-1900): p sust1900;j ¼ N rep;j 10 : Eq3 Then, based on the observed historical allis shad distribution, SS 1 was computed as the following log-likelihood function: SS 1 ¼ X j2p logðp sust1900;j þ dÞþ X j2a logð1 À p sust1900;j þ dÞ; Eq4 with p referring to all the basins where the species was historically recorded as present, a referring to all the basins where the species was historically recorded as absent and δ a constant fixed to 0.
For Kappa calculation, the probabilities of a basin to be suitable to allis shad derived from the model needed to be transformed into presences-absences using a threshold comprised between 0 and 1. Here, the threshold maximizing the Kappa value was the one applied. Historical allis shad distribution and potential environmental explanatory variables were extracted from the EuroDiad 3. 2 database. Among the 197 river basins describing inland waters of the Western Palearctic region in this database, the species was recorded present in 79 basins and absent in 118 (Fig  2 ; see S1 Table ). Seventy-five percent of species entries from the database were used in model calibration and the remaining part in model validation. Model validation consisted of evaluating model predictive performances on data not utilized during model calibration using the Kappa and AUC metrics.
5 and the high RCP 8. 5. Downscaled projections were limited to one GCM, the CNRM-CM5. Data at 0. 5 degree resolution can be freely downloaded at http://pcmdi9. llnl. gov/esgf-web-fe/. For GR3D, a simulation lasting 300 years (i. e. , 1200 seasonal time steps) was run. During the first 100 years of simulation, water temperatures were fixed to the 1901-1910 mean (i. e. , initialization of a stable allis shad distribution around 1900). Then, temperatures evolved according to the CRU TS 3. 22 database (i. e. , reproduction of temperature evolution of the 1901-2013 period) and to the selected RCP scenarios (i. e. , simulation of temperature evolution for the 2014-2100 period). This 300 years simulation was run 100 times with 100 couples of the two calibrated parameters; their values being randomly sampled in their posterior distributions.
Results Compared to the first modelling attempt of  [28] , the use of the latest version of the CRU TS database to construct the allis shad correlative SDM did not change the explanatory variables retained in the model nor their response curves. Regarding climatic variables, summer air Table  2. Guidelines for interpreting similarities and differences in SDMs outputs in terms of research activities and biological conservation. In bold were given the categories to which the present study was finally assigned. Blank cells signified that preferentially no conservation planning recommendations should be drawn. SDM C and SDM M were abbreviations corresponding to the correlative and mechanistic species distribution models, respectively. temperature was also selected with an optimal value around 16°C.
Nonetheless, species for which a mechanistic model with an explicit dispersal process was built and for which potential range shift was studied by combining SDMs outputs remain rare examples. This constitutes a complex, costly and time-consuming work flow that could not be routinely applied. Scientists are still lacking more operational tools to assess whether species will track future climate change appropriately. In this sense, various studies have demonstrated that species' traits can be important predictors of response to climate change for different taxonomic groups  [103] [104] [105]. In addition, large numerical databases on species traits have been constructed and were made available online (e. g. , FishBase  [106] ; FishTraits  [107] ). Building on this strong background, we are currently developing a generic trait-based method to complement more elaborated modelling approaches such as the one presented here in predicting climate change effects on species assemblages.
3. 2 describes the distribution of European diadromous fishes at three time steps (i. e. , 1750-1850, 1851-1950 and 1951-2010). This database covers the Western Palearctic region including Europe, North Africa and the Middle East, with 197 river basins describing inland waters of those regions (Fig 2). The database records the presence or absence of European diadromous fishes in every basin. Allis shad were recorded 'present' in 79 basins in the first two time periods. Historical suitable basins were mainly in Western Europe, with a few being located in North Africa (Fig 2).
We examined tree-soil habitat associations in lowland forest communities at Paracou, French Guiana. We analyzed a large dataset assembling six permanent plots totaling 37. 5 ha, in which extensive LIDAR-derived topographical data and soil chemical and physical data have been integrated with precise botanical determinations. Map of relative elevation from the nearest stream summarized both soil fertility and hydromorphic characteristics, with seasonally inundated bottomlands having higher soil phosphate content and base saturation, and plateaus having higher soil carbon, nitrogen and aluminum contents. We employed a statistical test of correlations between tree species density and environmental maps, by generating Monte Carlo simulations of random raster images that preserve autocorrelation of the original maps.
Across local topographic gradients that represent differences in light availability and forest turnover rate,  [35]  predict species composition dominated by light-wooded fast-growing species on seasonally inundated bottomlands and by dense-wooded slow-growing species on plateaus. Here we integrate the novel correlation test based on image synthesis to assess species-habitat associations with a comprehensive dataset of replicated permanent plots, large enough (6. 25 ha each) to study the local distribution of species across broad gradients of topography, soil hydrology and fertility. We analyze the distribution of more than 15,800 trees of 94 species in 37. 5 ha of lowland forest to understand how environmental heterogeneity correlates with the spatial distribution of species at a local scale.
Botanical data All species with stem 10 cm in Diameter at Breast Height (DBH) have been identified for the 22,810 trees in the six studied plots, with vouchers determined at the regional herbarium (CAY) and by appropriate taxonomic specialists. A total of 508 distinct morpho-species was identified in this dataset. For this study, we selected species based on several criteria. First, we restricted our analysis to the more common species to avoid spurious species-habitat associations detected for rare taxa. We selected species based on (i) an overall density above one individual per hectare  [41]  and (ii) at least one individual in each of the six 6. 25-ha plots. Second, we removed the two common palm species (Oenocarpus bataua and O. bacaba) from the analysis to restrict our comparison to the guild of dicots.
The resulting dataset contained 94 species from 67 genera and 30 families (with dominant families Lecythidaceae, Chrysobalanaceae, Fabaceae, Sapotaceae), representing 15,823 individuals (S1 Table ). Four of these taxa are morphospecies that are in the process of taxonomic description (Chaetocarpus sp. 1, Euphorbiaceae; Symphonia sp. 1, Tovomita sp. 2 (DS), Tovomita sp. P4, Clusiaceae).
Environmental data To test species-habitat associations we first created maps of environmental factors recognized to be representative of habitat heterogeneity and potentially important for the spatial structure of tree communities. In French Guiana, the local hydrological, physical and geochemical soil features resulting from the weathering process along topographic catenas have been recognized as predominant ecological factors acting on the tree community  [20, 35, 39, 42]. We thus derived continuous environmental maps related to topography, soil hydrology and fertility (Table  1  and S1 File and S2 File and S3 File) against which to contrast tree species distributions. Topography was described with absolute elevation, relative elevation from the nearest stream and local slope angle. Absolute elevation was calculated as a digital terrain model (DTM) derived from LIDAR (Light Detection And Ranging) data acquired across the Paracou site in October 2009.
Relative elevation from the nearest stream, local slope angle, flow accumulation and wetness index were calculated from characteristics of DTM using the package "Terrain Analysis" from SAGA GIS (System for Automated Geoscientific Analyses Geographic Information Systems) software  [43]. Relative elevation represents relative altitude above the nearest stream, which is likely to be more pertinent to local hydrological characteristics than absolute altitude. Local slope angle measures estimated deviation in relation to the horizontal plane. Hydrology was estimated as flow accumulation and wetness index. Flow accumulation estimates surface runoff with the Mass-Flux Method  [44]. Wetness index estimates soil moisture content, computed as a function of local slope angle and the neighboring maximum values of drainage area  [45].
Maps were standardized by default to 32 x 32 cells, which corresponds to a resolution of 7. 8 m per cell, achieved via data smoothing. We used the image synthesis method in two ways. First, we examined correlations between pairs of environmental variables to understand relations between variables and to select key representative variables for subsequent analyses. This analysis was realized on plot 15 only, because it is the only plot which has relatively equal representation of contrasting topographic habitats (i. e. , plateaus and bottomslopes). We then tested for species-habitat associations by examining correlations among the selected environmental variables and raster maps of species abundances for the 94 focal tree species. Density raster maps for each species were created by convoluting occurrence count of species per 7.
Data analyses Most analyses were realized with the free software R  [54]  and more specifically with following packages: raster  [55] , rgdal  [56]  and maptools  [57]  for cartogarphic tools; RGeostats  [58]  for kriging;. SAGA GIS (System for Automated Geoscientific Analysis Geographic Information Systems) free terrain analysis software was used to create hydrological maps from DTM  [43]. MATLAB software  [59]  was used to perform maps' association tests.
This study was carried out within the framework of  EA 's PhD project co-funded by  European Social Fund ,  French Guiana region ,  Centre National d'Etudes Spatiales (CNES)  and  Université des Antilles et de la Guyane. It is a contribution to  Centre d'Etude de la Biodiversite Amazonienne (CEBA) biodiscovery program  funded by an " Investissement d'Avenir"  grant  Agence Nationale de la Recherche  ( CEBA ,  ANR-10-LABX-25-01 ). The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.
Tree plot data are in part publicly available in the forestplots. net database (only for plot 6 of Paracou). Data (coordinates, DBH and determination data) of other control plots of Paracou are private data of Cirad, so these will be distributed upon request to Bruno Hérault (bruno. herault@ecofogdata are publicly available in the TRY database (https://www. try-db. org/TryWeb/Home. php) with the keyword : BRIDGE. Christopher Baraloto updated functional trait data of Paracou in TRY database. DNA sequence data used to construct molecular phylogenetic trees are available in the public database GENBANK LIDAR data for the region are available in the Labex CEBA geoportail: http:// vmcebagn-dev. ird. fr/geonetwork/srv/eng/search#Soil data will be distributed upon request to Vincent Freycon (vincent.
Depth color coding: We modified the "temporal color code" plugin developed by Kota Miura (Centre for Molecular and Cellular Imaging, EMBL Heidelberg, Germany) to apply a color code on each image depending of its depth. Instead of applying a Maximum Intensity Projection of the stack, we choose to use the ImageJ 3D viewer, and thus obtained a 3D reconstruction of cells with and easily readable depth scale, as shown in Figure  3. The plugin we developed is available upon request.
Acknowledgments We thank  Kota Miura  for the temporal color coder plugin for imageJ. Pauline Vandame  ( 2011-2014 ),  Emilie Floquet  and  Magalie Hervieu  (2014-2015) were paid by the  University of Lille  1 and the  Region Nord-Pas-de-Calais. We thank the personal of the BICeL-Lille1-HB facility for access to the microscopy systems and technical advices.
The Cherenkov Telescope Array (CTA) -an array of many tens of Imaging Atmospheric Cherenkov Telescopes deployed on an unprecedented scale -is the next generation instrument in the field of very high energy gamma-ray astronomy. CTA will operate as an open observatory providing data products to the scientific community. An average data stream of about 10 GB/s for about 1000 hours of observation per year, thus producing several PB/year, is expected. Large CPU time is required for data-processing as well for massive Monte Carlo simulations needed for detector calibration purposes. The current CTA computing model is based on a distributed infrastructure for the archive and the data off-line processing. In order to manage the off-line data-processing in a distributed environment, CTA has evaluated the DIRAC (Distributed Infrastructure with Remote Agent Control) system, which is a general framework for the management of tasks over distributed heterogeneous computing environments.
In particular, a production system prototype has been developed, based on the two main DIRAC components, i. e. the Workload Management and Data Management Systems. After three years of successful exploitation of this prototype, for simulations and analysis, we proved that DIRAC provides suitable functionalities needed for the CTA data processing. Based on these results, the CTA development plan aims to achieve an operational production system, based on the DIRAC Workload Management System, to be ready for the start of CTA operation phase in 2017-2018. One more important challenge consists of the development of a fully automatized execution of the CTA workflows. For this purpose, we have identified a third DIRAC component, the so-called Transformation System, which offers very interesting functionalities to achieve this automatisation.
The Transformation System is a 'data-driven' system, allowing to automatically trigger data-processing and data management operations according to pre-defined scenarios. In this paper, we present a brief summary of the DIRAC evaluation done so far, as well as the future developments planned for the CTA production system. In particular, we will focus on the developments of CTA automatic workflows, based on the Transformation System. As a result, we also propose some design optimizations of the Transformation System, in order to fully support the most complex workflows, envisaged in the CTA processing.
Developed in python, DIRAC is composed by a collection of sub-systems, each constituted of services, agents, and a database backend. Examples of sub-systems are the Workload Management System (WMS), the Data Management System, the Transformation System, etc. Each system comprises a generic part, which can be easily extended according to the needs of a specific community. As of today, within CTA there has been no specific need to extend any DIRAC sub-system and the CTA extension is limited to the python API for the job submission and CLIs. However, in view of the future Level 1 data-processing, we have started some development work to improve the DIRAC Transformation System, which will be specifically described in this paper. The paper is organized as follows. In section 2 we will give an overview of the CTA production system, briefly describing the role of its main components.
Overall view of the CTA production system The CTA data-processing, from raw data to high level data, is composed of a set of complex software pipelines (calibration, reconstruction, analysis, Monte Carlo), each one being composed of several application 'stages'. A sequence of stages executed within a single job corresponds to a 'task'. A collection of identical tasks, with a varying parameter, forms a 'production' (see Fig. 1 ). The full processing is thus composed of several productions, each one eventually associated to a given dataset. The CTA production system is based on four main components: 1) Computing Resource Management System (CRMS); 2) Archive System; 3) Pipeline System; 4) Information and Communications (IC) infrastructure. The CRMS manages the whole job's life-cycle, from submission to execution on the IC infrastructure.
Current prototype of the CTA Production system for Monte Carlo simulations In 2011, we have started the evaluation of the DIRAC system for the CRMS, and in particular the DIRAC WMS  [5]. In this context, we have deployed a first prototype, composed of four servers, hosted at PIC and CC-IN2P3. Servers run all the necessary DIRAC services and agents, host the associated databases, as well as the DIRAC web portal. In addition, as the Archive System was still in early development phase, we have also adopted the DIRAC Data Management System, the DIRAC File Catalog and the LHC File Catalog in order to have a fully working framework for Monte Carlo (MC) simulation production. The DIRAC Request Figure  1. Each pipeline is composed by several stages, tools, components and is built within a common framework (see the bottom right box).
A sequence of pipeline stages linked together defines a production, as shown on the bottom left box. Finally, each production is composed by several identical tasks or jobs having a varying input parameter, as for instance the input file to process. System (RMS) has also been installed to asynchronously treat different types of requests coming from jobs or other DIRAC systems. This is used for instance by jobs to recover failed transfers. The Pipeline System is replaced by simple shell scripts executing applications adapted from the currently running Cherenkov experiments. Finally, for the IC infrastructure we exploit the resources made available by several computing centres of the CTA consortium and under the grid EGI (European Grid Infrastructure) framework. During the past three years, this prototype has been extensively exploited for CTA Monte Carlo simulations and analysis dedicated to the CTA 'site selection', i.
Moreover, monitoring is very much simplified as the transformation status is directly accessible via a python API and the DIRAC web interface. Finally, human errors are much reduced. As an example, once the transformation is created, new tasks are added by 'extending' the transformation, making sure that all tasks have the same reference configuration. MC simulations are the most simple example of transformations, since they don't have any input file. However, the Transformation System can be used for many others use-cases, which can be grouped in two categories, i. e. data-processing and data-manipulation. The first category concerns tasks to be treated by the WMS (jobs or 'workflow tasks'), like MC simulation or re-  processing, while the second concerns tasks to be treated by the RMS ('request tasks'), like for instance bulk data removal, replication or transfer.
In the following we will focus more on the first category, since in the CTA production system, data-manipulation will be handled by the Archive System. Besides, transformations can have input files, as in the case of re-processing, or not, as in the case of MC simulations. Input files can be defined either as a fixed list or as the result of a meta-data query. In order to explore the DIRAC Transformation System functionalities, we have implemented a few CTA use-cases, such as re-processing of simulated data, bulk data-removal of obsolete data and data-replication. In 2013-2014, we have run about 10 MC campaigns (see Fig. 2 ), executing a total of 7 M jobs and consuming 170 M CPU HS06 hours. The deletion of old datasets affected about 10 M of files for a total volume of about 125 TB. The successful results of the application of the Transformation System to CTA productions, proved that the system has all the basic functionalities needed for the CTA data-processing.
Evolution of the Transformation System : towards an input-data driven system 4. 1. Transformation System architecture As any DIRAC system, the Transformation System architecture follows a service oriented paradigm. Each DIRAC system is composed of databases, services and agents. Databases keep the persistent state of a system and they are accessed by services and agents as a kind of shared memory. Services are passive components listening to incoming client requests and reacting accordingly by accessing the database back-end. Agents are active components running continuously and invoking periodically their execution methods. They animate the whole system by executing actions, sending requests to DIRAC or third party services. Focusing now on the architecture of the Transformation System, we give below a short description of its main components: • TransformationDB: collects and serves the necessary information to automate the preparation of tasks associated to transformations • TransformationManager service: serves the Transformation System clients accessing the TransformationDB • Agents: -TransformationAgent: processes the transformations found in the TransformationDB and creates the associated tasks, by connecting input files with tasks according to a given plugin -InputDataAgent: updates the files to be attached to the active transformations according to a given meta-data query (inputdataquery) fetched from the Transformation-Manager service -WorkflowTaskAgent: takes the 'workflow tasks' from the TransformationDB and submits them to the WMS -RequestTaskAgent: takes the 'request tasks' from the TransformationDB and submits them to the RMS Interactions between all these components are shown in Fig.
3. To illustrate the system at work, let us consider the example of a 'data-reprocessing' transformation. The production manager creates a transformation, by defining its attributes. Among these, we mention: the body, i. e. the workflow or the request to be executed within a task; the type (e. g. MCSimulation, datareprocessing, removal, etc. ); the inputdataquery and the plugin. The inputdataquery is the meta-data query which selects the list of files to be associated to the transformation. The way the files are grouped and associated to the transformation tasks is determined by the plugin. For instance, files can be grouped according to their physical location, to a given share or until they reach a certain size. Once the transformation is created, it's stored (with its attributes) in the TransformationDB.