dataesr/scientific-paragraphs-categorization huggingface dataset:
Deconvolution methods We implemented an R package, immunedeconv, that provides a unified interface to all seven deconvolution methods compared in this paper. The CIBERSORT R source code was obtained from their website on 2018-03-26. The xCell, EPIC, MCP-counter, TIMER and quanTIseq source codes were obtained from GitHub from the following commits: dviraran/xCell@870ddc39, GfellerLab/EPIC@e5ae8803, ebecht/MCPcounter@e7c379b4, hanfeisun/TIMER@a030bac73, FFinotello/quan-TIseq@ee9f4036. We ran CIBERSORT with disabled quantile normalization, as recommended on their website for RNA-seq data. While quanTIseq provides an entire pipeline, starting with read-mapping and estimation of gene expression, we only ran the last part of that pipeline, which estimates the immune cell fractions from gene expression data.
We ran TIMER with "OV" on ovarian cancer ascites samples and with "SKCM" on melanoma samples. We ran quanTIseq with the option tumor = TRUE on all tumor samples and tumor = FALSE on the PBMC samples. We ran EPIC with the TRef signature set on all tumor samples and with BRef on the PBMC samples. We ran xCell with the cell. types. use parameter to avoid overcompensation by the spillover correction. For simulated tumor data, cell. types. use was set to B, CAF, DC, Endo, Mac/Mono, NK, T CD4+ n. r. , T CD8+, T reg. For the validation datasets, it was set to B, DC, Mono, NK, T CD4+, T CD8+, T. We disabled the mRNA scaling options of quanTIseq and EPIC for the single cell simulation benchmark using the mRNAscale and mRNA_cell options, respectively. Notably, this only has an effect on the absolute values, but not on the correlations used to compare all methods.
Simulation benchmark We simulated bulk RNA-seq samples by calculating the average gene expression per gene of cells sampled from the single cell dataset. Independently for each sample, 500 cells were randomly selected as follows: (1) A fraction f of cancer cells was drawn from N (0. 33, 0. 3), which is the empirical distribution of cancer cells in the melanoma and ascites samples in the single cell dataset. f was constrained to the interval [0, 0. 99]. (2) Half of the samples use melanoma cancer cells, the other half ovarian cancer cells (3) The remaining fraction 1 -f was randomly assigned to immune cells, resulting in a fraction vector. (4) The fraction vector was multiplied with 500 to obtain a cell count vector. (5) The corresponding number of cells was drawn with replacement from the single cell dataset.
Minimal detection fraction and background prediction levels We simulated bulk RNA-seq samples as follows: For each cell type c, we create five independent samples for each i ∈ {0, 5, 10,. , 50, 60,. , 100, 120,. , 300, 350,. , 500}. For each sample independently, we randomly sampled i cells of type c and a background of 1000 cells containing all cell types except c from the single cell dataset. The selected cells were aggregated by calculating the arithmetic mean for each gene. This results in five batches of 300 samples each (30 spike-in levels × 10 cell types). Each of the five batches was submitted to the methods independently in a single run. We quantify the background prediction level of cell type c as the predicted score of c in samples of type c with i = 0, i. e. in samples with no cells of type c present.
Spillover We refer to spillover as the erroneous prediction of another cell type due to a partial overlap of the signatures. We measured spillover on two datasets: (1) 44 true bulk RNA-seq samples of pure immune cells (supplementary table  3 ). (  2 ) 45 simulated bulk RNA-seq samples of nine cell types. For each cell type c, we simulated five samples by independently aggregating 500 random cells of type c by taking the arithmetic mean. Each dataset was submitted to the methods independently in a single run. We visualized the results as chord diagrams (figure  3 ) using the R package circlize  (Gu et al. (2014) ).
Schelker's and Racle's dataset have too few samples to be considered individually. The values indicate Pearson correlation of the predictions with the cell type fractions determined using FACS. Blank squares indicate that the method does not provide a signature for the respective cell type. 'n/a' values indicate that no correlation could be computed because all predictions were zero. The asterisk (*) indicates that the 'monocytic lineage' signature was used as a surrogate to predict monocyte content. P-values: **** < 0. 0001; *** < 0. 001; ** < 0. 01; * < 0. 05; ns ≥ 0. 05. P-values are not adjusted for multiple testing. Method abbreviations: see table 1.
Conclusion We have presented in this paper a novel finite volume scheme of Godunov-type for SP model. The solver is based on a four-wave approximation of Riemann problem. This can be seen as an augmented HLLC scheme which is well-balanced, positivity preserving and shock capturing. Details on practical implementation of the scheme were also discussed. Next, a first application to modelling interactions between rigid vegetation with the flow in a laboratory flume was performed. Good agreement was found both with experimental data and the result provided by an explicit simulation with SW model. Experimental data were provided by the FlowRes project, supported by the French National Research Agency (ANR) under the grant N o ANR14-CE003-0010.
Boolean and multi-valued logical formalisms are increasingly used to model complex cellular networks. To ease the development and analysis of logical models, a series of software tools have been proposed, often with specific assets. However, combining these tools typically implies a series of cumbersome software installation and model conversion steps. In this respect, the CoLoMoTo Interactive Notebook provides a joint distribution of several logical modeling software tools, along with an interactive web Python interface easing the chaining of complementary analyses. Our computational workflow combines (1) the importation of a GINsim model and its display, (2) its format conversion using the Java library BioLQM, (3) the formal prediction of mutations using the OCaml software Pint, (4) the model checking using the C++ software NuSMV, (5) quantitative stochastic simulations using the C++ software MaBoSS, and (6) the visualization of results using the Python library matplotlib.
, 2017; Paulevé, 2017; Stoll et al. , 2017). The CoLoMoTo Interactive Notebook 1  (Naldi et al. , 2018b ) relies on Docker 2 and Jupyter 3 technologies to assist on editing and sharing reproducible analysis workflows for logical models. In addition to the distribution of a set of software tools to define and analyse Boolean and multi-valued networks, a unified Python interface for each of the integrated tools is provided, greatly easing the execution and chaining of complementary analyses. This protocol describes in details the usage of the CoLoMoTo Interactive Notebook to provide a reproducible analysis of a recently published model of the signaling network controlling tumor cell invasion and migration. More specifically, we combine different tools (Table  1 ) to compute the model stable states, perform stochastic simulations, compute (sets of) mutations controlling the reachability of specific stable states, and evaluate their efficiency.
Executable and Reproducible Model Analysis This protocol has been actually edited entirely as a Jupyter notebook before being converted to a LaTeX document for journal-specific editing purposes. The original notebook file is provided as Supplemental Material. It can also be visualized and downloaded for execution in the CoLoMoTo Interactive Notebook at https://nbviewer. jupyter. org/gist/pauleve/a86717b0ae8750440dd 589f778db428f/Usecase%20-%20Mutations%20enabling%20 tumour%20invasion. ipynb. The blocks beginning with In [. ] correspond to Jupyter code cells, which contain the Python instructions to execute. 1 Available at http://colomoto. org/notebook 2 https://docker. com 3 https://jupyter. org When relevant, the blocks beginning with Out [. ] display the result of the last instruction of the corresponding code cell.
Provided Docker and Python are installed, the CoLoMoTo Interactive notebook can be installed by typing and executing the following command 4  on GNU/Linux, macOS, and Microsoft Windows: pip install -U colomoto-docker Once installed, the notebook can be executed by typing colomoto-docker -V 2018-05-29 The execution of this command will open a web page with the Jupyter notebook interface, enabling the loading and execution of the code. Note that "SHIFT+ENTER" must be used to execute each code cell. More information on colomoto-docker usage can be obtained by typing colomoto-docker --help and by visiting https://github. com/colomoto/colomoto-docker.
Identification of Stable States First, we compute the complete list of logical stable states (or fixpoints) of the model using the Java library bioLQM  (Naldi, 2018). We thus need to convert the GINsim model into bioLQM: In [4]: lqm = ginsim. to_biolqm(lrg) At that stage, lrg is a Python object representing the model suitable for GINsim, and lqm is a Python object representing the equivalent model suitable for bioLQM. The list of stable states of a bioLQM model is computed as follows: In [5]: fixpoints = biolqm. fixpoints(lqm) Here, fixpoints is a Python list of states. A state is encoded as a Python association table (dictionary), which maps each node of the network to a value. For a nice display of the list of stable states, one can use the tabulate function provided in the colomoto_jupyter Python library, imported at the beginning of the notebook: In [6]: tabulate(fixpoints) Figure  2  shows the table as displayed in the notebook.
Assessing the Probabilities to Reach Alternative Attractors Using MaBoSS MaBoSS  (Stoll et al. , 2017)  is a C++ software enabling the stochastic simulation of Boolean networks by translating them into continuous time Markov processes. Each node activation and inactivation is associated with an up and a down rate, which specify the propensity of the corresponding transitions. From a given state, the simulation integrates all the possible node updates and derives a probability and a duration for each transition. By default, all transitions are assigned the same rate. For a given set of initial conditions, MaBoSS produces time trajectories and estimates probabilities of model states over the whole simulation time. Steady state distributions can thus be approximated, provided that a sufficient number of sufficiently long simulations have been performed.
The aim of this section is to reproduce part of the results obtained by  Cohen et al. (2015) , which show that a Notch (NICD) gain-of-function together with a p53 loss-of-function prevent reaching a stable apoptotic phenotype. First, we convert the bioLQM model to MaBoSS: In [8]: wt_sim = biolqm. to_maboss(lqm) The variable wt_sim is a Python object that gathers both the Boolean network rules and the settings for the simulations, including the transition rates.
Initial states First, a distribution of initial states must be specified: each simulation then starts from a state sampled from this distribution. The distribution is determined by assigning a probability to start in state 0 or in state 1 to each node. By default, a node has a probability 1 to start in state 0. The maboss Python library provides widgets to ease the assignment of this initial distribution. The following code enables the definition of a distribution of initial states with all nodes at 0, except DNAdamage and ECMicroenv with equiprobable 0 and 1 values. After pressing "OK, " the notebook cell will be replaced by the actual Python call resulting in equal probabilities for these two nodes to start in active or inactive states. In [9]: maboss. wg_set_istate(wt_sim) The notebook will then display the widgets reproduced in Figure  4.
Simulation of the Wild-Type Model The object wt_sim represents the input of MaBoSS, encompassing both the network and simulation parameters. The simulations are triggered with the. run() method and return a Python object for accessing the results. In  [12] : %time wt_results = wt_sim. run() CPU times: user 4. 61 ms, sys: 406 s, total: 5. 02 ms Wall time: 2. 89 s The resulting object gives access to the output data generated by MaBoSS. It includes notably the mean probability over time for the activity of the output states integrated over all the performed simulations. The function plot_piechart displays proportionally the mean probability of each output state at the last time point. Provided the simulation time has been set high enough, this gives an approximation of the probabilities of the stable states reachable from the specified initial conditions.
Formal Analysis With Pint and NuSMV In the above section, the conclusion regarding the loss of apoptotic stable state relies on stochastic simulations, which, in general, may not offer a complete coverage of the possible trajectories. Therefore, one may want to formally verify whether the loss of reachable stable apoptosis state is total or not. First, we show how to use Pint  (Paulevé, 2017)  to predict combinations of mutations which are guaranteed to prevent the activation of apoptosis. Next, we use the software NuSMV  (Cimatti et al. , 2002)  to evaluate formally the Notch++/p53--  double mutant. Finally, we use MaBoSS to assess the efficiency of new combinations of mutations predicted by Pint.
Revisiting the Notch++/p53--Double Mutant We will first formally analyse the Notch++/p53--double mutant to show that asymptotic apoptosis is forbidden, although transient activation of apoptosis node might still be possible. One can apply a mutation on a Pint model using the lock method. A new model is returned with a constant value for the corresponding nodes. In  [21] : mut_an = an. lock(NICD=1, p53=0) Then, we use the temporal logic CTL  (Clarke and Emerson, 1982)  to specify formally the dynamical properties to verify. CTL expression can be built using the colomoto. temporal_logics Python module. In  [22] : from colomoto. temporal_logics import * First, the existence of a trajectory leading to a transient state where Apoptosis is active can be specified as follows: In [23]: transient_apoptosis = EF(S(Apoptosis=1)) EF is a temporal logic operator that is true if there exists at least one trajectory leading to a state verifying the properties given as argument.
Here the property S(Apoptosis=1) specifies that the state has the node Apoptosis active. Next, the existence of a trajectory leading to a stable Apoptosis activation can be specified as follows: In [24]: stable_apoptosis = EF(AG(S(Apoptosis=1))) Here, AG enforces that all the states reachable via any trajectory have the node Apoptosis active. Finally, we gather these two properties in a Python dictionary for later use: In  [25] : ctl_specs = { "reach-apoptosis": transient_apoptosis, "stable-apoptosis": stable_apoptosis } The adequation of a model with a CTL property can be assessed using a model-checker such as NuSMV  (Abou-Jaoudé et al. , 2015). Pint provides a conversion to NuSMV models. By default, the NuSMV model considers any initial state. With the skip_init=False option, we enforce that the properties are verified only from the initial states defined earlier.
We show here how we can take advantage of the Python environment to provide a small program, which, for each subset of mutations of a multiple mutant (here a triple gain-offunction for SNAI2, ZEB1 and miR203), performs stochastic simulations with MaBoSS to assess the probabilities to reach the different stable behaviors from the specified set of states. The computation can take a couple of minutes. The results are shown in a graphical form (colored pie charts) for each single and double loss-of-function combination. In the pie charts, "Others" regroup states with an individual probability less than 1%, which often correspond to simulated trajectories having not reached an attractor in the given amount of time. The resulting graphics are reproduced in Figures  8 9 10 11 12 13. Note that only one of the pie charts shows an absence of apoptotic state: the SNAI2++/miR203++ double mutant (Figure  13 ).
ANTICIPATED RESULTS With this protocol, we showed how the Python interface and Jupyter integration of GINsim, bioLQM, MaBoSS, and Pint ease     the delineation of sophisticated re-executable computational analyses of qualitative models of biological networks, combining and chaining different software with a unified interface. Leaning on the CoLoMoTo Docker image and on the companion Jupyter notebook, we have demonstrated the benefits of this framework by revisiting the analysis of a recent Boolean model of the signaling network controlling cancer cell metastasis. We could reproduce results previously obtained with GINsim and MaBoSS, which demonstrate that the Notch++/p53--double mutant can suppress the apoptotic outcome. Furthermore, a formal analysis of trajectories with Pint enabled us to deduce novel "anti-apoptotic" combinations of mutations, including a triple mutant that forbids even transient activation of apoptosis, which were subsequently quantified using MaBoSS.
FUNDING DT and CH acknowledge support from the  French Plan Cancer , in the context of the projects CoMET ( 2014-2017 ) and SYSTAIM (2015-2019). DT and AN acknowledge support from the  French Agence Nationale pour la Recherche (ANR) , in the context of the project  SCAPIN  [ ANR-15-CE15-0006-01 ]. AZ acknowledges support by the  Ministry of education and science of Russia  (Project No. 14. Y26. 31. 0022 ). AZ and LC acknowledge support from  ITMO Cancer , in the context of the  INVADE grant  ( Call Systems Biology 2012 ), and from the  EU ERACoSysMed programme , in the context of the  COLOSYS  project. AZ, LC, and LP acknowledge support from the  ANR  in context of the  ANR - FNR  project  AlgoReCell  [ ANR-16-CE12-0034 ]. LP acknowledge support from  Paris Ile-de-France Region (DIM RFSI)  and  Labex DigiCosme  [ ANR-11-LABEX-0045-DIGICOSME]  operated by  ANR as part of the program Investissement d'Avenir Idex Paris-Saclay  [ ANR-11-IDEX-0003-02 ].
OpenAPI  [6]  is one of them: it defines a specification to describe the HTTP APIs of web services in a language-agnostic way. It is quite famous in the industry and has a rich ecosystem of tools  2. Motivation. Building or fast-prototyping digital products can be achieved using a top-down approach. First, they design an OpenAPI model and make sure it is suitable as an interface between the different actors. Then, they can rely on this model to implement them independantly using programming languages. Some tools like Swagger Code Generator  [13]  provide support to developers in this process: they generate code based on the OpenAPI model, targeting one of the numerous supported languages and frameworks. However, because OpenAPI is language-agnostic, the generated code does not contain implementation details; developers still have to complete it in a way that respects the contract defined by the OpenAPI model, so that they obtain a working implementation.
These components can be defined in two ways: (i) by a contract and an implementation in a programming language, or (ii) in term of already defined components. Every service is linked to a component whose purpose is to generate an HTTP response. Our tool, SWSG  [10] , provides support to automatizes the topdown development process. It can read these extended models, check several properties to ensure their consistency, and generate code of working web services. On top of solving the alignment problem, this gives even more support to developers. The article is structured as follows. Section 2 describes the component system and how it is integrated in OpenAPI 3. 0. Section 3 introduces SWSG and shows how it checks models and generates code. Section 4 presents related work. Finally, Section 5 concludes the article with some lessons and future work.
GENERATING WEB SERVICES To use our extensions to OpenAPI 3. 0, we propose the following top-down development process: (1) developers write a standard OpenAPI model that fits their needs; The step (2) is made possible by our extensions and provide a transitional step between the modelling (1) and the implementation (3) in the refinement process. It simplifies the implementation (3) by reducing it to several small functions instead of a whole program. The step (4) makes use of our tool, SWSG  [10] , that follows the process shown in Figure  1. We present this tool in the following sections: Section 3. 1 focuses on the model consistency verification and Section 3. 2 on the code generation.
Code Generation The process depicted by Figure  1  is generic: it does not rely on a specific language or technology. Yet the language and technologies used to implement atomic components must be identical or compatible with those of the code generation target. Because we experiment in Startup Palace's context, the current implementation of SWSG targets the PHP programming language  4  with the Laravel web framework  5  , which is a common tool stack. The generation in itself is done with a model-to-text transformation that uses a template engine called Twirl 6. Apart from some static classes and from the implementations of atomic components (that are not altered), SWSG generated two kinds of source files: implementations of composite components and a route file. The Listing 3 shows the code generated for the FindPet component (defined in Listing 1).
Second, this allows SWSG to provide more support to users; the balance between flexibility and support is discussed in  [16]. One of the tools featured in the OpenAPI ecosystem is Swagger Code Generator  [13]. It aims at generating client librairies, server stubs or documentations from an OpenAPI model. It supports many languages and frameworks, but only helps developers to write new services by generated boilerplate code. This automatizes a tedious task; however they still need to add a lot of code on top of it. Moreover, when services evolve, developer need to manually propagate evolutions into the codebase because Swagger Code Generator isn't able to merge them automatically. Our approach solves this issue because it gives flexibility to developers before the code generation step, making useless editing generated code.
CONCLUSION We extended OpenAPI 3. 0 with a component system to describe implementations of web services from a high-level. This establishes an intermediary artifact that fits well in the top-down development process, between the abstract OpenAPI model and the concrete implementation of web services. This allows to generate an implementation of the web services that does not need manual modifications. As a consequence, alignment between the OpenAPI model and the implementation is guaranteed. Moreover, this paves the way for enhanced support features; for example, verification or interactive visualization. We also presented SWSG, a tool that can check structural consistency of extended OpenAPI models and generate code of the web services. This approach was tested on several case studies 7 , but needs more testing on bigger projects.
Methods This work takes advantage of an already existing database, based on Particulate Matter (PM 10 ) samples collected during the DECOMBIO program  (Chevrier et al. , 2016) , with the chemical analyses and the source apportionment of PM having already been conducted  (Chevrier, 2016) , and the OP measurements performed on the same samples  (Calas et al. , 2018). These are briefly presented below.