dataesr/scientific-paragraphs-categorization huggingface dataset:
ncbi. nlm. nih. gov). G: Gene set enrichment analysis of a ranked list of all genes comparing MPP + and PSELT treatment versus MPP + with those up-regulated by EZH2 knockout (p value = 0, enrichment score = 1. 14). Genes that are up-regulated by EZH2 knockout and have a H3K27me3 mark correlate with genes up-regulated by MPP + and are down-regulated by PSELT. Data were taken from GSE80222  [38]  and from several other studies  [70] [71] [72]   F: Quantification of cell survival after PSELT and MPP + treatment in the presence or absence of EPZ6438. Data are expressed as mean ± SEM and are compared using ANOVA and Tukey's test, *p < 0. 05, **P < 0. 01 (n = 3 per condition). Experiments were repeated at least twice with similar results. inhibitor significantly attenuates the pro-survival effect exerted by PSELT in the presence of MPP + , indicating that the epigenetic regulator EZH2 is involved in the PSELT-promoted cell survival most likely by regulating histone methylation and chromatin remodeling.
Results of behavioral tests recorded at day 7 are shown as supplemental data (Fig. S2 ) and only data from days 0 and 2 are shown here. B: The coordination capacity of the animal groups was monitored using a rotarod. The latency at which the mice were able to maintain their balance on the bar was recorded. The average latency of the last two trials was used for analyses. Data are expressed as mean ± SEM and are compared using Student t-test, **p < 0. 01 (n = 12). C and D: Horizontal activity of all animal groups was recorded during 3 consecutive periods of 10 min at days 0 (C) and 2 (D). Total horizontal activity for 30 min is shown for each animal group. Data are expressed as mean ± SEM and are compared using Student t-test, *p < 0. 05, **p < 0. 01 (n = 12). E and F: Vertical activity of all animal groups was monitored during 3 consecutive periods of 10 min at days 0 (E) and 2 (F).
Acknowledgements This work was supported by the  Institut National de la Santé et de la Recherche Médicale  (INSERM, grant number  U1239  to YA);  University of Rouen Normandie  (Grant  DC2N  to YA); the  Regional Council of Normandy  and the  European Community FEDER program  (Europe gets involved in regional development through the  ERDF program ) (Grants DO-IT, PACT-PACT-PACBS and PHEDERCPG to YA); the  Comparative Genomics and Cancer Genetics Branch, National Human Genome Research Institute, National Institutes of Health  (to AGE) and the  Ministry of Education of Saudi Arabia (Scholarship  to I. A. ). Images were acquired and peptides were synthesized in PRIMACEN, the cell imaging platform of Normandy and behavioral analyses were performed in the SCAC platform of IRIB. The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.
, 2001). ChIP efficiency and quality were measured using the Epstein-Barr virus latent origin oriP as reference (Suppl. Fig. 1c ). The Raji cell line contains 50-60 EBV episomes  (Adams et al. , 1973). The viral protein EBNA1 recruits ORC to oriP's dyad symmetry element, followed by MCM-DH loading. We detected both ORC and MCM at the dyad symmetry element, as expected  (Papior et al. , 2012; Ritzi et al. , 2003). ChIP-sequencing of two ORC (Orc2, Orc3) and three  MCM (Mcm3, Mcm7)  replicates resulted in reproducible, but dispersed ChIP-seq signals as exemplified at the well-characterized replication origin Mcm4/PRKDC (Fig. 1a ). We first employed the MACS2 peak-calling program  (Feng et al. , 2012; Zhang et al. , 2008) , but found that the obtained results were too dependent on the chosen program settings.
At genome-wide levels, we found that ORC and MCM distributions were too dispersed to be efficiently captured by peak calling (data not shown), requiring an alternative approach. Consequently, we summed up the reads of the ChIP replicates in 1 kb bins and normalized the signals against the mean read frequencies of each ChIP sample and against input, as is standard in most ChIP-seq analyses. However, in line with a previous report  (Teytelman et al. , 2009) , the input sequencing control was differentially represented in DNase HS regions or regions of biological function. For example, the input was significantly underrepresented in DNase HS regions (DNase HS clusters retrieved from an ENCODE dataset comprising 125 cell lines, see Material and Methods section; Suppl. Fig. 2a ), TSSs (Suppl. Fig.
RNA extraction, sequencing, TPM calculation RNA was extracted from 3 x 10 5 Raji cells using Direct-zolTM RNA MiniPrep kit (Zymo Research) according to manufacturers' instructions. RNA quality was confirmed by Bioanalyzer RNA integrity numbers between 9. 8 and 10 followed by library preparation (Encore Complete RNA-Seq Library Systems kit (NuGEN)). Single-end 100 bp sequencing was performed by Illumina HiSeq 1500 to a sequencing depth of 25 million reads. The reads were mapped to hg19 genome using Tophat2 and assigned to annotated genes (HTSeq-count)  (Anders et al. , 2015; Kim et al. , 2013). TPM values (Transcripts per kilobase per million reads) were calculated for each sample ( ! = 10 ! ! ! ! ! / ! ! ! ! ! where n i is the number of reads that map to gene i whose total exon length expressed in kb is l i ) as previously described  (Wagner et al.
Replication fork directionality profiling using OK-seq method in Raji Raji OK-seq was recently published as part of  Wu et al. and  is available from the European Nucleotide Archive under accession number PRJEB25180 (see data access section)  (Wu et al. , 2018). Reads > 10 nt were aligned to the human reference genome (hg19) using the BWA (version 0. 7. 4) software with default parameters  (Li & Durbin, 2009). We considered uniquely mapped reads only and counted identical alignments (same site and strand) as one to remove PCR duplicate reads. Five biological replicates were sequenced providing a total number of 193. 1 million filtered reads (between 19. 1 and 114. 1 million reads per replicate). RFD was computed as  = (!!!) (!!!) , where "R" (resp. "F") is the number of reads mapped to the reverse (resp.
Comparison of ChIP relative read frequencies to transcription data Gene containing bins were determined and overlapping genes removed from the analysis. For cumulative analysis, we only worked with genes larger 30 kb, and assigned the gene expression levels in TPM accordingly. Genes were either aligned at their transcriptional start site (TSS) or their transcriptional termination site (TTS) and the corresponding ChIP read frequencies were calculated in a 30 kb window around the site.
Comparison of ChIP relative read frequencies to replication timing For identification of RTDs in Raji cells, we used the early to late replication timing ratio determined by Repli-seq  (Sima et al. , 2018). We directly worked from the precomputed early to late log-ratio from supplementary file GSE102522_Raji_log2_hg19. txt downloaded from GEO (accession number GSE102522). The timing of every non-overlapping 10 kb bin was calculated as the averaged log 2 (Early/Late) ratio within the surrounding 100 kb window. Early RTDs were defined as regions where the average log-ratio > 1. 6 and late RTDs as regions where the average log-ratio < -2. 0. These thresholds resulted in 1648 early RTDs, ranging from 10 to 8940 kb in size, with a mean size of 591 kb, while we detected 2046 late RTDs in sizes from 10 to 8860 kb, averaging at 470 kb.
ERCE RFD profiles The position of the three genetically identified ERCEs in the mESC Dppa2/4 locus and of the 1,835 predicted mESC ERCEs were downloaded from Sima et al. (Sima et al. , 2019. The mESC OK-seq data were downloaded from Petryk et al. (Petryk et al. , 2018) , (SRR7535256), and mapped to mm10 genome Petryk et al. (Petryk et al. , 2018). OK-seq data from cycling mouse B cells were downloaded from.
Tubbs et al. (Tubbs et al. , 2018 ) (GSE116319). The RFD profile was computed as in Hennion et al. , 2020  with 10kb binning steps. Predicted ERCE shuffling was performed using a homemade function keeping the number of ERCE constant for each chromosome and avoiding unmapped genome sequences (genome regions with more than 20 consecutives N). Aggregated average RFD profiles were centered on the ERCE and the profile's envelopes represent the CI95 based on the mean and standard deviation at each position. was assigned to URRs and NRRs and represented as boxplot (mean (circle), the median (thick line), the 1st and 3rd quartile (box), the 1st and 9th decile (whiskers), without representing outliers). Statistics were performed using one-sided t-test. *** p < 0. 001. d-e) 3x5 panel of 2D histograms representing Orc3 (d) and Mcm7 (e) ChIP frequency vs.
Acknowledgements We thank  Tobias Straub  for initial help with bioinformatical analyses,  Torsten Krude  and  Till Bartke  for critical comments on the manuscript. A. S. was supported by the  Deutsche Forschungsgemeinschaft  ( SFB 1064 TP05 ),  SPP1230  and by the HELENA graduate school of the  Helmholtz Zentrum München. B. A. and O. H were supported by the  Agence Nationale de la Recherche  ( ANR-15-CE12-0011 ,  ANR-18-CE45-0002 ,  ANR-19-CE12-0028 ) and the  Fondation pour la Recherche Médicale  ( FRM DEI201512344404 ), and the  Cancéropôle Ile-de-France  and the  INCa  ( PL-BIO16-302 ). O. H. was supported by the  Ligue Nationale Contre le Cancer (Comité de Paris) , the  Association pour la Recherche sur le Cancer , and the program " Investissements d'Avenir " launched by the  French Government  and implemented by the  ANR  ( ANR-10-IDEX-0001-02 PSL*Research University ).
Data access Data have been deposited to the European Nucleotide Archive (ENA, https://www. ebi. ac. uk/ena). OK-seq data in Raji cells are available under the accession numbers PRJEB25180 (study accession) and SAMEA104651899 (sample accession, 5 replicates). Raji RNA-seq data are available under the accession number PRJEB31867 (study) and SAMEA5537240, SAMEA5537246, and SAMEA5537252 (sample accession per replicate). Raji ChIP-seq data were deposited under the accession number PRJEB32855.
I. INTRODUCTION The use of density-functional theory (DFT) to compute the properties of systems at the atomic level has become widespread  [1, 2] , as both the number of quantum engines that implement it and the available computational power continue to increase. However, despite its large-scale deployment both in academia and in industry, the application of DFT is still not a trivial operation. Accurate predictions require expert knowledge of not just DFT itself but also of the specific code used to perform the calculations (throughout this work we will use the terms quantum engine and code interchangeably). Although the diversity of available simulation packages improves the accuracy and reliability of results by virtue of cross-verification  [3] , different codes use diverse computational methods and interfaces, making it difficult even for experts to master more than just a few of them.
This may result in software being used not for its applicability to a particular problem, but merely due to circumstantial reasons. Furthermore, the fact that the correct usage of DFT-based codes requires expert knowledge directly limits its application and potential for scientific discovery. Although DFT is used to compute many material properties of varying complexity, a large percentage of all performed calculations are defined by relatively simple recipes. Therefore, in addition to implementing new functionalities and improving the accuracy of existing ones, the effort of domain and code experts should be focused on providing robust workflows with common interfaces that can be used by experts and non-experts alike. If these are designed properly such that they are reusable, they can be employed as modular blocks in building more complex workflows, e.
This particular common workflow interface, referred to as the "common relax workflow" throughout this work, allows a user to optimize a structure using any of these codes without having to define code specific parameters. The computed results are returned in a single unified format with identical units making the results directly comparable and reusable regardless of the underlying quantum engine used. Each implementation of the common relax workflow interface provides at least three protocols ('fast', 'moderate' and 'precise') that allow a user to specify the desired computational accuracy in an intuitive and general way. The mapping between these levels of protocols and code specific parameters are up to the respective code experts to define. Through these protocols, expert knowledge of appropriate numerical parameters is thus encoded directly into the workflows, reducing the risk of incorrect or unreliable results and opening up the use of the quantum engines also to non-experts.
The EOS and the DC are computed for a few compounds with different geometric, electronic and magnetic properties. As we will show later, the results computed by the various quantum engines show good agreement. We stress here that the focus of this paper is not on the validation of the results, but rather on the demonstration of the feasibility of a common workflow interface, directly enabling the reusability of complex workflows and the cross-verification of their results. We hope this will motivate readers to generalize these concepts and apply them to a broader and more complex range of problems. The implementations of the common relax workflow interface of all quantum engines described in this paper are made available as free open-source software at https://github. com/aiidateam/aiida-common-workflows under the MIT license.
Common workflow design To ensure that the common workflows satisfy the requirements of optional transparency and scoped provenance, we have chosen to implement them using Ai-iDA  [6] , a scalable computational infrastructure for automated reproducible workflows and data provenance. The workflows are implemented as AiiDA work chains  [29] , whose data provenance and that of all their subprocesses is automatically stored by AiiDA in a relational database. AiiDA provides an application programming interface (API) to query the provenance graph at various levels of granularity, satisfying the scoped provenance requirement. The optional transparency criterion is made possible by the design of AiiDA's workflow language specification  [29]. All processes in AiiDA are implemented in Python and, most importantly, the process specification (see Listing 1) is defined programmatically, allowing inspection of inputs and outputs before executing the workflow.
Design strategy The design of the interface is guided by the idea to employ optional transparency to create a workflow interface that is suitable both for expert and nonexpert users. This interface must be simple and general (code-agnostic) but at the same time retain full flexibility in changing code-specific parameters. Our adopted solution consists in the creation of code-specific workflows (implemented as AiiDA work chains named <Code>CommonRelaxWorkChain, where <Code> indicates the name of the underlying quantum engine), whose interface design is not restricted. A common interface is achieved by ensuring that each work chain provides also an input generator whose interface is identical for every <Code>, as shown in Fig. 3. Listing 5 shows an actual code example of how the input generator can be obtained from a work chain implementation.
The get_builder method of the input generator will transform the inputs, that respect the common interface, into the inputs that are expected by the corresponding code-specific work chain implementation. The inputs are returned in the form of a "builder" which can be directly submitted to AiiDA to start running the workflow. g e t _ i n p u t _ g e n e r a t o r() builder = g e n e r a t o r. g e t _ b u i l d e r( s t r u c t u r e=. , protocol =. ,. ) submit ( builder ) Listing 5. Submission of the relax common workflow employing the quantum engine <Code>. The arguments accepted by get_builder are identical for every <Code>, establishing a common interface. We note that not only the names but also the (Python) types of the inputs and outputs are standardized to en- Any implementation consists of two parts: the <Code>CommonRelaxWorkChain and a <Code>CommonRelaxInputGenerator.
Common inputs The second step of the design is the identification of the minimal set of arguments for the input generator, reflecting the inputs of the most generic relaxation process. We identified three fundamental inputs that we therefore implemented as mandatory arguments of the get_builder method. • structure. The structure to relax. (type: an AiiDA StructureData instance, the common data format to specify crystal structures and molecules in AiiDA  [31] ). • protocol. In the context of this work, this means a single string summarizing the computational accuracy of the underlying DFT calculation and relaxation al-gorithm. Three protocol names are defined and implemented for each code: 'fast', 'moderate' and 'precise'. The details of how each implementation translates a protocol string into a choice of parameters is code dependent, or more specifically it depends on the implementation choices of the corresponding Ai-iDA plugin.
Typically one single executable is sufficient to perform the relaxation. However, there are cases in which two or more codes in the same simulation package are required to achieve the final goal, as for example in the case of FLEUR. (type: a Python dictionary). Other inputs have been recognized as common optional features that also a non-expert user might want to have control over: • threshold_forces. A real positive number indicating the target threshold for the forces in eV/Å. If not specified, the protocol specification will select an appropriate value. (type: Python float). • threshold_stress. A real positive number indicating the target threshold for the stress in eV/Å 3. If not specified, the protocol specification will select an appropriate value. (type: Python float). • electronic_type.
The get_relax_types method returns the supported values for relax_type for the corresponding workflow implementation. Inspection methods are implemented for all codes and all the arguments of get_builder except the threshold values, the structure, the reference_workchain, and the magnetization_per_site. Associated to the engines argument, there are the methods get_engine_types and get_engine_type_schema, which return the steps required by the relaxation and information on the code type necessary for each step of the relaxation, respectively. The described inspection methods allow to introspect, in a fully machine-readable and automatic way, what the valid options for a particular common workflow implementation are. This is particularly relevant to facilitate future development of a graphical user interface (GUI) for the submission of the common relax workflow.
However, it is worth mentioning that the small discrepancies between codes in Fig. 4  are not surprising, considering that the treatment of polar molecules with codes designed for extended systems is not a trivial task. In particular, some codes always need to use periodic boundary conditions, introducing non-physical interactions among replicas in the calculation. Even for large A b i n i t B i g D F T C A S T E P C P 2 K F L E U R * G a u s s i a n N W C h e m O R C A Q E S i e s t a V A S P ∆E (eV) Figure  4. Energy difference between the planar and pyramidal phases of ammonia. Energy difference (∆E) between the planar and pyramidal phases of ammonia, calculated with the eleven quantum engines reported in the horizontal axis (QE stands for Quantum ESPRESSO). A relaxation of the structure has been performed independently by every code before computing the energies (except for FLEUR * , because for FLEUR the relaxation failed due to overlapping muffin-tin spheres, a method-specific issue requiring error handling.
Provenance Since all workflows are implemented using AiiDA, the full provenance is automatically stored when the workflow is executed, as discussed in Sec. II A. Fig. 5  shows Schematic provenance graph for a relaxation workflows. Schematic provenance graph for a relaxation workflow powered by two different quantum engines (top: Siesta; bottom: Quantum ESPRESSO). The node of the <Code>CommonRelaxWorkChain is highlighted with the label "RelaxWorkChain" and with a red edge. All the Ai-iDA work chains called during the relaxation are represented by orange rectangles. The dark red rectangles are calculations, meaning calls to an external executable that performs a calculation, for instance a call to the pw. x of Quantum ESPRESSO. All the ellipses represents data nodes, meaning nodes in the database that contain data, like, for instance, the initial structure, the total energy and so on.
In blue is the data node representing the code utilized for the calculations. In pink are represented calls to Python functions that modify some data in order to create others. a schematic provenance graph for a relaxation workflow powered by two different quantum engines. Note that only a subselection of the total number of inputs and outputs are shown for clarity, but all subprocesses are displayed and the connections between the nodes give an idea of the internal complexity of the workflows. Notably, the figure shows how the different workflow implementations can follow considerably different logical paths while ultimating returning the same quantities according to the same common interface. The action of taking the arguments of the common interface and transforming them in code-specific inputs (operated by the input generators) is not tracked.
C. Code-agnostic workflows Optimizing the geometry of a solid-state structure or molecule is a common core building block of materialsscience workflows. Creating a common workflow interface for this particular task allows higher level workflows that reuse it to become code agnostic. This makes it possible to run the workflow with any quantum engine that implements the common relax workflow interface, without having to explicitly specify any input that is specific to the quantum engine. We discuss two examples of such workflows in the following sections.
Using this common relax workflow, we have shown how higher-level workflows can reuse it to compute relevant material properties, such as the EOS and DC, while keeping a fully code-agnostic interface. Our results show how optionally transparent common workflow interfaces directly enable the cross-verification of results produced by different quantum engines. In addition, they empower a broader audience to use these methods in a robust way, encoding the experts' knowledge into reproducible code and hopefully stimulating new collaborations and more accurate materials science simulations. Volume/atom (Å 3 ) Figure  7. EOS for Si, Al and GeTe. Results obtained with the code-agnostic EquationOfStateWorkflow. For each code, the energy is shifted to set the minimum energy to zero. The EOS has been computed with all codes discussed in this work, except ORCA and Gaussian, which are mainly specialized for non-periodic systems.
05. 1, which can be downloaded here. Quantum Mobile is an open-source virtual machine based on Ubuntu, that comes with a large number of codes, tools and de-  pendencies that are commonly needed to run materialsscience atomistic simulations. In particular, it contains a pre-configured AiiDA installation together with the plugins interfacing AiiDA to all eleven quantum engines described here. In addition, since version 21. 05. 1 Quantum Mobile also includes the common-workflow interfaces and implementations discussed here, released as the aiida-common-workflows package v0. 1 on PyPI. Crucially, Quantum Mobile also includes the executables for the following open-source quantum engines: Abinit, BigDFT, CP2K, FLEUR, NWChem, Quantum ESPRESSO and Siesta (as well as a few more). Although CASTEP and ORCA provide free academic licenses, it requires users to have their own license which prevents pre-installation in Quantum Mobile.