dataesr/scientific-paragraphs-categorization huggingface dataset:
In order to implement those features, we used the wellknown CGAL library  [30]. It has to be noticed that, contrary to Chaste and CompuCell3D software, CPOP does not propose to model cell population growth but represents cell populations in their final state when the cell population has reached a size and a number of cells corresponding to what is observed with microscopy. Spatial positions of each cell and organelle in the cell population are accessible in CPOP. The CPOP platform has been interfaced to the Geant4 toolkit  [31] [32] [33] [34]  in order to tackle how energy depositions are allocated to cells, especially when enhancing radiation outcomes using gold or gadolinium nanoparticles. Some authors already assessed such outcomes when simulating ceramic oxide nanoparticles under MeV proton irradiation or kilovoltage photon field  [16, 17, 35].
The simplified class diagram of the CPOP platform is presented in Fig. 2. Compilation CPOP version 2. 0 is compatible with Linux OS and gcc version 4. 8 and higher. Before compiling the CPOP platform, it is necessary to install some open-source programs and libraries. First, it is mandatory to install Qt (http://www. qt. io/), version 4. 6 or later, in order to empower Man-Machine Interface (MMI) utilities and engines. Then, it is required to install CGAL libraries version 4. 5 (http://www. cgal. org/) in order to benefit from Delaunay and Voronoi facilities to build respectively triangulation and meshes for cell populations. This installation is requiring Boost (http://www. boost. org/), MPFR (http://www. mpfr. org/) and Xerces C++ libraries (http://xerces. apache. org/, version 2. 0 or later); the latter enables XML parsing when GDML exportation of cell population geometry is performed.
In order to display any geometry built with CPOP, it is necessary to install QGLViewer, version 2. 0 or later (http://libqglviewer. com/). Then, in order to interface CPOP with Geant4 simulations (http://geant4. org), users would have to install the toolkit on their computer; the installation of Geant4 requires an external installation of CLHEP (A Class Library for High Energy Physics, http:// http://proj-clhep. web. cern. ch/, version 2. 1. 4. 1). Therefore, users may pay attention to fix the GEANT4_USE_SYSTEM_CLHEP option to ON during the Geant4 compilation and to fix the WITH_EXTERNAL_CLHEP option to ON during the CPOP compilation. Further, the ROOT Data analysis framework (https://root. cern. ch/, version 5. 34 or later) has to be installed to enable data outputs at the end of particle tracking simulations inside cell populations.
The distribution can be modified to be either random or normal. For that purpose, CPOP is based on the CLHEP HepRandom module. b. Cell population geometry A 3D power-weighted Delaunay triangulation, holding cell neighbourhood relations, is used to spatially represent cells with vertices. To enable that, the 'Delaunay' class uses the CGAL library enhancing the Dynamic Object Delaunay package. The Voronoi tessellation, created with the 'VoronoiMesh' class, is used to represent cell shapes using meshes. Each free cell (having no neighbor cell and a ratioToSta-bleLength parameter equal or higher to 1) is considered to have spherical shape with spherical radius; for cells being in conflict with others, cells are constrained like shown in Fig. 4. When neighboring cells and their radii are in conflict (ratioToStableLength parameter inferior to 1), then the radius of each cell is minimized in order to not overlap with any other geometry.
Acknowledgments This work is part of the  RACE (Radiation resistance  of cancer cells using Geant4-DNA) project supported by grants from Plan Cancer 2009-2013  French national initiative through the call for proposals "Domaine de la physique, des mathématiques ou des sciences de l'ingénieur appliqués au Cancer " managed by  INSERM  ( Institut National de la Santé et de la Recherche Médicale ) under contract  PC201320. This work was also performed within the framework of the  LABEX PRIMES  ( ANR-11-LABEX-0063 ) of  Université de Lyon  within the program " Investissements d'Avenir"  ( ANR-11-IDEX-0007 ) operated by the  French National Research Agency (ANR).
High multiplexing considerably reduces the cost of sequencing per sample. Regarding data analysis, standard RNAseq tools can be used with some adjustments related to UMI counting. To facilitate data processing in service-oriented settings, we have modi ed the de-multiplexing step to obtain one fastq and one bam le per sample. This allows us to handle several projects on the same run. This le splitting step also reduces the computation time by using the parallelization power of a HPC cluster. We have also adapted the code to allow for large projects split over several runs. We have developed a snakemake 8 pipeline including every analysis step from raw fastq de-multiplexing to functional annotation of the differentially expressed genes, producing a complete HTML report for enduser. A clear de nition of the scienti c question driving genome-wide transcriptional pro ling remains the key factor to determine the optimal experimental design.
Primary Analysis The primary analysis (Fig. 3 ) consist in generating the expression matrix containing the raw counts for each sample and for each gene, from raw sequencing data les. -Illumina basecall les are transformed into paired-end fastq les with Illumina bcl2fastq converter. -Samples are demultiplexed according to their respective barcodes described in a sample sheet to create a single-end fastq le per sample. -A step of read trimming is performed in order to remove any poly A tail, which can occur when the transposase cuts a DNA fragment in close proximity to the poly A tail. By using cutadapt on these fragments, all the bases following the poly A tails (reverse sequences of the UMI, sample barcode and illumina adapter) are also removed. -The cDNA sequences from each sample are then aligned on the reference transcriptome and the mitochondrial genomic reference sequence with BWA 5 aligner.
Secondary Analysis The secondary analysis consists in identifying the differentially expressed genes between conditions from the raw expression matrix. The pipeline is mainly written in the R programming language. -Samples and genes are ltered out of the raw expression matrix according to the parameters speci ed in the con guration le: * Samples are removed if they have less than --minReads reads assigned (default 200k) or if they have less than --minGenes genes detected (i. e. number of genes with at least 1 count) (default 5k). * Genes are removed if not detected (counts = 0) in at least the number of samples forming the smallest condition. -Counts are then normalized by DESeq2 6 method. -Differentially expressed genes are found by DESeq2. By default, genes with an adjusted p-value < 0. 05 and a log2 fold-change > 0.
Requirements Installing git and conda are mandatory before running the pipeline. All necessary tools are then listed within a conda environment recipe. This environment can be created with a basic conda command. -----$ conda env create -n srp -f CONDA/srp. yml -----Testing the installation A minimal sample size test data as well as a sample sheet are available in the "TESTDATA" folder. In order to check the installation, run the pipeline on this data. This test data is made up of six samples classi ed in three conditions (2 samples per condition). The fastq les are real reads taken on a small portion of the human chromosome 22. The reference is a fasta le of the human chromosome 22. -----$ conda activate srp # Under the srp-pipeline directory: $ python SCRIPTS/make_srp_con g. py -s TESTDATA/samplesheet.
The script used to create the con guration le is make_srp_con g. py in the SCRIPTS folder. The help can be visualized with: ----$ python SCRIPTS/make_srp_con g. py -h ---- The mandatory options are -s for the samplesheet, either -f for a le listing the fastq paths or -i for an illumina directory and -r for the directory containing the genome les for the different assemblies. It is recommended to specify a working directory where the les will be output with option -w to keep the srp-pipeline git clone clean. The program outputs a json object on stdout which can be redirected to a le. ----$ python SCRIPTS/make_srp_con g. py -s <my_samplesheet> -r <path_to_reference_folder> -w <path_to_workdir> -i <path_to_fastqs> > con g. json ----For secondary analysis, use option -c to specify the comparisons to perform.
----$ python SCRIPTS/make_srp_con g. py -s <my_samplesheet> -r <path_to_reference_folder> -w <path_to_workdir> -i <path_to_fastqs> -c <comparisons_ le> > con g. json ---- The generated con guration le should be checked to see if everything seems alright. ----$ cat con g. json ----4-the snakemake pipeline. Test the launch with a dry run: ----$ snakemake --con g conf="con g. json" -rpn ----All rules and commands that will be run should be displayed. Otherwise errors are returned. Launch the run: ----$ snakemake --con g conf="con g. json" -rp -j 1 ---- In order to launch the pipeline on a cluster, specify a script to encapsulate the jobs to snakemake. example for SGE: ----$ snakemake --con g conf="con g. json" --cluster "qsub -e. /logs/ -o. /logs/" -j 33 --jobscript SCRIPTS/sge. sh --latency-wait 100 -rp ----.
Note on comparison le: -The project name and conditions must match one or more samples in the samplesheet. -There should be no empty lines. -There should be no header. -Same can be speci ed in column 2 and 3 to perform only the rst part of the secondary analysis (all but comparisons). The project has to appear only once in the le. -The rst condition column is the test and the second is the control. Note on the conda environment: -If the environment for this pipeline has already been created the environment for this pipeline, just "conda activate srp". Note on snakemake launch: -Specify the number of jobs with -j <N>. -Even if multiple jobs are not speci ed, two scripts in the pipeline are still threaded. Thus it is advised not to run the pipeline on a real dataset without an HPC. -The path to the log output les must exist ($ mkdir.
These projects represent more than 6000 samples analyzed. Different types of samples were tested, with RNA extracted from cell culture, primary cells, cell sorting, or biopsies. On average, about 300 million reads are generated by a Hiseq rapid run multiplexing 96 samples and about 1 billion on a SP NovaSeq run multiplexing 2*96 samples. From a total of 27k human genes referenced in RefSeq, a maximum of about 16k expressed genes are detected per sample. This plateau is reached with 5 million reads (Fig. 4 ). Our experience based on these projects has allowed us to optimise library preparation and improve data outputs. Each aspect is detailed below. Library preparation -Size library quali cation: The expected library size recommended by Illumina is between 350 and 800 pb. In this protocol, we recommend a library size greater than 400 pb to avoid sequencing the polyA tails.
Bioinformatics analysis The snakemake pipeline is part of our registry and is based on FAIR practices, taking advantage of virtual environments (conda, docker) and continuous integration (jenkins). These best practices allow for pipeline deployment in multiple environments for reproducibility and scalability issues. The gitlab repository provides a short example dataset, which is quick and easy to use. This small dataset mimes 3 conditions with 2 replicates each aligned on hg19 reference. More details are available on the gitlab wiki.
control of RNA: 3 hours -Normalisation and randomization of samples in 96 well-plate : ~2-3 hours -Day 1 (RT, cDNA pooling, Exonuclease, PCR, quanti cation) : ~7 hours -Day 2 (Tagmentation, Indexing PCR, QC, qPCR) : ~6 hours -Sequencing run : ~13 hours (NovaSeq 6000) ~16 hours (HiSeq 2500) Bioinformatics -Snakemake tiny dataset analysis on a PC (16Go RAM, 8 cores): 5 minutes -Real analysis with 96 samples on HPC cluster with 35 parallel jobs: 2 hours.
, 2019). Thus, a future research avenue in computational models may include a densitydependent noradrenergic neuromodulation with the addition of some receptors maps, obtained by positron emission tomography (PET), or even gene expression maps  (Shen et al. , 2012)  that correlate with receptor density maps  (Komorowski et al. , 2017). Surprisingly, using the Allen Human Brain Atlas database  (Shen et al. , 2012)  we found that some adrenergic receptor genes, i. e. , the ADRA2A and ADRB1, are less expressed in the rich club nodes than in feeders and local nodes (Figure  8 ). As a consequence, the noradrenergic-mediated increase in filter gain could have a lower impact on rich club nodes. It is possible that this reduced expression constitutes a compensation for the high connectivity of rich club nodes, specially considering the higher metabolism of rich regions that exposed them to oxidative stress and neuroinflammation  (Griffa and Van den Heuvel, 2018).
Simulations Following  Birn et al. (2013) , we ran simulations to generate the equivalent of 11 min real-time recordings, discarding the first 60 s. The system of stochastic differential equations (5) was solved with the Euler-Maruyama method, using an integration step of 1 ms. We used 10 random seeds (realizations) which controlled the initial conditions and the stochasticity of the simulations. We simulated neuronal activity sweeping the parameters α ∈ [0, 1] and r 0 ∈ [0, 1], for the macroscale scenario. In the local-and meso-scale scenarios, we swept r 0 ∈ [0. 33, 1] for a susbset of nodes, considering a basal value of r 0 = 0. 33 and a fixed α = 0. 65. All the simulations were implemented in Python and the codes are freely available at: https://github. com/vandal-uv/Structural_ Neuromod_2021.
Gene Expression Maps To quantify the expression of some noradrenergic receptor genes in brain regions, we used the microarray expression data of the Allen Human Brain Atlas  (Shen et al. , 2012). The dataset was processed and normalized employing the Abagen library for Python (https://github. com/rmarkello/abagen/tree/0. 1;  Arnatkevicute et al. , 2019) , and then parcellated using the AAL atlas  (Tzourio-Mazoyer et al. , 2002). We compared the expression of the ADRA2A, ADRA2C, and ADRB1 genes in rich club, feeders and local nodes. Statistical comparison was performed with a Student's t-test for independent samples.
FUNDING This work was supported by  Fondecyt  Grants  1181076  (to PO) and  11181072  (to RC), the  Advanced Center for Electrical and Electronic Engineering  ( ANID FB0008 ), and  ANID-Millennium Science Initiative Program   ICN09-022  ( Centro Interdisciplinario de Neurociencia de Valparaíso CINV ). CC-O was funded by  Beca Doctorado Nacional   ANID 2018-21180995.
We present a multithreaded event-chain Monte Carlo algorithm (ECMC) for hard spheres. Threads synchronize at infrequent breakpoints and otherwise scan for local horizon violations. Using a mapping onto absorbing Markov chains, we rigorously prove the correctness of a sequential-consistency implementation for small test suites. On x86 and ARM processors, a C++ (OpenMP) implementation that uses compare-and-swap primitives for data access achieves considerable speed-up with respect to single-threaded code. The generalized birthday problem suggests that for the number of threads scaling as the square root of the number of spheres, the horizon-violation probability remains small for a fixed simulation time. We provide C++ and Python open-source code that reproduces all our results.
Algorithms: from global-time processes to multithreaded ECMC In this section, we start with the definition of a continuous-time process, Algorithm 1, that is manifestly equivalent to molecular dynamics with the collision rules of eq. (  1 ). Its event-driven version, Algorithm 2, provides the reference set L ref of liftings used in our validation scripts (see Section 3). The single-threaded Algorithm 3 relies on local times. It has correct output if no horizon violation takes place. Its event-driven version, Algorithm 4, yields a practical method that can be implemented and tested. Algorithms 5 and 6 realize multithreaded ECMC, the latter in a highly efficient C++ implementation.
1. Code availability. Alg. 4 is implemented in SingleThreadLocalTimeECMC. py and tested in the PValidateECMC. sh script. Remark 7 (Partial validation). In Section 3. 2, a variant of Alg. 4 is used to validate part of a run, even if it does not terminate correctly. When a sphere i detects a horizon violation, its time t i is recorded. At h , the set L t * of all liftings up to the earliest horizon violation, at t * , agrees with the corresponding partial list of liftings for Alg. 1.
Output is as for Alg. 1. Code availability. SequentialMultiThreadECMC. py. implements Alg. 5. It also constructs all states connected to the initial state and traces them to the absorbing states. Remark 8 (Illustration of pseudocode). The multithreading stage of Alg. 5 corresponds in k independent programs running independently. In the sequentialconsistency model, the space of programming statements is thus k-dimensional (one sequence (1ι,. , 26ι) per thread), and each displacement in this space proceeds along a randomly chosen coordinate axis. As an example, if for a buffer {next 1 ,. , next ι = 20ι,. , next k } the switch selects thread ι, then the tag of target particle j ι is set to "static", and the buffer is updated to {next 1 ,. , next ι = 1ι,. , next k }. The thread ι will thus be restarted at its next selection.
The latter is a an atomic variable. We refer to line numbers in Algorithm 5. Remark 11 (Active-sphere necklaces). Alg. 5 restarts thread ι if the target sphere j (for an active sphere i on the thread) is itself active on another thread. With periodic boundary conditions, active-sphere necklaces, where all target spheres are active, can deadlock the algorithm. To avoid this, Alg. 6 moves sphere i up to contact with j before restarting (this is also used in Alg. 4). source code of Algorithm 6 essentially translates that of Algorithm 5. The compiler may however change the order of execution for some statements in order to gain efficiency. (The memory access in modern multi-core processors can also be very complex and, in particular, thread-dependent. ) Attributes, such as the memory_order qualifier in the CAS statement, may constrain the allowed changes of order.
Algorithm 6 (Multithreaded ECMC (C++, OpenMP)). With initial values as in Remark 12 (Memory-order directives in Algs 5 and 6). In the SequentialC5 test suite with N = 5, interchanging statements 15ι and 16ι in Alg. 5 yields a spurious absorbing state, and invalidates the algorithm. The same test suite can also be input into Alg. 6, where it passes the Ordering. sh validation test, even if the statements in MultiCPP. cc corresponding to 15ι and 16ι are exchanged. However, a 1µs pause statement introduced in the C++ program between what corresponds to the (interchanged) statements 15ι and 16ι produces a sim1% error rate, illustrating that Alg. 6 is unsafe without a protection of the order of the said statements. Safety may be increased through atomic position and local time variables, allowing the use of the fetch_add() operation to displace spheres.
This may be of importance if disjoint parts of the constraint graph are stored on different CPUs, each with a number of dedicated threads. In general, we expect constraint graphs to be a useful tool for hardsphere production codes, with typically O (N ) liftings between changes of v. Validation scripts are discussed in Section 3. 2. Scripts check that the liftings of standard cell-based ECMC are all accounted for in the used constraint graph. For the ECMC algorithms of Section 2, the set L of liftings provides the complete history of each run, and scripts check that they corresponds to L ref. In Section 3. 3, we then benchmark Algorithm 6 and demonstrate a speed-up by an order of magnitude for a single CPU with 40 threads on an x86 CPU (see Section 3. 3). The overhead introduced by multithreading (∼ 2.
Runs compute the set L t * to the earliest horizon-violation time t * (with t * = h if the run concludes successfully). The PValidateECMC. sh test first advances C 256 = C t=0 to a random breakpoint h (using L ref ). Each test run is in the interval [h, h ], where h is randomly chosen. To pass the validation test, L t * must for each run agree with L ref (see Section 4 for details of scripts used). Algorithm 4 passes the PValidateECMC. sh test with n run = 1×10 3 for k max = 8192. Our x86 computer has two Xeon Gold 6230 CPUs with variable frequency from 2. 1 GHz to 3. 9 GHz, each with 20 cores and 40 hardware threads. We use OpenMP directives to restrict all threads to a single x86 CPU. We consider again C 256 = C t=0 as the initial configuration, and then run the program from h to h. On our x86 CPU, Algorithm 6 passes the CValidateECMC.
Benchmarks for Algorithm 6 (x86 and ARM) Algorithm 6 is modified as discussed in Remark 7 (program execution continues in spite of horizon violations) and used for large values of h. This measures the net cost of steady-state thread interaction, without taking into account thread-setup times. We report here on results of the BenchmarkECMC. sh script for C 256 as an initial configuration and G 256 with k = 80 active spheres. The number of threads varies as n ι = 1, 2, 3,. , n max ι , with n run = 20. On our x86 CPU (see Section 3. 2), the BenchmarkECMC. sh script is parametrized with n max ι = 40. The benchmark speed increases roughly linearly up to 20 threads (reaching a speed-up of 12 for 20 threads), and then keeps improving more slowly with a maximum for 40 threads at a speed-up of 16 and an absolute speed of ∼ 1.
7×10 12 events/hour (see Fig. 7 ). The variable frequency of Xeon processors under high load may contribute to this complex behavior. On a single thread, our program runs 2. 4 times slower than an unthreaded code, due to the eliminated overhead from threading constructs. The original CellECMC. f90 cellbased production code generates 3×10 10 events/hour. The use of a constraint graph, rather than a cell-based search, thus improves performance by almost an order of magnitude, if the set-up of G is not accounted for. On our ARM CPU, the BenchmarkECMC. sh script is parametrized with n max ι = 4. The benchmark speed increases as the number of threads, reaching a speed-up of 4. 0 for n ι = 4. The absolute speed is about seven times smaller than for our x86 CPU for a comparable number of threads, as may be expected for a low-power processor designed for use in mobile phones.
Available computer code All implemented algorithms and used scripts that are made available on GitHub in ParaSpheres, the public repository, which is part of a public GitHub organization. 5 Code is made available under the GNU GPLv3 license (for details see the LICENSE file). The repository can be forked (that is, copied to an outside user's own public repository) and from there studied, modified and run in the user's local environment. Users may contribute to the ParaSpheres project via pull requests (see the README. md and CONTRIBUTING. md files for instructions and guidelines). All communication (bug reports, suggestions) take place through GitHub "Issues", that can be opened in the repository by any user or contributor, and that are classified in GitHub projects. Implemented algorithms.
Code/Directory Algorithm / Usage CellECMC. f90 Cell-based production ECMC  [   7  In the Setup. sh script, CellECMC. f90 first produces an equilibrated sample C 0. It then generates G (3) with GenerateG3. py, and runs PruneG. py to output G. Finally, it runs GlobalTimeECMC. py for each set A 0 , in order to generate generate several L ref. The ValidateG. sh script runs cell-based ECMC, using GraphValidateCellECMC. cc, and verifies that all liftings are accounted for in G. It also tracks the solicitation of arrows as a function of time. The PValidateECMC. sh script validates SingleThreadLocalTimeECMC. py by comparing the sets of liftings with L ref from Setup. sh. The CValidateECMC. sh script does the same for MultiThreadECMC. cc The BenchmarkECMC. sh script benchmarks MultiThreadECMC. cc for different numbers of threads.