dataesr/scientific-paragraphs-categorization huggingface dataset:
(a) Guessing entropy (GE) on DPAcontest v4. (b) Success rate (SR) on DPAcontest v4. (c) Guessing entropy (GE) on AES_RD dataset. (d) Success rate (SR) on AES_RD dataset. (e) Guessing entropy (GE) on AES_HD. (f) Success rate (SR) on AES_HD.
Consequently, the suspended sediments are principally transported as aggregates (i. e. flocs). The flocculation process also influences the flux and the fate of particles because the formation of flocs influences the transport of sediment via variations of floc density, fall velocity and dispersion in the water column. In this proceeding, we propose a further development of the module SISYPHE, which is now able to simulate sediment transport based on : i) a 10 classes sediment size distribution with specific density values and ii) the consideration of flocculation processes in contrasted hydrological conditions. The performances of the two new model configurations are discussed and evaluated based on the comparison with the standard version of SISYPHE.
The figure  3  shows the monitored turbidity and measured SSC performed synchronously at the downstream boundary of the studied river section since 2014. The corresponding turbidity values range from 0 to 300 NTU. This linear regression between the two datasets exhibits a Pearson's correlation coefficient of 0. 96. Unfortunately, those turbidity values previously recorded remained well below of those recorded in June 2016. Fig. 3. Linear regression between the river water turbidity and the SSC measured at the downstream boundary of the modelled Orne River section. During this flood event, 7 water samples were collected and the corresponding suspended sediment grain size distribution was estimated using a laser scattering SYMPATEC that combines two lenses R2 (0. 45 µm to 87. 5 µm), and R5 (4.
The parameterisation of the SISYPHE and TELEMAC3D models is the same for the different modelling configurations. The first configuration (2CL) corresponds to the standard SYSIPHE configuration, which only considers two classes of sediment particle sizes having distinct sediment densities. In the second configuration (10CL) ten classes of sediment particle size are considered and the input SSC time series are defined for each class. The third configuration (10CLF) combines the latter (10CL) and the added FLOCMOD module. The initial riverbed sediment composition (Fig. 1 ) received two distinct repartitions: one for the riverbed and one for the riverbanks. The two grain size classes of the configuration 2CL are determined as follow: the coarser grain is the median diameter of the non-cohesive sediment for the riverbed and the smaller grain is the median diameter of the cohesive sediment of the riverbank.
Conclusion This study evaluates the sensitivity of the TELEMAC-MASCARET modelling suite to the number sediment size classes considered in the sediment transport module SYSIPHE and to the flocculation process by combination between SYSIPHE and FLOCMOD. First we compared two model configurations with respectively 2 and 10 sediment size classes (without flocculation) based on simulations of a rather high magnitude flood event in a small river show that using only two sediment class leads to spurious simulated erosion fluxes. Furthermore, the deposition/erosion areas are highly impacted by the chosen configuration (10CL and 2CL) as no correlation where found between these two models. The integration of a flocculation module in the sediment transport module of the modelling suite was further analysed.
Digitising and measurement. Skulls were scanned using X-ray microtomography on a SkyScan 1076 (ISEM Institute, Montpellier), Nikon Metrology HMX ST 225 (NHMUK Natural History Museum, London), or SkyScan 1174v2 (The Evans Evolutionary Morphology Lab, Monash University, Melbourne). Acquired voxel size ranged from 18 to 36 μm. We digitised each left turbinal from each individual with Avizo Lite 9. 0. 1 software (VSG Inc. , Burlington, MA, USA). This process was completed by semi-automatically selecting and delimiting each turbinal on each reconstructed virtual slice. Segmentation followed turbinal descriptions presented for Rodentia  80  , Lagomorpha  38  , and Marsupialia  81. According to these references, we divided into 8 or 9 turbinals (Fig. 1  and ESM, Figs. S1 and S2) and followed anatomical terminology of ontogeny  [38] [39] [40] [41].
For example, the nasal septum is partially covered in sensory epithelium  17, 24, 82  but accurate delimitation is not possible with dry skulls. For all following quantitative measures and analyses, we took species averages for which we have multiple specimens (ESM, Table  S8 ). Skull length (SKL) was measured between the most anterior part of the nasal bone and the most posterior part of the occipital bone  83. Snout length (SNL) was measured between the most anterior part of the nasal bone and the posterior-most portion of the naso-frontal suture. The snout width (SNW) was measured across the nasolacrimal capsules  83. Length measurements were exported using Avizo Lite 9. 0. 1 software (VSG Inc. , Burlington, MA, USA). Turbinal surface area. We divided the turbinals into olfactory and respiratory regions to estimate the surface area available for these two functions and used the surface area as a proxy for olfactory or heat and moisture conservation capacities.
Due to the impossibility of estimating the proportion of nasoturbinal that was involved in olfaction or in heat and moisture conservation, we performed separate surface area analyses including nasoturbinal either as respiratory or as olfactory turbinals (ESM, Table  S4 ). Within turbinal regions, we assumed that the different epithelial cells and receptors were evenly distributed and as such, greater surface area indicates greater capacity. We sized turbinal surface areas by the total surface area of all turbinals. The surface area of segmented turbinals were exported using Avizo Lite 9. 0. 1 software (VSG Inc. , Burlington, MA, USA). Turbinal complexity. In addition to surface area, we also used turbinal complexity as a proxy for olfactory and heat or moisture conservation capacities. We interpret complexity as the degree of details in a predefined area.
We considered that all anteriorly positioned turbinals (respiratory turbinals) were involved in heat and moisture conservation, while posterior ones (olfactory turbinals) participated in olfaction. Using ImageJ software  86  , we extracted scanned images corresponding to the middle of the total number of slices composing each turbinal group. We converted the turbinal shape into a single pixel-wide binary contour using skeletonisation. The image was then scaled and centered onto a 300 × 300-pixel black square with Adobe Photoshop CS6 software. Images were converted to grayscale and binary formats. The 2D complexity value was obtained with ImageJ plugin FracLac 87. Slice surface area was used as a size proxy to scale complexity values. To measure 3D turbinal complexity we propose two indices implemented in the freeware MorphoDig  49.
To determine if slopes were significantly different between dietary groups and to compare allometric effects, we performed analysis of covariance (ANCOVA) following Claude  93. We also performed analysis of variance (ANOVA) based on the residuals of PGLS (resPGLS) to test for dietary influence on turbinal surface area, turbinal complexity, snout length, and snout width. To test for group differences, we performed the multiple comparison test of Tukey's HSD based on the residuals of the PGLS with the R package multcomp  94. To compare differences without phylogeny we also performed Tukey's HSD tests based on the residuals of linear regressions. For all analyses based on PGLS we performed model fitting with: a model without phylogeny, Brownian (BM), Ornstein-Uhlenbeck (OU), and Grafen models in order to adapt the phylogenetic model to our data  95, 96.
Secondly, C2 is the difference between Dmax and Dtip. Thirdly, C3 is the ratio between C2 and the sum of all phenotypic distances from ancestors to descendants (Ltot. clade). Contrary to C2 and C3, C1 compares phenotypic similarities and phylogenetic relationships without taking into account the absolute amount of evolution that has occurred during convergence  106. We ran these analyses with a modified R package convevol  107, 108  , performing 1,000 simulations.
Acknowledgements We thank:  S. Cardoso ,  M. Wright ,  J. Clavel ,  I. Ruf ,  R. Allio ,  J. Claude ,  L. Hautier ,  C. Molinier ,  F. Delsuc ,  M. Orliac , and  G. G. Musser. 3D data acquisitions were performed using the μ-CT facilities of the  MRI  platform member of the national infrastructure  France-BioImaging  supported by the  French National Research Agency  ( ANR-10-INBS-04 ,  «Investments  for the future»), and of the  Labex CEMEB  ( ANR-10-LABX-0004 ) and  NUMEV  ( ANR-10-LABX-0020 ). Thanks to  F. Ahmed ,  B. Clark , and  V. Fernandez  for access to the CT-scan facilities at the  Natural History Museum (NHMUK, London). We are grateful to the following people and institutions for granting access to specimens:  S. Morand  with  ANR 07 BDIV 012  CERoPath,  S. Ginot ,  J. Claude ,  F.
Veyrunes ,  F. Bonhomme , and  J. J. Duquesne  ( UM2 );  Y. Chaval  and  N. Charbonnel  (CBGP);  P. Jenkins ,  S. Oxford , and  K. Dixey  ( NHMUK, London );  D. Wilson ,  L. Gordon , and  D. Lunde  ( USNM, Washington , D. C. );  E. Westwig ,  M. Surovy ,  N. Duncan ,  C. Grohé , and  R. S. Voss  ( AMNH, New York );  K. Roberts  and  K. M. C. Rowe  ( NMV, Melbourne );  D. S. Balete ,  A. Ferguson , and  W. T. Stanley  ( FMNH, Chicago );  G. Véron ,  V. Nicolas , and  C. Denys  ( MNHN, Paris ); S. van  Der Mije  ( RMNH, Leiden ). Likewise, we thank the  Research Center for Biology, Indonesian Institute of Sciences (RCB-LIPI ) and the  Museum Zoologicum Bogoriense  for providing staff, and support to carry out fieldwork in the Wallacea. This research received support from:  SYNTHESYS  Project which is financed by the  European Community Research Infrastructure Action  ( FP7 :  GB-TAF-5737 ,  GB-TAF-6945  to the  NHM UK) ,  Agence Nationale de la Recherche  (Défi des autres savoirs,  DS10 ,  ANR-17-CE02-0005 RHINOGRAD 2017 ), PEPS ADAPTATION ADAPTABILITE (SHREWNOSE),  Negaunee Foundation ,  Field Museum's Barbara Brown Fund for Mammal Research National Science Foundation  ( DEB-1441634 ,  DEB-1343517 ,  OISE-0965856 ), and  National Geographic Society  ( 9025-11 ).
Inputs may be passed directly on the command line or through configuration files. They may also be interdependent, for instance, mutually exclusive. Such formal descriptions, simply referred to as descriptors, can be parsed in any programming language, describe command lines regardless of their implementation, and link to a container image where the application is installed. Boutiques descriptors allow for automatic application integration in platforms and advanced validation of input values to prevent errors. Boutiques descriptors are intended to be produced by application developers, stored alongside their application, indexed by common repositories, and consumed by execution platforms. A set of core tools facilitates the construction, validation, import, execution, and publishing of Boutiques descriptors.
Command-line description The core component of the descriptor is a command-line template complying to the syntax of the sh UNIX shell, the default shell on most of the Linux distributions and on OS X. The command-line template is a single string that may contain placeholders for input and output values, called value keys. It may also encompass several commands separated by sh constructs such as semicolons, pipes (|), or ampersands (&), to facilitate the embedding of basic operations on the command line, for instance, directory creation, input decompression, or output archival. Here is an example of a typical command-line template: exampleTool 1 [CONFIG FILE] [STRING INPUT] [FILE INPUT] - exampleTool 2 [FLAG INPUT] [NUMBER INPUT] >> [LOG]. txt The template contains five value keys, identified by square brackets, that will be replaced by values and file names according to the user input when the application is executed.
Workflow support Boutiques does not specify a particular language to build workflows from descriptors, due to the large amount of specialized frameworks to do so. However, workflows can be both composed from and described as Boutiques descriptors; workflow engines can leverage the bosh tools to call Boutiques applications from their descriptors; in turn, workflows can be described as Boutiques descriptors. Such a "task encapsulation" model allows for a scalable and reliable execution of workflows expressed in a variety of languages, as detailed in  [4].
Container images are defined from their URL (rootfs) or image name in a Docker or Singularity index. Descriptors may specify a working directory where the application has to be run, they may indicate if the image has an entry point, and they may also report a hash to accurately identify container images and detect updates. Containers were adopted because they allow for an automated and lightweight integration of application implementations in platforms. They are extremely useful to improve the reproducibility of analyses, as variations in the software environment may have an important impact on the computed results. They also have limitations, in particular, they do not specify the hardware architecture required to execute an application, which can be an issue in some cases.
Core tools Boutiques is available on Python through the PyPi package repository as "boutiques. " The Boutiques package exposes a command-line utility to the user, bosh, which contains entry points for all core functions within Boutiques. The core tools provided by Boutiques are the validator, executor (for both launch and simulation), invocation schema handler, importer, and publisher. The tools exposed through the command-line interface are also available consistently through a Python API by importing the Boutiques package. Though not a component of the Boutiques tool chain, a Jupyter Notebook tutorial exists to facilitate new users getting started with Boutiques. Validator The Boutiques validator checks conformance of JSON descriptors to the Boutiques schema using a basic JSON validator.
CBRAIN CBRAIN (http://github. com/aces/cbrain) [7]  is a web platform to process data distributed into multiple storage locations on computing clusters and clouds. CBRAIN offers transparent access to remote data sources, distributed computing sites, and an array of processing and visualization tools within a controlled, secure environment. The CBRAIN service deployed at the Montreal Neurological Institute relies on the infrastructure provided by Compute Canada  [8]. It currently provides 500+ collaborators in 22 countries with web access to several systems, including six clusters of the Compute Canada high-performance computing infrastructure (totaling more than 100,000 computing cores and 40 PB of disk storage) and Amazon EC2. CBRAIN transiently stores about 10 million files representing more than 50 TB distributed in 42 servers.
We also introduced a new list mechanism in CBRAIN to facilitate the iteration of Boutiques applications on large sets of files. CBRAIN lists are specific files that contain references to other CBRAIN files. When a list is passed to a Boutiques application, the elements in the list are either concatenated in a single command line (when the corresponding Boutiques input is a list) or a new command line is generated for every element in the list (when the input is not a list). Supporting lists as a specific CBRAIN file type allows for improved validation. For instance, lists that contain references to nonexistent or deleted files can be detected. It also allows users to edit lists using their own tools such as scripts or spreadsheet applications.
Nipype Nipype (http://nipype. readthedocs. io/en/latest) [9]  is a workflow engine widely used in neuroinformatics. Nipype workflows can be composed from Boutiques applications using the Python API. As an example, we implemented NipBIDS 3  , a Nipype workflow, to process BIDS datasets using BIDS apps imported as Boutiques applications. NipBIDS iterates participant analyses on all the subjects found in a BIDS dataset and runs a group analysis if requested. SPINE SPINE (http://spinevirtuallab. org), which stands for Structured Planning and Implementation of New Explorations, is a webbased, collaborative platform (virtual laboratory) designed to support the design and execution of experiments centered on specific scientific questions. SPINE enables distributed data collection and management, as well as experiment design, execution, and review.
Boutiques will serve as SPINE's algorithm and workflow repository and enables unequivocal referencing of specific workflows applied to specified datasets within an experiment, thereby describing the provenance and facilitating the reproducibility of image-derived measurements. Workflows in SPINE may combine human image annotation with automated image processing algorithms. Future development will focus on extending Boutiques workflow descriptors to include the identification and characterization of human operators and their specific historic performance on the required tasks. SPINE is currently hosted at Brigham & Women's Hospital in Boston, and supports several international projects.
VIP The Virtual Imaging Platform (VIP)  [10]  is a web portal for medical simulation and image data analysis. VIP makes applications available as services and connects them to the biomed Virtual Organization (VO) in the European Grid Infrastructure  4. The biomed VO interconnects approximately 65 computing sites world-wide and provides access to 130 computing clusters and 5 PB of storage. The VIP service is deployed at the Creatis Laboratory 5  in Lyon France, and it uses the DIRAC French national service  6  to execute jobs on EGI grid and cloud resources. As of October 2017, VIP counts more than 1,000 registered users and a growing number of available applications. Until recently, applications were manually integrated in VIP as workflows written in the Gwendia  [11]  language and executed with the MOTEUR  [12]  engine.
As of today, Boutiques is supported through an importer tool that parses the JSON descriptor and automatically generates the corresponding application workflow and the wrapper script that handles, among other things, the execution of the command line. In VIP, application workflows enable (1) iterations on input lists, (2) the generation of parallel tasks, and (3) the concatenation of multiple applications. For example, the applications used in the MIC-CAI challenges described below required workflows to evaluate results using the metrics defined by the challenge. Application concatenation is handled at the importer level based on predefined workflow templates.
Anatomical imaging FSL Several MRI analysis applications from the FMRIB Software Library (FSL  [13] ) were integrated in CBRAIN using Boutiques: BET, fsl anat, FAST, and FIRST. Descriptors are on Neurolinks. Anima. animaN4BiasCorrection, an ITK-based bias field correction application from the Anima 7  project was made available in VIP through Boutiques.
Functional MRI (fMRI) Niak. The Niak fMRI preprocessing pipeline  [14] , executed with the Pipeline System for Octave and Matlab (PSOM)  [15] , was integrated in CBRAIN through Boutiques. The integration uses the CBRAIN subtasking mechanism described earlier so that even the invocations processing a single subject can be parallelized. It also allows CBRAIN to leverage the efficient agent model used in PSOM, as described in  [16]. The integration required some work in PSOM to facilitate its invocation as a noninteractive command-line application. The resulting CBRAIN plugin is available at https://github. com/SIMEXP/cbrain-plugins-psom. Descriptors are on Neurolinks. GinFizz. We integrated the GinFizz 8  Nipype-based fMRI preprocessing pipeline in VIP with Boutiques. A few technical issues coming from the management of users in Docker containers had to be addressed.
Diffusion imaging MRTrix3 A few applications from the MRtrix3 package  [17]   9  for diffusion MRI processing were also made available in VIP, as well as a pipeline developed at Creatis, that combines MRtrix3 and FSL applications. ndmg. The NeuroData MRI to Graphs one-click connectome estimation pipeline  [18] , developed in Python and leveraging FSL, was exported to Boutiques and is available at https://github. com/neurodata/boutiques-tools. The ndmg pipeline is deployed in CBRAIN via its Boutiques descriptor and is available both through Docker and Singularity container environments.
Image simulation CreaPhase The CreaPhase phase-contrast simulator, developed at Creatis, was integrated in VIP through Boutiques. The inputs had certain particularities (some needed to be enclosed in simple quotes, others were vectors of variable size enclosed in brackets) that required the post-processing of the wrapper script generated by the Boutiques importer. ODIN. The Odin MRI simulator  [19]   10  was integrated in VIP through Boutiques. Since Odin requires important amounts of computing resources, it is executed by VIP on the EGI grid that currently does not support Docker. The Docker image was used just for compilation and testing; the Odin executable was extracted from the Docker image, and the Odin wrapper script was modified accordingly.
Workflow support Boutiques intentionally does not provide a workflow language to compose applications, as this is already possible with numerous workflow engines. Workflows can be either composed from Boutiques applications, as we illustrated with the Nipype and MOTEUR engines, or described as Boutiques applications, as we demonstrated with the Niak fMRI preprocessing pipeline. Furthermore, the CBRAIN platform has a subtasking mechanism that allows Boutiques applications to submit tasks, which is used to parallelize workflows wrapped as Boutiques applications. Based on the CBRAIN experience, we may specify the subtasking mechanism in Boutiques so that other platforms can benefit from it. This model is powerful because it shields the Boutiques specification from specific workflow constructs and it allows a wide range of workflow engines to be described and used uniformly.
Reproducibility Boutiques helps computational reproducibility through containers and formal command-line descriptions. With Boutiques, complete sets of applications could be easily migrated across execution platforms, including high-performance computing clusters and individual laptops, to reproduce analyses. The Boutiques descriptor describes the parameters and implementation of the application, and the invocation schema describes the parameter values. However, reproducibility is a large problem that Boutiques only partially addresses. At the command-line execution level, containers help freeze a large fraction of the software ecosystem but they do not shield against discrepancies arising from different Linux kernel versions or hardware platforms. For instance, containers may not execute consistently on different CPUs that comply with the x86 64 architecture (e.
Common Workflow Language The Common Workflow Language (CWL  13  ) is the work most closely related to Boutiques as it provides a formal way to describe containerized applications. In particular, CWL's Command Line Tool Description overlaps with the Boutiques descriptor. This section highlights the main differences between CWL and Boutiques, based on version 1. 0 of the CWL Command Line Tool Description  14. According to GitHub, CWL started 6 months before Boutiques (September 2014 vs. May 2015).