dataesr/scientific-paragraphs-categorization huggingface dataset:
Microcanonical simulations of CNT potentials In UNRES, the conformational search is carried out by using coarse-grained molecular dynamics and its extensions. Therefore, after implementing the nanotube in the UNRES, we checked energy conservation in the constant volume, constant number of particles, and constant energy (NVE) MD simulations also termed microcanonical simulations. We used the Trp-cage (PDB ID: 1L2Y) as a model system. Initially, the protein was placed inside of the periodic box with each of the sides equal to 220 Å. The first residue was placed ~10 Å from the CNT center with a CNT radius (R 0 ) of 6 Å resulting in a slightly positive value of the protein-CNT interactions. This structure was energy minimized with the energy weight w CNT = 1; the same weight was used in all further investigations.
Acknowledgments This work was supported by grant  UMO-2015/17/N/ ST4/03935  from the  National Science Centre. Computational resources were also provided by (a) the supercomputer resources at the  Informatics Center of the Metropolitan Academic Network (IC MAN ) in Gdansk, and (b) computational resources at the  Interdisciplinary Center for Mathematical and Computer Modeling in Warsaw (ICM) , grant  GA65-20 , and (c) our 682-processor Beowulf cluster at the  Faculty of Chemistry, University of Gdansk. We would like to thank  Prof. Jacek Koronacki  for helpful comments.
Normalized enrichment scores for more cell types are shown in Additional file 1: Figure  S17. PCA principal component analysis clusters in Fig. 6a , respectively). At the end of the tutorial, the authors concluded that the memory/naive split was weak and more cells would be needed to give a better separation between the two CD4+ T-cell subclusters. To find DE genes between the two CD4+ T-cell subclusters, we used SEURAT, unweighted EDGER, ZINB-WaVE-weighted EDGER, MAST, and limma-voom. We then sought to identify cell types using gene set enrichment analysis (GSEA), with the function fgsea from the Bioconductor R package FGSEA  [40]  and gene sets for 64 immune and stroma cell types from the R package XCELL  [41]. While unweighted EDGER found that one cluster was enriched in both CD4+ memory and naive T cells compared to the other cluster, our weighted EDGER method as well as SEURAT and limma-voom found that the cluster was enriched in CD4+ T-effector memory, CD4+ T-central memory, and CD4+ memory T cells, and depleted in CD4+ naive T cells.
Conclusion In summary, we provide a realistic simulation framework for scRNA-seq data and use the well-tested ZINB-WaVE method to identify excess zeros successfully and yield gene-and cell-specific weights for DE analysis in scRNAseq experiments. The tools we have developed allow an integrated workflow for normalization, dimensionality reduction, cell-type discovery, and the identification of cell-type marker genes. We confirmed that state-ofthe-art scRNA-seq tools do not improve upon common bulk RNA-seq tools for DE analysis based on scRNAseq data. Our workflow, however, outperforms current methods and has the merit that its performance does not deteriorate in the absence of zero inflation. The inference of DE is focused on the count component of the ZINB model and our method produces posterior probabilities that can be used as observation-level weights by bulk RNA-seq tools.
EDGER We extended the EDGER package  [2, 50]  by fitting a NB model genewise, with ZINB-WaVE posterior probabilities as observation-level weights in the weights slot of an object of class DGEList, and estimating the dispersion parameter by the usual approximate empirical Bayes shrinkage. Downweighting is accounted for by adjusting the degrees of freedom of the null distribution of the test statistics. Specifically, we reintroduced the moderated F test from a previous version of EDGER, where the denominator residual degrees of freedom df j for a particular gene j are adjusted by the extent of zero inflation identified for this gene, i. e. , df j = i w ijp, where w ij is the ZINB-WaVE weight for gene j in cell i and p the number of parameters estimated in the NB GLM. This weighted F test is implemented in the function glmWeightedF from the Bioconductor R package ZINBWAVE.
2012; Eckhoff and Wenger 2016) , and how it has expanded beyond malaria to include other infectious diseases that share a common framework. We discuss how multiple layers of detail become intertwined in the dynamics of transmission and the diverse group of professionals required to make this level of software complexity feasible and reliable. EMOD has been developed over more than a decade by professional software developers, and so it has capabilities that would be very difficult to develop at an academic institution with shorter-duration PhD and post-doctoral trainee positions. By making the code and documentation openly available, the team hopes to enable infectious disease researchers, policy-makers, implementers and funders to access modeling software that is difficult to produce with the time and staffing more commonly available in academic and similar organizations.
Without altering the internal SEIRS disease process, such a structure allows for the transmission mechanism to be switched, e. g. by adding an explicit contact network of remembered relationships between agents. More complex modeling of transmission modes can be necessary not just to capture transmission dynamics, but also to ensure that the impacts of interventions and their interactions can be accounted for. For example, for vector-borne diseases such as malaria, interventions can target multiple points in the vector's life cycle, as illustrated in Fig. 2 , a diagram of the feeding cycle in the EMOD vector-borne disease model  (Eckhoff 2011). The daily vector survival, feeding, vectorto-human disease transmission and egg-laying model is itself complex, but is just one module of the larger model illustrated in Fig.
Spatiotemporal patterns of health care access and delivery can have disease-specific components, but if made sufficiently configurable, much of this infrastructure can be shared across diseases. The disease-agnostic infrastructure of an IBM is often the most time-consuming and complex to create initially, but can be shared across disease models if the code is designed in a reusable way, made available and maintained after the initial research applications are complete. an insect vector such as a mosquito in the EMOD vector model. This branching tree of conditional probabilities is used to determine the proportion of vectors that die, survive, feed and reproduce each day. Multiple simultaneous interventions can target various branches in the vector feeding tree, and the deterrent and toxic effects of multiple interventions can be represented simultaneously.
The EMOD model provides a flexible framework to build simulations with different scales and different spatial resolutions so as to match the policy question of interest. For example, a polio model of Kano state (built upon the generic code base) simulated over 1322 nodes to represent the different clusters of populations across the state so as to capture the dynamics of the final chains of transmission, and to understand how long after the last case of the disease was detected could we be sure that the disease had been eliminated (McCarthy, Chabot-Couture and Shuaib 2016). In contrast, a polio model of 16 West African countries was also built using the EMOD software where each subnational administrative unit (state or province) for each country was simulated as a single node. The resulting 210 nodes were used to study the propagation of vaccine infections following the outbreak response vaccination campaigns during the polio endgame using live poliovirus vaccine  (McCarthy et al.
2017). Another advantage of the inheritance structure in EMOD is the ability to add a new disease with less effort, since much of the generic framework and transmission-mode-specific logic is already available. To make it easier to add new disease models, EMOD also supports a 'custom' disease class in which researchers supply a Python script to describe the disease process. EMOD is written in C ++ for computational speed, but Python is a more commonly used programming language in research and allows for rapid prototyping on top of the EMOD framework. To visualize the relative ease of adding new diseases to the EMOD framework, compare the number of lines of code devoted to the generic EMOD, transmission code and disease-specific code (Fig. 5 ). The common framework, which is inherited by all disease types and sufficient in itself to run the generic SEIRS model, occupies over 34 000 lines of code.
2017 ; do Nascimento, Barker and Brodsky 2018), and the impact of other health system changes such as decentralization and differentiated care on patient retention  (Bor et al. 2017; Murray et al. 2017). Making changes to health care patterns in the EMOD source code required re-compiling and re-testing the model, which limited the speed and frequency of updates to the health system model. To address this problem, the 'campaign' framework in EMOD was developed to allow user input to flexibly configure the series of triggers, decisions, delays and targeting/filters that represent the process of providing interventions to individuals. The framework can also be used to deliver targeted seeding of new infections (required for initializing the epidemic) and adding or removing co-factors for transmission.
The triggerable campaign framework has also been used to configure reactive case investigation in a spatial malaria model, where treatment of an index case in a household broadcasts the signal for case investigation only to neighboring households  (Gerardin et al. 2017). The flexible campaign framework allows for rapid response to policy and implementation questions by adding de novo structures to health-seeking and health delivery models without the need to modify model code. However, other structural changes to model assumptions, such as addition of new features or new disease types, do require code modifications. In the following section, we describe the software processes and quality assurance measures used validate and maintain EMOD.
The source code for EMOD is available online at https://github. com/InstituteForDiseaseModeling/EMOD. To develop new features or disease applications using EMOD, researchers from the team and collaborating institutions may choose to contribute code to the model, or to provide detailed specifications to a software developer who will implement the new feature or change. Code changes are subject to code review by a designated maintainer of the code repository. After a feature is added, the researcher who requested it is tasked with designing a test case to ensure that the feature works as specified from a scientific perspective. In addition, professional software testers perform further testing to assess technical adherence to the specification, as well as other factors such as informative error messages and handling of corner cases.
The size and collaborative development of the EMOD codebase necessitates a more formal level of testing, including automation of testing. Software developers generally perform some degree of testing in the course of model development, ensuring that new feature is behaving as expected. The simplest form of testing consists of 'trying out' the new feature with a set of EMOD input files and inspecting the output files for the anticipated result. However, it is also necessary to ensure that the changes did not inadvertently alter some other aspect of the model-potentially in a different disease area than the one for which the feature was intended. To address this issue, the feature-specific tests (model input and the expected output) that are created in the course of development are stored over time and aggregated into a set of test cases known as regression tests.
EMOD currently includes over 600 tests producing over 1200 output files, available online at https://github. com/InstituteforDiseaseModeling/EMOD/tree/ master/Regression. When a new feature is added, it is   c ) is HIV testing of children. The building blocks specify the time that the intervention becomes available (Start Year); the target population based on socio-demographic strata such as age, sex, location and user-defined characteristics such as risk group or accessibility ('Accessibility': 'Yes'); and the triggering condition for the intervention to be applied, if any. The triggering condition can be one arising from the internal dynamics of the model (such as becoming six weeks of age, as in the example above, 'SixWeeksOld') or can be a user-defined event arising from another building block (such as the output of the example above, 'ARTStagingDiagnostic Test,' which will trigger the next event to happen as shown by the red arrow in (b)).
Building blocks may act as probabilistic decisions, delays, diagnostics and interventions. Some building blocks allow for additional user input, for example, the probabilistic decision of whether to be tested for HIV in (b) and (c) allows user to input a time-series for the probability of HIV testing. EMOD will linearly interpolate the time-series to assign a probability at each simulation time step, as shown in the orange graph in (b). recommended to run the entire batch of regression tests in order to check whether the code changes have altered the output of any previous test case. At IDM, the tests are automatically run nightly with the latest version of the EMOD code. After a nightly run, the files are compared against the previous day's output and changed files are flagged for further investigation.
The regression test system alerts the team to any test for which the output files are non-identical to the previous day's output, regardless of whether the changes to the output files are substantive. It is not uncommon for these differences to be 'false alarms. ' In the case of Monte Carlo agent-based models, a change to the number or sequence of calls to a random number generator can alter the output of a given simulation run, but would not change the scientific behavior of the model, e. g. average result of multiple stochastic replicates. To enable model testing when random number streams have changed, and more generally, to provide a more thorough comparison of the model's behavior relative to its scientific specification, the team has developed more intensive tests termed Scientific Feature Tests (SFTs), of which over 140 are currently available at https://github.
com/InstituteforDiseaseModeling/ EMOD/tree/master/Regression (a separate folder of SFTs is available for each disease type). An example of an SFT is checking whether random draws from a specified probability distribution really do follow the expected distribution, e. g. by repeatedly sampling from the distribution and ensuring that it is statistically unlikely to differ from the expectation. SFTs can sometimes be thought of as 'black-box testing' because they test the model's behavior based on its outputs, regardless of the internal implementation. In contrast to the 'black box testing' approach of SFTs, a 'white box testing' approach is also taken to examine the internal workings of the software itself, including implementationspecific aspects of the software that are not user-facing. Such tests are typically referred to as 'component tests' or 'unit tests' and sometimes require separate code, known as test harnesses, to instantiate and examine individual components of the model in isolation.
Available component tests for EMOD can be found at https://github. com/InstituteforDiseaseModeling/EMOD/tree/ master/componentTests. Component tests allow for verification of model functionality when subtle problems with a feature might not be evident from the output of the overall epidemic simulation. For example, such a test might generate a population of individuals with unique identifiers, and then check whether the correct numbers of unique identifiers were created in memory. Other examples include verifying whether diagnostics appropriately exhibit the configured specificity and sensitivity, or whether sexual relationships interact appropriately with migration. The development team also includes software documentation professionals. Technical documentation is available online at www.
idmod. org/documentation and training materials are in development and have been piloted in university courses, onsite trainings and trainings held at collaborating institutions. In addition, the EMOD executable can generate a schema, or list of all parameters available in the version of the software being run. The schema includes parameter names, data types, defaults, ranges and short descriptions. A frontier for EMOD is learning the most effective way to support new users with a variety of goals, timelines and experience levels. The configurability of EMOD makes the model suitable for multiple purposes: it can be used to triangulate baseline data for estimates of disease trends, to forecast impact of interventions with detailed patterns of uptake and to connect with economic models to address resource allocation questions.
The data and effort required to parameterize and fit EMOD to specific settings also make it more suitable for settings in which detailed data are available, particularly data stratified by population categories such as age groups and geographic regions. In principle, most forms of model detail can be disabled or configured to mirror a simple assumption (for example, birth rates can be made proportional to population size and mortality rates can be age, sex and time invariant). However, computational and ease-of-use limitations make EMOD an unlikely choice for simulations that could be conducted with simpler compartmental models. Instead, EMOD is typically applied in data-rich settings. Considering the effort required to fit EMOD to a new setting, it is unlikely that EMOD will be applied systematically to all settings affected by diseases, as has been done with other modeling software in order to produce estimates in all countries of the world with a systematic and harmonized approach.
CONCLUSIONS Dynamic modeling of infectious diseases using IBMs brings together a diverse set of disciplines at different scales of detail, from within-host biological processes to between-host interactions to population-level patterns. The interaction of these components brings about a level of complexity that requires software discipline and formal testing and benefits greatly from sharing of code across disease applications to maximize code usage for efficiency and debugging. We have described the experience of developing EMOD, a multi-disease modeling framework that uses a modular approach to define interactions between model components, and OOP to maximize sharing of features across disease applications. With support from Bill and Melinda Gates through the Global Good Fund, EMOD is available free of charge, and source code is openly available.
Metabonomics data analysis The raw UPLC-Q-TOF/MS data were converted to mzXML files using Proteo Wizard MSconventer tool and then processed using XCMS online software. The parameters in XCMS were set as follows: centwave settings for feature detection (Δm/z = 25 ppm, peakwidth = c (10, 60)); obiwarp settings for retention time correction (profStep = 1); and parameters including minfrac = 0. 5, bw = 5 and mzwid = 0. 025 for chromatogram alignment. After being normalized and integrated by using support vector regression, the processed data were uploaded into MetaboAnalyst software for further analysis (www. metaboanalyst. ca). Principal component analysis (PCA) and partial least square discriminant analysis (PLS-DA) were performed for both positive and negative models after log transformation and pareto scaling.
The variable importance in the projection (VIP) value of each variable in the PLS-DA model was calculated to indicate its contribution to the classification. Metabolites with the VIP value >1 were further applied to Student's t-test at univariate level to measure the significance of each metabolite, with results adjusted for multiple testing using the Benjamini-Hochberg procedure with the critical false discovery rate (FDR) set to 0. 05. The heat plot of metabolites was gained by Multi Experiment Viewer (MeV) software 4. 9. 0 after unit variance scaling for each metabolite.
Bioinformatics analysis and biomarker identification Analyses were conducted in three separate settings. In setting 1, we compared the metabolic phenotypes of DT-MDD and DN-MDD, and analyzed the perturbed pathways in DN-MDD vs. HCs to explore the underlying pathophysiology of depression in children and adolescents. Ingenuity Pathway Analysis (IPA, http://www. ingenuity. com) software and MetaboAnalyst were used to perform biological function analysis. In setting 2, analysis of significant metabolites between DN-MDD and HCs were performed to identify potential diagnostic biomarkers. Two methods were used: (1) A stepwise binary logistic-regression model was used for the multivariate analysis  [22] ; (2) A receiver-operating characteristic curve (ROC) analysis was carried out to quantify the diagnostic performance of individual metabolites  [23] , and the value of area under the ROC curve (AUC) was calculated.
(B) Positions of the Npa1p cross-linking sites (CLS 1-5b) on the rRNA 3D structure of the state C nucleolar pre-60S particle (  [11] ; pdb code: 6EM1). 25S and 5. 8S rRNAs are represented in pale blue and yellow, respectively. Rpl3 is shown in magenta. Root helices 1 (R1) and 6 (R6) are represented by a black (25S) and yellow (5. 8S) helix (R1), and by a green helix (R6). https://doi. org/10. 1371/journal. pgen. 1007597. g008 Npa1p was also found cross-linked to two sites within ITS2 (Fig  9A ). In the proposed "ringpin" model of ITS2 secondary structure  [7] , Npa1p is positioned at the base and in the central region of the hairpin structure (Fig 9A ), where no AF binding had so far been reported.
Deep-sequencing and bio-informatics analyses To build the cDNA library, 5' adapters are linked at the 5' end (BY4742: 5'-invddT-ACACr GrArCrGrCrUrCrUrUrCrCrGrArUrCrUrNrNrNrUrArArGrC-OH-3'; NPA1-HTP: 5'-invddT-ACACrGrArCrGrCrUrCrUrUrCrCrGrArUrCrUrNrNrNrArUrUrArGrC-OH-3'), and a 3' linker (5'-AppTGGAATTCTCGGGTGCCAAG/ddC/-3') is added at the 3' end. Samples are analysed by Illumina sequencing using HiSeq. Barcodes, adapters and low quality reads are eliminated using Flexbar (http://sourceforge. net/projects/flexbar/). Remaining reads are aligned to the yeast genome using Novoalign (http://www. novocraft. com). Downstream analyses including the pileups are performed using the pyCRAC tool suite (http:// sandergranneman. bio. ed. ac. uk/Granneman_Lab/pyCRAC_software. html). Hits repartition per million of sequences are produced using pyReadCounter.
py-m 1000000 option. Different pileups of hits for each gene are obtained using pyPileup. py-L 50-limit = 100000 options. NGS analysis files of raw and processed data were deposited in Gene Expression Omnibus database under the accession number GEO: GSE104281. In addition, the NPA1-HTP CRAC data displayed in the UCSC genome browser can be accessed via the following URL: https://genome. ucsc. edu/cgi-bin/hgTracks?db=sacCer3&lastVirtModeType=default&lastVirtModeExtraState= &virtModeType=default&virtMode=0&nonVirtPosition=&position=chrXII%3A460923% 2D466869&hgsid=642906575_AycMTIJwrsUKtASq0SLaYLJEWCOF.
Acknowledgments We thank  ChloeGuillon  for help with immunoprecipitation experiments,  Marlène Faubladier  for construction of yeast strains,  Stephanie Balor  and  Vanessa Soldan  ( METI platform, Toulouse ) for technical support in electron microscopy. We are grateful to  Carine Froment  and  Odile Schiltz  ( Infrastructure Proteomique de Toulouse ) for mass spectrometry analysis, to  Sander Granneman  for sharing results prior to publication and to  Jesus de la Cruz  and members of our team for helpful discussions.