dataesr/scientific-paragraphs-categorization huggingface dataset:
For example, the Simulation Experiment Description Language (SED-ML; (11)), the COMBINE archive format (12), the Kinetic Simulation Algorithm Ontology (KiSAO; (13)) and the JWS Online repository (14) can be used to share kinetic simulations. Despite this progress, sharing, reusing, and combining simulations remains difficult. One reason is that it is difficult to find, obtain, and use appropriate tools for particular systems and scales. For example, many tools do not provide clear documentation about their simulation methods, and each tool must be obtained from a different location, installed via a different process, and executed via a different UI or API using different model formats. Guides, such as the retired SBML Software Guide, and container registries, such as BioContainers, have only addressed some of these issues.
To accelerate the reuse of simulations, as well as the development of multiscale simulations, we developed BioSimulators, a central registry for the capabilities of simulation tools (e. g. supported model formats, modeling frameworks, and simulation algorithms) and consistent Python, commandline, and containerized interfaces to these tools. Currently, BioSimulators encompasses 54 tools for 13 model formats, 14 modeling frameworks, and 91 simulation algorithms (Supplementary Tables  S1-S3 ), and consistent interfaces to 21 of these tools (Supplementary Tables  S4  and S5 ). For example, this includes asynchronous logical simulation with BoolNet, geometric flux balance analysis with COBRApy, discrete particle-based simulation with BioNet-Nucleic Acids Research, 2022 3 Figure  1. BioSimulators simplifies simulation by abstracting simulation projects and simulation tools.
Streamlined discovery of appropriate tools for projects To help investigators find appropriate tools, BioSimulators provides a central database of the capabilities of simulation tools. This includes the model formats, modeling frameworks, simulation algorithms, and observables that each tool supports; the parameters of each algorithm; and the data type of each parameter, as well as metadata, such as the license of each tool. Where possible, this information is captured using ontologies such as EDAM, KiSAO, SBO and SIO. This ensures that simulation tools are described consistently. To further help investigators find tools, we have also used the capabilities of each tool and relationships among algorithms captured by KiSAO to develop recommendation services. For example, we have developed a web form that can recommend simulators for executing particular projects.
Streamlined acquisition and installation of simulators To make it easier to obtain and install simulation tools, BioSimulators saves a Docker image for each version of each containerized tool. This ensures that investigators can use a single program, such as Docker Desktop, to easily obtain and install any version of any tool. To ensure that investigators can use these images in high-performance computing (HPC) environments, which generally disallow the use of Docker due to security limitations, BioSimulators tests that these images are compatible with the Singularity Image Format (SIF), which can be run in HPC environments. Similarly, the Python APIs and command-line programs for simulation tools can be installed consistently from the PyPI repository.
Consistent representation of simulation projects and tools The foundation of BioSimulators is a set of formats, ontologies, and specifications for consistent representation of simulation projects (one or more simulations of one or more models using one or more algorithms), the inputs (e. g. experimental data for validating simulations) and outputs (data sets and visualizations of simulation results) of simulation projects, simulation tools and the capabilities of simulation tools (supported formats, frameworks and algorithms) (Supplementary Figures  S1  and S2 ). Where possible, these conventions embrace existing resources. Using these resources required filling numerous gaps within and between them. This included creating new schemas for simulation results, logs of the execution of simulations, and the capabilities of simulation tools; formalizing numerous aspects of SED-ML; adding many new ontology concepts for formats and algorithms; and correcting hundreds of bugs in various simulation projects and software tools.
We use the PDF format to capture visualizations of simulation results. To enable modelers to execute simulators consistently, we developed specifications for Python APIs and containerized command-line programs for simulators. To help investigators find specific tools for particular projects, we developed a schema for capturing the capabilities of simulation tools. This schema uses the EDAM, SBO, KiSAO, SIO, and other ontologies to capture the model formats, modeling frameworks, simulation algorithms, and simulation observables that each tool supports. We similarly helped expand these ontologies to better capture the capabilities of a broader range of tools. More information about these conventions is available in Section S2 and at https://docs. biosimulations. org.
Standardized interfaces to simulation tools We developed most of the Python, command-line, and containerized interfaces to simulation tools by wrapping simulation tools, such as COBRApy and COPASI, with BioSimulators-utils, a library that we developed for orchestrating the execution of COMBINE archives. Briefly, BioSimulators-utils executes each simulation task in each SED-ML file in a COMBINE archive by (i) resolving the model for the task, (ii) modifying the model according to the changes specified in SED-ML, (iii) using KiSAO to determine the most similar simulation algorithm that the simulation tool implements to the algorithm specified for the task, (iv) translating this algorithm and its specified parameters into the corresponding method of the simulation tool and its arguments, (v) executing this method with these arguments, (vi) collecting the results of this method and (vii) using these results to generate the reports and plots specified in the SED-ML files.
Recommendations of algorithms and simulation tools To help investigators navigate the sea of simulation formats, methods, and tools, we developed several interfaces for recommending resources, including (a) an interactive table for searching our registry of tools; (b) a web form for obtaining a list of tools which implement algorithms similar to a given algorithm, sorted by the maximal similarity of their algorithms to the given algorithm and (c) a web form for identifying simulators which can execute a given project using the specified or similar algorithms. Briefly, we implemented these services by (a) determining the formats and algorithms specified for a given project, (b) using our registry to determine the capabilities of each tool, (c) using parent-child and other relationships to encode similarities among algorithms into KiSAO, (d) using these relationships to query KiSAO for sets of similar algorithms, (e) manually assigning each set a degree of similarity, (f) combining the formats and algorithms required for a given project, the capabilities of each tool, and the similarity among algorithms to determine the maximal degree of similarity at which each tool can execute a given project and (g) sorting the tools by this maximal similarity.
Validation of simulation projects and tools To ensure that BioSimulators' conventions are used consistently and to quickly alert users to issues, we developed a tool for integrated validation of COMBINE archives (model, SED-ML, and metadata files) and tools for validating simulation results, logs of the execution of simulations, and the capabilities of simulators described with the new schemas outlined above. This included developing the first validation rules for SED-ML. For example, our tool for validating simulation projects checks that each SED-ML file is consistent with the SED-ML schema and that each observable of each simulation references a valid model variable. To make these validation tools easy to use, we developed several interfaces, including web forms, a REST API, a command-line program, and a Python API.
DESIGN, IMPLEMENTATION AND DEPLOYMENT BioSimulators is composed of a set of conventions for consistently representing simulation projects and simula-tion tools; a set of tools for validating whether simulation projects and tools are consistent with these conventions; a collection of standardized Python APIs, command-line interfaces, and Docker images for simulation tools; a Docker image repository for these tools; a database for their specifications; a REST API for updating and querying this image repository and database; and a graphical user interface for browsing the database, validating projects, and getting recommendations for algorithms and tools (Supplementary Figure  S3 ). The interfaces for simulators and the tools for validating simulation projects and simulators were primarily implemented with Python using libraries such as jlib-SEDML, libCellML, libCOMBINE, libOmexMeta, libS-BML, libSEDML, pyBioNetGen, pyNeuroML, RBApy, Smoldyn and XPP.
The containerized interfaces for simulators were developed using Docker. The tools for validating logs of the execution of simulation projects and the specifications of simulation tools, the database of simulation tools, the REST API to the database, and the web application were implemented in TypeScript using NestJS, Mon-goDB and Angular. The database, API, web application, and test suite for simulation tools are deployed using Mongo Atlas, Google Cloud, Netlify and GitHub, respectively. The containerized simulation tools are stored using GitHub Container Registry. More information about the architecture, implementation and deployment of BioSimulators is available in Section S6.
Multiscale simulation with multiple algorithms and tools By providing consistent Python APIs for simulation tools, we believe that BioSimulators makes it easier to combine multiple simulations of various subsystems and scales into multiscale simulations. In particular, BioSimulators makes it easier to combine simulations that require multiple model formats, simulation algorithms, and simulation tools. For example, the Vivarium Collective (  16 ) has begun to develop capabilities for co-simulating multiple BioSimulators tools.
The success of correctly identifying all the components of a nonlinear mixed-effects model is far from straightforward: it is a question of finding the best structural model, determining the type of relationship between covariates and individual parameters, detecting possible correlations between random effects, or also modeling residual errors. We present the SAMBA (Stochastic Approximation for Model Building Algorithm) procedure and show how this algorithm can be used to speed up this process of model building by identifying at each step how best to improve some of the model components. The principle of this algorithm basically consists in 'learning something' about the 'best model', even when a 'poor model' is used to fit the data. A comparison study of the SAMBA procedure with SCM and COSSAC show similar performances on several real data examples but with a much-reduced computing time.
In the implemented version of package Rsmlx, we limit the size of the block-structure that can be considered at each iteration. For M 1 , no correlation can be added and a diagonal matrix is used for Ω ; for M 2 only blocks of size two are considered. At iteration k for selection of model M CORR k+1 , block size cannot be larger than k + 1, leading to no more than (k -1)k/2 non-zero covariance terms in Ω. The error model selection M ERR k+1. For a given set of simulated individual parameters (ψ (k) i , 1 ≤ i ≤ N ), the residual errors can easily be computed: e (k) ij = y ij -f (t ij , ψ (k) i ), 1 ≤ i ≤ N , 1 ≤ j ≤ n i. We then fit several error models with standard deviation of the form g(t ij , ψ (k) i , ξ) for e (k) ij and select the one minimizing a penalized criterion: M ERR k+1 = argmin M min ξ -2 log L M (ξ; e (k) ij ) ) + pen ERR (M.
We denote n ξ the length of ξ, i. e. the number of parameters in model M. The penalization depends on the criterion selected for global optimization: if AIC then pen ERR (M) = 2n ξ , if BIC then pen ERR (M) = log(N )n ξ , and if BICc then pen(M) = log(n tot )n ξ where n tot is the total number of observations, including below the limit of quantification (BLQ) data. In the implemented version of package Rsmlx, five error models (provided by function g in Equation (1)) are tested by default: constant (g x (t ij , ψ (k) i , ξ) = ξ), proportional (g x (t ij , ψ (k) i , ξ) = ξf (t ij , ψ i )), combined 1 (g x (t ij , ψ (k) i , ξ) = ξ 1 + ξ 2 f (t ij , ψ i )), combined 2 (g x (t ij , ψ (k) i , ξ) = ξ 2 1 + ξ 2 2 f (t ij , ψ i )) or exponential in which a constant error model is fitted to the log(y) using the transformation u = log in Equation 1.
Results Step-by-step example of the SAMBA procedure To illustrate how SAMBA works in practice, we will describe step-by-step the complete procedure on the example of remifentanil  [18]. We use here the SAMBA implementation in function buildmlx of the R package Rsmlx, using the default settings. SAMBA iterations. We start the SAMBA procedure with a model M 0 without any covariate on all parameters, with no correlation between random effects and the so-called combined 1 error model. Figure  2  illustrates the selection steps on this specific example. One can notice that the BICc, which has been chosen as target criterion, decreases from 7186 for M 0 , to 6985 for M 1 , 6957 for M 2 , and 6903 for M 3 , which is finally selected as the best model for this example. -Run 0 (BICc=7185. These covariate, correlation and error models are then passed on to run 1: M 1 = {{M COV,Cl 1 , M COV,Q2 1 , M COV,Q3 1 , M COV,V 1 1 , M COV,V 2 1 , M COV,V 3 1 }, M CORR 1 , M ERR 1 }).
Performances on real examples, comparison with the SCM and COS-SAC procedures To assess the performances of the SAMBA procedure compared to SCM and COSSAC procedures, we replicate the illustration provided in  [2]. We applied the three routines to a collection of 10 representative datasets, including pharmacokinetics, pharmacodynamics, and disease models. Of note, the SCM method for variable selection used here is exactly the same as the one implemented in PsN (Pearl Speaks NONMEM), differences lie in the algorithms used to estimate the parameters of a model and to calculate the likelihood. We restricted the SAMBA procedure to the covariate model selection as correlation and error model selection are not implemented in COSSAC and SCM. The results can be found in We insist on the fact that a difference in BICc does not necessarily have any biological meaning.
This is an arbitrary criterion that allows to quantify the goodness of fit with respect to the sparsity of the model chosen. We thus argue that the three procedures lead to rather similar models which all constitute very good starting points for the modeler to build a model based on biological hypothesis. Finally, in only one example discussed below, the difference in BICc was larger than 10 points of BICc both compared to SCM and COSSAC procedures. Regarding the Cholesterol dataset, we run again the SAMBA procedure starting from a full model in which all covariates are supposed to have an effect on all parameters. The new model selected by SAMBA is the full model with an effect of logAGE on (Chol0, slope) and SEX on (Chol0, slope) is much closer in term of BICc than the one selected starting from an empty model (∆BICc =-2).
What is of interest here is the convergence of SAMBA. As it is also the case for SCM and COSSAC, SAMBA may not converge to the global minimum. This is particularly the case when the amount of data is too small compared to the complexity of the model to build. This phenomenon will be particularly critical when the number of covariates is high and/or when these are highly correlated. We then strongly encourage the user to build strategies to assess the robustness of the results. Extensions of the proposed algorithm are possible but are outside the scope of this paper and constitute a possible new research direction. When there is a large number of available covariates, COSSAC and mainly SCM often fail in finding the best model in a reasonable time. In this case, SAMBA represents a particularly appealing approach since the covariate model selection is based on a stepwise variable selection procedure for linear models, which is known to handle high-dimension problems.
The SAMBA procedure is implemented the R Package Rsmlx in the function buildmlx  [15]. Minimal required input is a Monolix project used as initial model. Additional arguments can be used to enable specific features (all not listed): select the components of the model to optimize between the covariate, correlation, and error model, restrict the number of parameters or covariates to use, select a specific objective criterion, etc. Rsmlx is on CRAN and the R code can be modified to investigate any of the alternative implementations mentioned above for a specific problem. Note that the execution of Rsmlx requires the Monolix software, since it is only an algorithm combining tasks implemented in Monolix. The R codes allowing to replicate the analyses of this article are available in supplementary material.
All the illustration datasets can be downloaded from the Supporting Information Appendix S2 of  [2]. Finally, the SAMBA procedure is also implemented in the Monolix-GUI software starting procedures while keeping the same performances. We also show that it is possible to perform correlation and error model selection in nonlinear mixed-effects models. How might this change clinical pharmacology or translational science? This method will allow the practitioner to very quickly find a set of very good models in term of data fitting and parsimony, even when the number of parameters or the number of covariates available is large.
Because the datasets are real data illustrations, there is no "true" model. It is only possible to compare them in term of BIC. Out of 10 examples, the same best model was proposed by the three procedures in four examples. In two examples, the best model selected by SAMBA was better in term of BICc than with SCM and COSSAC (Theophylline Ext. Rel. and Warfarin PK/PD). In three other examples the model with lowest BICc was not selected by SAMBA. However, the difference in BICc was respectively smaller than 6 in comparison with SCM procedure and 4. 2 in comparison with COSSAC procedure.
The remifentanil data. The dataset is composed of 65 healthy adults who have received remifentanil IV infusion at a constant infusion rate between 1 and 8 µg. kg -1. min -  for 4 to 20 minutes. Time and rate of infusion are known for each individual. The phar- macokinetics data consists in the plasma concentration of remifentanil, which is mea- sured during and after infusion for a total of 19 to 53 observations by patients, totalling 2057 observations. A total of 6 covariates are available: one qualitative covariate, the sex (SEX) and five continuous covariates: the age (AGE), the height (HT), the weight (WT), the lean body mass (LBM) and the body surface area (BSA). All the latter are normalized and log-transformed for the analysis. In the following, we adopt the notation logAGE = log(AGE/AGE pop ), where AGE pop is a typical value to normalize on, e.
(B) 3D representation of the RMSF, as a measure of the protein flexibility of the main chain atoms (see also Supplementary Figure  S1  for a 2D representation of the RMSF). The position of the deletion of the 31-33 residues is highlighted, the other mutations are shown in CPK. The RMSF follows a color code from blue (less flexible) to red (most flexible), note, in wt, BA4 and BA5 variants, the modifications of the fluctuations of the α-helix close to the R203K, S204R mutations located in close vicinity to the basic finger. These data highlight short-and long-range effects of the mutations on the protein flexibility, with a large enhancement in BA5 only missing the P151S mutation as compared to BA4 that may increase replication in the former variant. Associated with these changes in the cavity, we measured the protein flexibility of the three proteins, estimated by the root mean square fluctuations (RMSF).
The FL was then tested by DLS for its ability to bind RNA (TAR-polyA). The size of the native protein with bacterial nucleic acids contamination was 14. 5 ± 1. 0 nm in volume (data not shown). As shown in Figure  1D , the size of the protein depleted from nucleic acids contaminants was 12. 0 ± 0. 4 nm in volume (14. 0 ± 0. 3 nm in intensity) that increased to 15. 1 ± 0. 3 nm (20. 3 ± 0. 3 nm in intensity) upon addition of RNA (Figure  1D ), showing that the protein is functional. By comparison, the size of the NTD monomeric protein was 6. 0 ± 0. 3 nm and increased to 15. 7 ± 0. 5 nm in intensity in the presence of nucleic acids. The size of NTD could not be fitted by a spherical model to obtain its value in volume. To further characterize FL protein, the apparent melting temperature (Tm) of the protein alone was determined by DLS as a function of temperature.
Virtual Drug Screening on NTD and FL We performed virtual screening to identify ligands binding to the large C-terminal cavity of the full-length protein (Figure  2A ) using the data base of the Sigma-Aldrich catalog. We also screened for ligands binding to NTD. We first used the Libdock software of Discovery studio. Then, docking of the interesting hits was further repeated using CDocker. Finally, MD simulations were performed on the best hits. Tables  1  and 2  summarize the mean-full hits both in terms of docking and biological function.
Materials and Methods A computational model of the full-length nucleoprotein of SARS-CoV-2 was generated with the ColabFold  [59]  version of AlphaFold 2  [27]  using an API hosted at the Södinglab based on the MMseqs2 server  [60]  for the multiple sequence alignment creation. 300 sequences were aligned on uniprot entry A0A6C0T6Z7 as query sequence and no template (419 residues). Predicted lDDT is highest in the NTD and CTD regions that were previously determined by experimental methods (PDB entries 7act, 6wzo). MD simulations were performed based on Alphafold and initial minimization and equilibration steps for 21 ns in implicit solvent. The wt protein was prepared with Discovery Studio 2022 (Dassault Systèmes BIOVIA, Discovery Studio Modeling Environment, Release 2022, (San Diego, CA, USA): Dassault Systèmes 2022) the models were first protonated at pH 7.
Ligand Screening and Docking to wt N In silico screening of ligands that bind the protein structures was performed using the Sigma catalog data base and assessed in a two-step protocol. For this screening, we first used the docking program Libdock of Discovery Studio version 2021, with the exclusion of ligands with molecular weights above 2000 and according to the binding site(s) defined by cavity detection. A site-docking was then performed using Cdocker with energy minimization (Discovery Studio version 2021) to more precisely identify the ligand binding mode. For each protein, the most representative pose of the ligand was selected. The resulting protein-ligand complexes were finally refined by a molecular dynamics simulation using the CHARMm force field  [63]  and the standard dynamic cascade protocol of Discovery studio version 2021.
Acknowledgments: The authors are grateful to HO Bertrand from Biovia for the gift of a temporary license for Discovery Studio (Dassault Systemes). We thank N. Griffete and C. Menager from the Phenix Laboratory for the use of their Malvern DLS apparatus. We are grateful to the structural biology facility (UMS 3033/US001) of the Institut Européen de Chimie et Biologie (Pessac, France) for using the Biacore T200 instrument in SPR experiments. We thank the following colleagues for their support in the initial stages of the CoVNucleovir project: Bruno Fève, Michèle Sabbah, Vincent Maréchal and Francis Berenbaum, from CRSA, Sorbonne Université, Olivier Terrier, Rosa Calavatra, B. Lina, Virpath, Lyon University and the team of Evzen Boura, the Czech Republic.