dataesr/scientific-paragraphs-categorization huggingface dataset:
CAPS format When a database is BIDS-formatted, it is possible to preprocess its images with Clinica pipelines. These pipelines can for example perform intensity and spatial normalization of brain images to allow the extraction and analysis of comparable features from images of di↵erent participants. Two pipelines have been developed specifically for deep learning use, though the outputs of the other pipelines can also be used with ClinicaDL. These pipelines mainly perform a linear registration to a standard space for two di↵erent modalities: T1-weighted (T1w) magnetic resonance imaging (MRI) and positron emission tomography (PET) images. They output another folder whose structure is derived from BIDS: the ClinicA Processed Structure (CAPS)  22.
Selection metrics During the training procedure of a particular fold, one network is selected per selection metric given in input. These networks correspond to the network having the best validation performance according to their metric during the training procedure. 3. Data groups Finally, the best networks selected are evaluated on data groups. The characteristics of these data groups (TSV file of participant and session IDs with label values, and path to the CAPS directory) are stored at the first level of the hierarchy in the groups folder. This specification ensures the consistency between the evaluations of di↵erent networks trained on di↵erent folds and selected on di↵erent metrics. Only the first fold was trained (folder fold-0) and one model was selected based on its validation loss (folder best-loss).
Conclusion Relying on BIDS allows easing the processing of neuroimaging data as it is a standard format. As already mentioned, many BIDS data sets are hosted on OpenNeuro 24. For the others, tools have been developed to ease their conversion (a list of these tools is available on the BIDS website 25 ). The other formats we introduced (CAPS and MAPS) are useful as these structures are now stable and their elements can be easily processed and retrieved with tools of Clinica or ClinicaDL. For example ClinicaDL includes two quality check procedures taking as input the CAPS generated by pipelines of Clinica (t1-linear 26 and t1-volume 27 ).
org/public/datasets 25 https://bids. neuroimaging. io/benefits. html#converters 26 https://aramislab. paris. inria. fr/clinica/docs/public/latest/Pipelines/ T1_Linear/ 27 https://aramislab. paris. inria. fr/clinica/docs/public/latest/Pipelines/ T1_Volume/ bias. For example, consider a data set that includes several sites. If each site has a di↵erent diagnosis distribution (in the worst case, one site only recruits patients, whereas another one only recruits control subjects), the site is a leaking feature for the diagnosis. Unfortunately, as these sites use di↵erent scanners, the site information may be retrieved from the neuroimaging data. This selection bias requires expert knowledge of the data set used to be avoided. We mainly focus in this article on leakage in training examples, which is independent from the data sets used.
To prevent this pitfall, the source code of ClinicaDL is available on GitHub. Moreover, tests are run at each commit to ensure that the code can be correctly installed and that the main functionalities can be run (see Section 3. 1 for more information on tests). However, sharing code is not enough to be fully transparent. For nondeterministic models such as deep learning, method reproducibility can only be achieved by setting a random seed  [22, 23]. [22]  also evaluated the impact of the computational setup, and explained that the software versions of all the system used, the GPU version and even threading should be explicit to allow method reproducibility. All these variables can be easily set and retrieved when using ClinicaDL. First, the code and documentation of ClinicaDL are versioned to allow the user to retrieve the version needed for method reproducibility.
Results: ClinicaDL overview ClinicaDL is an open-source software platform entirely written in Python. It uses the PyTorch library as backbone. ClinicaDL extends PyTorch features for neuroimaging applications where the data set structure plays a key role in the organisation of the data and metadata. The software is publicly distributed as an easy-to-install package and is referenced in the Pypi package index  28. Releases are done on a periodic basis and the code follows the most standard current practices for software development. ClinicaDL has been designed to be used via the command line interface, with separate sub-commands performing the main tasks, as defined in a classical machine learning pipeline: extract, train, predict. Other sub-commands are available in order to allow the user to structure the data sets, create synthetic data, look for hyperparameters and interpret trained networks.
Distribution and Installation The source code is hosted on Github 29. It uses a version control system (VCS) and the releases are strictly labeled with the version number. As consequence, the source code used in a specific experiment can be easily retrieved. Labeled versions of the code are released as Python packages that are permanently stored in the o cial Python Package Index. Good practices related to the VCS include atomic committing, clear commit messages and peer-reviewed contributions. The installation of the released packages is done with a single command (pip install clinicadl). As often when installing Python packages, users are advised to install it into a virtual environment to avoid requirement conflicts. Instructions for developer installation are also available in the README of the repository.
Continuous Integration and Deployment Each contribution is peer-reviewed by a developer di↵erent from the original author. The resulting code is only integrated to the development branch if the post commit actions are executed in a satisfactory way. The ensemble of these actions is described in the Continuous Integration pipeline. This includes: • Environment and dependencies verification: The creation of an environment with all the dependencies necessary to install the package is performed in this step. • User interface tests: The command line interface is tested using the Pytest library. This library allows combining several sets of possible commands used in the user interface. These are systematically tested to avoid errors in the main interface of ClinicaDL. • Functional tests: A di↵erent kind of tests is executed before the integration of new code.
Model distribution The work described in  [1]  used a preliminary version of ClinicaDL. Several pretrained models generated from the methods described in this paper are available to download via Zenodo 30. These models are also publicly available via a classical https server 31 to facilitate interactive downloading. New versions of the software may induce changes on the organisation of the available models and the way they are loaded and processed by ClinicaDL. For these reasons, new models are trained regularly and stored in folders named with the corresponding software version, e. g. models_v020 corresponds to the models trained with the version 0. 2. 0 of ClinicaDL.
inria. fr/clinicadl/ tuto. The first sections introduce the clinical context of Alzheimer's disease and basics on deep learning classification. The rest of the book is made of interactive notebooks that present the main functionalities of ClinicaDL and can be easily run locally or on Google Colab (which provides free GPU environments). Finally a discussion forum is available at https://groups. google. com/ g/clinica-user. Users can interact with the development team. This tool will be replaced soon by https://github. com/aramis-lab/clinicadl/ discussions.
Preprocessing images ClinicaDL works preferably with images that had been previously preprocessed but one can also perform experiments with unprocessed images, the only requirement is to convert these images to the right format (see Section 2. 1. 2). Preprocessed images can be obtained using Clinica for di↵erent imaging modalities. This software provides, in its current version (0. 5. 0), light preprocessing pipelines for T1w and PET images that output images suited for further deep learning. For example, the t1-linear pipeline mainly performs bias field correction and spatial normalization to the MNI space of T1w MR images, while the pet-linear pipeline mainly performs spatial normalization to the MNI space and intensity normalization of PET images. As ClinicaDL and Clinica are fully compatible, outputs of the formerly mentioned pipelines can be introduced easily into a train or classification function of ClinicaDL.
Preparing metadata To use the train and inference functionalities of the software or to analyse the data, inputs must be organized in the right way. A collection of tools to handle metadata of BIDS-formatted data sets is proposed with ClinicaDL. These tools are intended to provide the correct organisation of the data: get the labels used in classification tasks, split the data to define test, validation and train subsets, and analyze the population of interest. This set of commands is available through the command clinicadl tsvtool. Some of them are still specific to the study of Alzheimer's disease: • Generation of TSV files including only participants with particular restrictions on two Alzheimer's disease data sets (AIBL and OASIS). • Extraction of labels specific to a particular diagnosis trajectory (e.
Training networks The main functionality of ClinicaDL is to train neural networks to learn a task. These tasks can be: 1. Classification (of a categorical label, for example the diagnosis), 2. Regression (of a continuous label, for example the age), 3. Image reconstruction. These tasks are highly dependent from the architecture. All tasks take as input the image or part of it (see Section 2. 1. 3); but for classification the output is a flattened array of size equal to the number of classes, for regression it is a single node, whereas for image reconstruction it has the same size as the input. When the user chooses a task and an architecture, the software will check if the task is compatible with the wanted architecture and will raise an error if it is not the case. Some pre-built architectures are already available in ClinicaDL, but an objective of the library is to allow the users to add their custom architectures easily.
Discussion In this paper we presented ClinicaDL, a Python open-source software for neuroimaging data processing with deep learning. This software includes many functionalities, such as neuroimaging preprocessing, synthetic dataset generation, label definition, data split with similar demographics, architecture search, network training, performance evaluation and trained network interpretation. The three main objectives of ClinicaDL are to (1) help manipulate neuroimaging data sets, (2) prevent data leakage from biasing results and (3) reproduce deep learning experiments. First, ClinicaDL relies on BIDS and CAPS formats to organize raw and processed data, respectively. Though these formats were first introduced for neuroimaging data management, they can be easily extended to any kind of medical imaging data, as it would only require renaming and formatting files of a data set.
Secondly, ClinicaDL prevents data leakage as train and validation data characteristics are saved when the output structure (MAPS) is created. Then, when evaluating the performance of a trained model on a new data group, ClinicaDL checks that this data group is independent from the training and validation groups. However, this only works under the assumption that participants are always named in the same way across data groups. For example, the cohorts OASIS-1, OASIS-2 and OASIS-3 comprise common participants anonymized with di↵erent names depending on the cohort. If OASIS-3 is used for training and OASIS-1 for test evaluation, ClinicaDL will not detect that there is an intersection between training and test data. Then it is the responsibility of the users to check the independence of their data sets.
Finally, none of the libraries reviewed proposed systems to avoid data leakage, though it is a crucial issue in our domain. As exposed in Section 3. 2, the association of Clinica and ClinicaDL covers a large variety of procedures needed in deep learning experiments, that starts from the raw data format and ends with network interpretability. On the contrary, TorchIO is more specialized as it focuses on medical imaging transforms, particularly for data augmentation. This focus results in a larger amount of options in this particular domain. This is why we consider integrating modules from TorchIO for data augmentation in the future. Monai is more complete with the possibility to transform images, and train, evaluate and interpret networks. They also provide a large amount of options for many features which are not customizable yet in ClinicaDL (for example the loss and the optimizer).
Funding The research leading to these results has received funding from the  French government  under management of  Agence Nationale de la Recherche  as part of the  "Investissements d'avenir" program , reference  ANR-19-P3IA-0001  ( PRAIRIE 3IA Institute)  and reference  ANR-10-IAIHU-06  ( Agence Nationale de la Recherche - 10-IA Institut Hospitalo-Universitaire-6 ).
https://github. com/ImagingInformatics/machine-learning 2 https://monai. io 3 https://github. com/NifTK/NiftyNet 4 https://github. com/://github. com/://github. com/neuronets/nobrainer 10 https://github. com/NiftyTorch 11 https://github. com/goeastagent/MildInt 12 https://github. com/rundherum/pymia/tree/master.
Scenario Formulation A literature search was performed with a selection of papers including randomized trials, systematic literature reviews, meta-analyses, and guidelines on peri-operative prophylaxis for the prevention of SSIs in eye surgery. The literature search was performed on the PubMed database, with a selection of English-language articles published from 2000 to 2020. In cases in which the literature of the above years was scarce, the search was expanded to include work from 1980 onward. The key search terms were "antimicrobial prophylaxis" OR "antibiotic prophylaxis" AND "oculistic" OR "cataract" OR "glaucoma" OR "dacryocystitis" OR "intracameral antibiotic" OR "strabismus" OR "blepharoplasty" OR "ocular trauma" OR "foreign body" OR "ocular/eye" OR "retinopathy of prematurity" OR "transplant/transplantation" OR "ocular neoplasia" OR "ocular tumor" OR "corneal grafts" AND "neonate" OR "newborn" OR "paediatric" OR "pediatric" OR "children" OR "adolescent".
Two-Round Consensus Process Based on the scenarios, the questionnaire was submitted to experts on the online platform "REDCap". REDCap (Research Electronic Data Capture) is a secure, web-based software platform designed to support data capture for research studies, providing: (1) an intuitive interface for validated data capture; (2) audit trails for tracking data manipulation and export procedures; (3) automated export procedures for seamless data downloads to common statistical packages; and (4) procedures for data integration and interoperability with external sources. The selected literature was made available to all panel members, who were instructed on how to complete the questionnaire. Experts answered the questionnaire anonymously and their rating was expressed on a scale from 1 (definitely inappropriate) to 9 (definitely appropriate).
Acknowledgments: We would like to thank the other members of the  Peri-Operative Prophylaxis in Neonatal and Paediatric Age (POP-NeoPed) Study Group  who participated in the Consensus:  Alberto Argentiero ,  Matteo Puntoni ,  Cosimo Neglia ,  Isabella Cremonini ,  Mara Caramia-University Hospital of Parma, Parma, Italy ;  Elena Carrara ,  Agnese Corbelli ,  Marcella Gaffuri ,  Francesca Opri ,  Michele Piazza ,  Tessari Denis ,  Laura Venditto ,  Marcella Sibani ,  Evelina Tacconelli-Azienda Ospedaliera-Universitaria di Verona, Verona, Italy ;  Mario Lima ,  Luigia Scudeller ,  Federico Pea-IRCCS Azienda Ospedaliera-Universitaria di Bologna, Bologna, Italy ;  Cinzia Auriti ,  Guido Castelli Gattinara ,  Andrzej Krizystofiak ,  Andrea Dotta ,  Sergio Picardo ,  Alessandro Inserra ,  Massimiliano Raponi ,  Paolo Rossi ,  Alberto Villani-IRCCS Ospedale Pediatrico Bambino Gesù, Rome, Italy ;  Leonardo Bussolin ,  Luisa Galli ,  Carlotta Montagnani-Meyer Hospital ,  University of Florence, Florence, Italy; Alessandro Mugelli, Andrea Novelli-University of Florence, Florence, Italy; Gloria Pelizzo-Università degli Studi di Milano, Milan, Italy ;  Claudia Colomba ,  Giovanni Corsello ,  Marcello Cimador-University of Palermo, Italy ;  Elisabetta Bignamini, Silvia Garazzino-Regina Margherita Hospital, Torino, Italy; Alfonso Papparella-Università Vanvitelli, Napoli, Italy; Giangiacomo Nicolini-Treviso Hospital, Treviso, Italy; Rossella Garra-Catholic University, Roma, Italy ;  Laura Marchesini ,  Simonetta Tesoro-Perugia Hospital, Perugia, Italy; Stefania Stefani-University of Catania, Catania, Italy ;  Valeria Caldarelli-AUSL Reggio Emilia ,  Reggio Emilia , Italy;  Gianni Sava ,  Gabriele Stocco-University of Trieste, Trieste, Italy.
Context. The observational counterparts of theoretically predicted first hydrostatic cores (FHSC) have been searched for in the interstellar medium for nearly two decades now. Distinguishing them from other types of more evolved but still embedded objects remains a challenge because these objects have a short lifetime, are small, and embedded in a dense cocoon. One possible lead to finding them is the characterization of the outflows that are launched by these objects, which are assumed to have a low velocity and be small extent. Aims. We observed the L1451-mm FHSC candidate with the NOEMA interferometer (and complementary IRAM 30m data) in order to study the emission of several molecules. Methods. Molecular lines were reduced and analyzed with the GILDAS package network, the CASSIS software, and some python packages.
Observations and analysis tools The source was observed with the NOEMA interferometer (project number W18AD) on 2019 March 26 and April 7. The D configuration was used with ten antennas. The phase and amplitude calibrators were 0333+321 (both dates), 0234+285 (March 26), and J0329+351 (April 7), and the bandpass calibration was carried out on 3C84. MWC349 and LkHα 101 were used for the flux calibration on April 7 and March 26, respectively. A high number of 64 MHz wide spectral windows were observed between 128 and 152 GHz with a spectral resolution of 62. 5 kHz using the Polyfix correlator. Short spacing observations with the 30m telescope (project ID 214-18) were obtained during June 2019 with the FTS50 backend (dν = 50 kHz). The NOEMA and 30m data were merged after continuum subtraction using the GILDAS software 1  (CLIC and MAPPING; Pety 2005).
The beam size of the merged data is ∼2. 6 ′′ × 2. 2 ′′. Imaging was performed with natural weighting. No mask was used during cleaning, and absolute residuals showed no sign of spatially structured emission The data were resampled with a resolution of 86 kHz (0. 2 km s -1 ). Primary beam (39 ′′ ) correction was applied on the merged data. The rms of the data is about 8 mJy beam -1. The line identification and analysis were made with the GILDAS/LINEDB package as well as the CASSIS software 2  (developed by IRAP-UPS/CNRS). The spectroscopic catalogs used for the line identification are the JPL database 3  (Pickett et al. 1998 ) and the CDMS database 4   (Müller et al. 2005). When discussed in the paper, the line emission sizes were obtained by fitting an elliptical Gaussian in the (u, v) plane using the GILDAS package.
The resulting parameters are the minor and major axes of the full width at half maximum (FWHM) of the elliptical Gaussian. Velocity channel maps were created with GILDAS, and the moment maps were made with the Spec-tralCube python package (within the Astropy project; Astropy Collaboration 2013, 2018) and plotted with APLpy (an opensource plotting package for Python;  Robitaille & Bressert 2012). The conversion of NOEMA data from Jy beam -1 into K was made with SpectralCube.
Tracing the outflow The two velocity components previously discussed are very likely associated with the outflow identified by  Pineda et al. (2011)  and  Maureira et al. (2020). In this section, we use the data obtained from NOEMA data alone because we are only interested in the emission at small scales. For SiO and CH 3 OH, the fluxes are the same, but for CS and H 2 CO, the extended emission is filtered out. Based on the line profiles, we integrated the line intensities over two different ranges of velocities, between 2. 1 and 3. 9 km s -1 (blueshifted emission) and between 3. 9 and 7. 3 km s -1 (redshifted emission). These two emissions are shown in Fig. 1  for the four molecules, superimposed on the total integrated intensity for each transition. The positions of the maximum for each emission are shifted with respect to the continuum maximum position and are slightly different for the four molecules.
In our case, together with the SiO detection, this maser could be the signature of a shock produced by the very young low-velocity outflow. When the other detected lines of methanol (excluding the maser line) are taken into account, we have detected four lines of form E (two of them are blended) and one line of form A. Using the CLASS software, we fit the observed lines on the source position with a Gaussian profile. Only the NOEMA data were used because the line fluxes are the same as the combined data NOEMA + 30 m and the noise is smaller. The observed profiles are not all Gaussians. In particular, the lines at 145 097 and 145 103 MHz have red wings. The integrated intensity computed over the overall velocity range is less than 20% higher than the velocity obtained through a Gaussian fit of the lines.
Summary and conclusions We have presented some NOEMA + 30 m data of a few molecules on the L1451-mm source. In particular, we have detected and mapped H 2 CO, CS, and SiO lines. These three molecules present a double-peak profile that agrees well with an outflow that has been identified by previous publications. We also detected several transitions of methanol. One of these lines appears to be the class I maser line at 146. 618 GHz. This specific transition also seems to present a double-peak profile, while some of the methanol transitions have redshifted wings. Non-LTE radiative transfer analysis of the thermal lines of methanol indicates an H 2 density of about 3 × 10 6 cm -3 and a temperature of about 50 K. We detected DCO + , DCN, HDCO, and SO lines, but their emission is rather extended or not on the source.
For the line widths, we used the value of an approximate Gaussian fit of each line: 2. 6 km s -1 for H 2 CO, 3. 4 km s -1 for CS, and 2. 2 km s -1 for SiO. The collisional coefficients are taken from  Wiesenfeld & Faure (2013)  for H 2 CO, from  Lique et al. (2006)  for CS, and from  Dayou & Balança (2006)  for 6 https://github. com/astropenguin/ndradex SiO. The χ 2 minimization (with a 3σ confidence level) gives a column density of (8. 0 ± 0. 3) × 10 13 cm -2 for H 2 CO, (1. 2 ± 0. 1) × 10 13 cm -2 for CS, and (1. 6 ± 0. 3) × 10 12 cm -2 for SiO. Only the NOEMA data were used to focus on the small scales at which CH 3 OH is seen. For SiO and CH 3 OH, the line-integrated intensities are the same for NOEMA and NOEMA+30m data. The extended emission on the CS and H 2 CO lines appears as a narrow intense peak at the rest velocity of the cloud.