dataesr/scientific-paragraphs-categorization huggingface dataset:
The remaining three codes discussed here (CASTEP, Gaussian and VASP) are commercial, therefore they cannot be redistributed freely without infringing their licenses. Nevertheless, a complete set of instructions is provided in the supplementary material, to guide users who already have access to these codes (on any computer of their choice) to configure them with AiiDA. In this way, the common workflows (all instead available open-source in the Quantum Mobile) can be run seamlessly also for commercial codes. Thanks to this setup, common workflows with these codes can be run with almost no preliminary step required. Only few codes require minimal adjustment that are described in the subsections "running in the Quantum Mobile virtual machine" of the supplementary material. A detailed list of instructions on how to run the test cases presented in this manuscript in the Quantum Mobile is reported in the Supplementary Material.
DATA AVAILABILITY The data and the scripts used to create all the images in this work are available on the Materials Cloud Archive  [40]. Note that the data includes the entire Ai-iDA provenance graph of each workflow execution, as well as the curated data that is extracted from that database in order to produce the images. Abinit ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ BigDFT ✓ ✓ • a ✖ c ✖ c ✖ c ✓ ✓ CASTEP ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ CP2K ✓ ✓ • a ✖ d ✖ d ✓ ✓ ✓ FLEUR ✓ ✓ • a ✓ ✓ ✖ e ✓ ✓ Gaussian • f • f • f • f • f ✓ ✓ ✓ NWChem ✓ ✓ • a • b • b • b ✓ ✓ ORCA • g • g • g • g • g ✓ ✓ ✓ Quantum ESPRESSO ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Siesta ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ VASP ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Table  S2. Overview of which workflow, presented in the main article, could be run by each of the eleven quantum engines. A checkmark (✓) means that the workflow was successfully completed, a circle (•) means the quantum engine does not support the required functionality or structure and a crossmark (✖) means the AiiDA plugin for the quantum engine does not yet support a required feature or it could not successfully run the workflow.
For the latter two cases, a detailed explanation will be given below in the caption. Fe-f and Fe-af stand for ferromagnetic and anti-ferromagnetic iron, respectively. (a) The code does not support geometry optimizations at constant volume of the cell. (b) The code does not support running metallic systems which require smeared occupations. (c) BigDFT and its AiiDA plugin both support metallic systems, however, this requires specific mixing inputs which are still experimental. Although they give good results for the Al test case, the results are not trustworthy for the Fe examples and are therefore not included in the paper. The solution to address the issue is known: a two-steps approach is necessary, restarting the first calculation with a lower electronic temperature. This two-steps approach has been successfully used in earlier versions of PyBigDFT to perform the ∆ test, however, the AiiDA plugin and implementation of the common workflow interface for BigDFT do not yet support it.
(d) The results for CP2K for the iron structure seemed to converge to an incorrect ground state for as of yet unknown reasons and therefore the results have been omitted. (e) In certain rare situations, FLEUR is unable to retain the specified initial magnetization when generating the start density. This sometimes leads to calculations wrongly converging to non-magnetic metastable solutions. This can be fixed by explicitly breaking the magnetic symmetry by means of a small electric field or enforcing initial occupation values, but neither option is currently supported by the implementation of the common workflow interface for FLEUR. (f ) The code is not designed for extended systems although there is some support for it, but the AiiDA plugin does not implement it. (g) The code does not support extended systems.
Running in the Quantum Mobile virtual machine The source code of CASTEP can be compiled using the following commands on Quantum Mobile. We assume that the aiida-castep plugin has been installed as one of the dependencies of aiida-common-workflows. If internet connection is available, the following command can be used to install OpenBLAS in Quantum Mobile: sudo apt -get update sudo apt -get install libopenblas -dev Listing 7. Commands to install the OpenBLAS library. The availability of OpenBLAS may improve the execution speed of the code, but it is not essential. It is also possible to link with intel MKL library, but it is beyond the scope of this guide. Assuming a source archive of CASTEP version 19. 1. 1 is placed in the working directory, paste the following commands into the terminal to compile a binary and setup the Code node for AiiDA: During the compilation, the user will be prompted to confirm the path to the libraries, and directory where the compiled binary to be installed.
The option accepts a value for each engine of the calculation, meaning two integers must be provided for FLEUR ("-n 1 2" for instance) and one for any other code ("-n 4"). Moreover calculations on molecules (H 2 and ammonia) performed with codes designed for extended systems might result in calculations that require a lot of memory. The following list of instructions shows how the results of this paper can be reproduced. The label <code> must be substituted with the name of one of the available quantum engines. 1. Download Quantum Mobile v21. 05. 1 and follow the instructions for its installation. The installation just requires the Virtual Box software. 2. Start the virtual machine, open a terminal and type "workon aiida" to activate the virtual environment where all the python packages are installed.
The command directly plots the energy versus volume data. In case a print of the values is needed, the option "-t -p 4 5" can be added. The "-p 4 5" indicates that the volumes and energies should be printed with 4 and 5 decimal figures respectively. 6. The calculation of the EOS for GeTe is started with the command: aiida -common -w o r k f l o w s launch eos -S GeTe -p precise -r p o s i t i o n s _ s h a p e --< code > Once the calculation is finished, the results can be obtained with the same command explained in the previous point. 7. The calculation of the EOS for Fe in the ferromagnetic arrangement is started with: aiida -common -w o r k f l o w s launch eos -S Fe -p precise -s c o l l i n e a r --< code > The initial magnetization used is different for each <code> since the default is used.
The command for obtaining the results is always the same except that a further integer can be accepted by the "-p" option to indicate the decimal figures for the total magnetization ("-p 4 5 4") for instance. The calculation for the anti-ferromagnetic case is done with: aiida -common -w o r k f l o w s launch eos -S Fe -p precise -s c o l l i n e a r --m a g n e t i z a t i o n _ p e r _ s i t e -4 4 --< code > The only difference respect to the ferromagnetic case is the explicit choice of an initial magnetization. The same options of the plot-eos command can be used to custom the results analysis. For simplicity, we illustrated how to run the test cases using the command line interface of the package. Another possibility is to create a submission script for each case. Detailed documentation on the topic can be found in the aiida-common-workflow online documentation.
This work is supported by the MARVEL National Centre of Competence in Research (NCCR) funded by the Swiss National Science Foundation (grant agreement ID 51NF40-182892) and by the European Union's Horizon 2020 research and innovation programme under grant agreement No. 824143 (European MaX Centre of Excellence "Materials design at the Exascale") and grant agreement No. 814487 (INTERSECT project). The authors thank M. Giantomassi and J. -M. Beuken for their contributions in adding support for PseudoDojo tables to the aiida-pseudo plugin. The authors also thank X. Gonze, M. Giantomassi, M. Probert, C. Pickard, P. Hasnip, J. Hutter, M. Iannuzzi, D. Wortmann, S. Blügel, J. Hess, F.
ACKNOWLEDGMENTS This work is supported by the MARVEL National Centre of Competence in Research (NCCR) funded by the Swiss National Science Foundation (grant agreement ID 51NF40-182892) and by the European Union's Horizon 2020 research and innovation programme under grant agreement No. 824143 (European MaX Centre of Excellence "Materials design at the Exascale") and grant agreement No. 814487 (INTERSECT project). The authors thank M. Giantomassi and J. -M. Beuken for their contributions in adding support for PseudoDojo tables to the aiida-pseudo plugin. The authors also thank X. Gonze, M. Giantomassi, M. Probert, C. Pickard, P. Hasnip, J. Hutter, M. Iannuzzi, D. Wortmann, S. Blügel, J. Hess, F.
This work deals with the modeling of homogenized few-group cross sections by Artificial Neural Networks (ANN). A comprehensive sensitivity study on data normalization, network architectures and training hyper-parameters specifically for Deep and Shallow Feed Forward ANN is presented. The optimal models in terms of reduction in the library size and training time are compared to multi-linear interpolation on a Cartesian grid. The use case is provided by the OECD-NEA Burn-up Credit Criticality Benchmark [1]. The Pytorch [2] machine learning framework is used.
RESULTS The Pytorch package was used  [2] , and our script is available online under MIT license  [13]. The model's accuracy is set forth in terms of the mean average error ME = M i=1 abs(σ i -σ i )/M , and the mean average relative error MRE = M i=1 100abs(σ i /σ i -1)/M being M the size of the set. The model's relative error over all cross sections is TE = |Y| i=1 MRE i /|Y|. We consider the linearly independent variables: the Burnup (0 -45 GWd/t), the Fuel Temperature (500 -1000 • C) and the Boron Concentration (300 -800 ppm) sampled in a 170 × 16 × 16 grid totalizing 43520 data points. The number of dimensions is thus d = 3 and the data set is divided in a randomly sampled Train/Test split of 80/20 %. Train data are further divided in 5 randomly sampled batches aiding the optimizer (Adam  [2] ) to exit local minima, and so 5 network adaptations occur per epoch.
ANN ARCHITECTURE MRE errors for Shallow ANN with varying number of neurons are presented in Table  2  were N = 8 suffices to reach the target accuracy. Actually, error profiles during training are quite similar for N ≥ 8 at least up to 1E5 epochs. The amount of neurons defines the degrees of freedom of the model thus shaping its approximation power, provided a proper training. Fewer neurons imply a simpler parameter space to explore, faster training times and a resulting smaller library size which is also faster to process. We identify a Shallow ANN with N = 8 as the smallest network to analyze with the industry data set. are presented in Fig. 1. a where each layer is separated by "/" in the scheme. Errors decrease monotonically up to 1E3 epochs. Then, fluctuations are noticed since the Adam optimizer explores the parameter space to escape a possible local minimum.
Train errors on the contrary keep diminishing even reaching ML for all cross section as the set is being memorized by the network. Different regularization techniques are available for ANN that could be implemented to improve these result such as dropout, batch normalization or a standard L 2 regularization. An error histogram for the ANN N = 13/13 discriminated by cross section is presented in Fig. , the ratio of parameters in the ANN model with respect to mulit-linear, is presented for these cases. Errors are reported at 1E6 epochs except for the N = 13/13 ANN with the industry data set which is at 2E4 epochs (early stop criterion). All ANN errors are lower than 1E -2 and a significant reduction of up to 99. 7% is obtained. In general, cross section can be considered smooth noiseless functions and if enough train data is available (with respect to the degrees of freedom of the ANN) as is the case with the 80/20 split, train errors are quite representative of test error.
PERFORMANCE REMARKS For the ANN considered in this work training and evaluation times are presented in Table  5. The hardware used was a CPU of 24 cores of 2300 MHz and 126 GB of RAM with a GeForce GTX 1080, Python 2. 7 and Cuda 10. 1  [14]. Training times are given per epoch including a single network adaptation (only one batch equal to the train set). The training time of an epoch ranges from 1E -3 to 1E -1 depending on the availability of GPU acceleration. As considered in work 1E6 epochs and 5 batches a non-negligible calculation time of about 3h/ANN/σ may be required whereas for 7E2 epochs only a few seconds. An evaluation vector of size 5E5 was considered and times are expressed per evaluation point. 8 2E -3 2E -3 1E -9 7E -3 1E -3 2E -8 50 2E -3 2E -3 2E -9 2E -2 2E -3 3E -7 200 3E -3 2E -3 4E -9 1E -1 5E -3 1E -6 13/13 3E -3 3E -3 8E -10 2E -2 3E -3 1E -7 Table  5 : Training and evaluation times for a single ANN.
Values suggested by the literature proved to be adequate, especially for the learning rate. Provided a constant amount of degrees of freedom (library size), considering 2-3 layers improved the error convergence rate with respect to a Shallow ANN. As evidenced by fluctuation in the training error at a high amount of epochs, a few layers seem to provide a richer parameter space for the optimizer. Architectures with different numbers of neurons per layer did not offer any relevant advantage. With the 80/20 % split, where the train data has a size of ∼ 3. 6E4, cross sections train errors were systematically representative of test error. Two ANN models of interest were retained for the industry data set: the first characterized by fast convergence and low error, composed of two layers (N = 13/13), and the second one for maximal reduction of a single layer (N = 8).
They were able to achieve an acceptable error 0. 1% after short training of 6E3 and 7E2 epochs for the ANN of N = 8 and N = 13/13 respectably. Nonetheless the multi-linear errors were not reached for all cross section even after 1E6 epochs and the N = 13/13 showed over-fitting in this smaller industry data set. Evaluation times were quite compatible with the expected industry standard though CPU training times could become prohibitively large, specially for ANN counting more than a few neurons without GPU acceleration. For the two ANN of interest with the two considered train set a significant reduction of up to 99. 8% was obtained.
Introduction To date, several different software solutions for data pre-processing have been proposed, and new ones are published continuously. However, reproducibility, comparability and reliability of results generated via such algorithms remain challenging and difficult to assess or compare. Difficulties in the evaluation are primarily due to complex parameter options used for pre-processing within various tools and the complexity of the analysis, which can potentially affect and vary the outcome  (Li et al. , 2018). In metabolomics and particularly for non-targeted metabolomics, there are no 'gold standard' experimental datasets or a trusted set of methods to evaluate parameter choices and tools [e. g. Sanger sequencing for genomics  (Sanger et al. , 1977) ]. Moreover, differences in instrumentation, acquisition strategies or sample complexity might not draw a general conclusion from a potential gold standard dataset.
While there are software packages for automatized non-targeted data pre-processing (NPP) parameter optimization and adaption [e. g. IPO  (Libiseller et al. , 2015) , Autotuner  (McLean et al. , 2020) ], they are not meant to assess the general quality of NPP results (More details in Supplementary Material S1). Hence there is a need for a strategy to assess the reliability of non-targeted data pre-processing (NPP) for LC-HRMS data on a routine case by case basis. This led us to develop the R package mzRAPP (Reliability Assessment for NPP), which enabled the extraction of well-defined NPP performance metrics from existing experimental datasets, by generating a benchmark (BM) subset to evaluate NPP-results (Fig. 1 ). For benchmarking, mzRAPP relies on user-provided input, specific to the experimental chromatographic setup [approximated retention time (RT) boundaries for a subset of compounds with known molecular formulas] for the generation of a BM.
Implementation and methods The mzRAPP-package has been developed with the R environment (version 4. 0. 3) and implemented as a shiny app for ease of use. It can be navigated in a two-step procedure, resulting in ten different NPP performance metrics. The first step is a module responsible for confirming the consistency of user-provided information (RT boundaries for different molecular formulas) with information extracted from the raw data in order to generate a sub-dataset-specific BM. This is achieved by comparing the enviPat-predicted isotopologue (IT) ratios  (Loos et al. , 2015)  to those extracted from mzML files using user-supplied boundaries (see GitHub for details). Next, the BM is used as a reference point leading to the generation of several NPP-performance metrics for the evaluation of chromatographic peak picking and alignment as well as the aligned features, respectively.
The output metrics include measurements to judge the proportion of missed peaks, quality of reported peak abundances, nature of missed peaks and alignment error counts. Interactive plots providing an overview and context to all metrics can be inspected interactively within the shiny app. As a result, several different NPP algorithms across tools with different parameter choices, can be evaluated for an optimal outcome. Below are the main theme and underlying methods developed for the mzRAPP package and the description of important key functionalities.
Assessing NPP reliability Since the BM can be edited by the user its data structure is checked via check_benchmark_input before being used for NPP assessment. The mzRAPP-package supports output formats from the five most common NPP tools, such as XCMS, MS-DIAL  (Tsugawa et al. , 2015)  and MZmine 2  (Pluskal et al. , 2010). The check_ nonTargeted_input function checks the presence of all components necessary for subsequent matching procedures and generates a generic format output for downstream processing. Next mzRAPPs com-pare_peaks function performs a series of non-equivalent joins between the BM and supplied NPP output tables. The result is returned as a list object which serves as input for different downstream analysis and plotting functions [e. g. derive_performance_metrics (details are provided in Supplementary Material S2) and plot_sunburst_peakQuality].
Graphical user interface A comprehensive GUI was developed to help metabolomics scientists with different computational skill sets access mzRAPP software solutions for NPP evaluation. The callmzRAPP function allows users to generate BMs and assess NPP without requiring any command-line functions. The mzML files are analyzed and inspected via non-targeted data pre-processing (e. g. via XCMS, MZmine 2, MS-DIAL) and then used to generate and validate a BM using known IT ratios. The generated BM is then utilized to assess the performance of NPP peak picking, peak alignment and feature processing across NPP methods. Subsequently, different performance metrics can be derived as a result. (b) The mzRAPP output graphics include different sunburst quality evaluation plots. From left to right, sunburst plots describe the peak detection (true positive/false negative peaks) and abundance (IT ratio bias) quality before (inner donut) and after alignment (outer donut).
Microarray Analysis Gene expression profiling was performed using the GeneChip ® Human Transcriptome Array 2. 0 (Thermo Fisher Scientific, Waltham, MA, USA) including more than 6. 0 million distinct probes covering both coding and non-coding genes built on transcript mappings from hg19 human reference sequence (GRCh37). A total of 400,000 full length transcripts were combined from available public data sources: RefSeq NCBI, UCSC Genes, Vega, GENCODE, Ensembl, Mammalian Gene Collection. Additional long non-coding content was combined from the UCSC genome browser, noncode. org, Broad Human Body Map. Probes are distributed across the full length of the gene including specific probes (>339. 000 probe sets) covering splice junction, providing a complete and accurate picture of overall gene expression with the additional ability for transcript isoform analysis.
Each DNA fragment is endlabelled with biotin using terminal deoxynucleotidyltransferase before being hybridized to the arrays for 16 h at 45°C in a GeneChip Hybridization Oven 640. Following hybridization and post hybridization washes each array were scanned using the GeneChip Scanner 3000 7G to generate the raw data (. CEL file). The QC steps of the experiment were performed using Expression Console v1. 4 (Thermo Fisher Scientific, Waltham, MA, USA) software. CEL files were first processed with the Affymetrix collection of command line programs Analysis Power Tools (APT, v1. 16. 0) using the apt-probeset-summarize command in order to estimate the intensity at gene level with the RMA-sketch normalization. In this step background corrected raw data were Log2-transformed and quantile-normalized following the Robust Multichip Average (RMA) procedure as described in Irizarry et al.
(12). For gene annotation the file "HTA-2_0. na34. hg19. transcript" (obtained from Affymetrix) was used. R v3. 1. 2 (www. r-project. org) environment and Bioconductor (www. bioconductor. org) packages were used for the following preprocessing and statistical analysis. PCA was performed with the native R function prcomp on RMA-normalized data and the first two principal components were plotted with ggplot2 package functions. Hierarchical clustering of sample Euclidean distances was performed with hclust and dist native R functions and the resulting heatmap was plotted with gplots package heatmap. 2 function. Finally, tRanslatome package pipeline was used to find out the probe sets that showed significant (FDR < 0. 01) differential expression between experimental conditions and to perform the Gene Ontology (GO) Database (  13 ) enrichment analysis, internally using the limma -Linear Models for Microarray Data -(  14 ) and topGO methods, respectively.
Digital PCR experiments were carried out on the BioMark HD System (Fluidigm, San Francisco, CA, USA) by loading cDNA samples into Fluidigm's 37K Digital Array microfluidic chip as previously described  (8). Briefly, Fluidigm's 37K Digital Array consists of 48 panels, each of which is further partitioned into 770 reaction chambers. The reaction for each panel was set up with the specific TaqMan assay probe and with TaqMan Universal Master Mix II (Applied Biosystems) into a final volume of 5 ml. For each sample, six serial dilutions were loaded in triplicate reactions and the chip was then thermocycled and imaged on Fluidigm's BioMark HD real-time PCR system. Positive chambers that originally contained 1 or more molecules has been counted by the Digital PCR analysis software (Fluidigm) and only templates that yielded 150-360 amplified molecules per panel were chosen for technical replication in order to obtain absolute quantification of target RNA copy number.
The quantifications of P-p70S6K S371, P-p70S6K T389, total GSK-3b, P-GSK-3b S9, P-GS S641, P-p44/ 42 T202/Y204, total p38 and P-p38 Y180/Y182 were performed by calculating their ratio compared to the actin level by using ImageLab software (Bio-Rad) and then calculating the ratio among infected/treated vs uninfected conditions.