dataesr/scientific-paragraphs-categorization huggingface dataset:
Web interface A web-based interface has been established at https:// bioinfo-csi. nus. edu. sg/methmotif allowing an intuitive exploration of our datasets and facilitating queries to the The distribution of the corresponding CpG methylation scores is then profiled in a heatmap for each cell type, to present the DNA methylation levels surrounding peak regions across all ChIP-ed proteins (methylation score less than 10% is defined as homogenously unmethylated, while methylation score more than 90% is regarded as homogenously hypermethylated). These heatmaps are accessible from the 'Explore' section of the MethMotif website (B). Finally, the direct binding motifs of sequence-specific TFs are identified. The DNA methylation level within TFBS is captured and shown in a MethMotif logo. MethMotif logos are collected in 'MethMotif database' section of the MethMotif website (C).
The methylation levels within each logo can be displayed according to three states: (i) all methylation levels compiled, (ii) methylated only and, (iii) unmethylated only (D). database. Users can freely access MethMotif via these three modes: 1. 'Motif database direct query'. Like many TFBS webservers, MethMotif includes a search engine that allows users to query any DNA binding protein present in our database using either its official gene name or its Meth-Motif ID (see an example of MethMotif ID in Figure  1C ). Queries can be refined by selecting a given cell line or tissue of interest. Query results include the Meth-Motif logo, information about the cell type, ChIP-seq and WGBS assays, as well as motif distributions, motif locations and downloadable processed files (PWM and methylation matrices), along with links to JASPAR 2018 and HOCOMOCO (Figure  1C  and D ).
2. 'Explore'. Users can intuitively explore all DNA binding proteins available in the released cell types in our database via dynamic heatmaps that classify each protein according to its CpG methylation pattern in a ±100 bp window surrounding ChIP-seq peak summits. Details about any DNA binding protein of interest can be easily obtained by hovering over the corresponding heatmap's row (Figure  1B ). To date, we have made available 11 dynamic heatmaps corresponding to the 11 analysed cell types. The heatmap dynamic interface takes advantage of InCHlib, an open source interactive JavaScript library (28). 3. 'Batch query'. MethMotif allows users to analyse the occurrences of TFBSs along with their respective methylation states across a given list of genome loci. This functionality is particularly useful to characterise binding sites for co-factors of a protein of interest, along with their respective DNA methylation levels.
Batch query module The functionality of batch query module implemented in MethMotif website is achieved by mapping the given list of genome loci to all TFBS genomic coordinates, together with their respective CpG methylation scores, in MethMotif database using in-house python scripts. The visible results, namely beeswarm boxplots and de novo generated MethMotif logo, are produced using WebLogo3  (26)  and in-house R scripts with the grImport package  (29).
Database maintenance Established ChIP-seq working standards and guidelines in ENCODE consortium foster reliable ChIP-seq data  (17). Since the beginning of the project, MethMotif database has been regularly updated with ChIP-seq datasets from EN-CODE. We plan to further enrich the MethMotif database by expanding cell types using newly generated WGBS datasets from ENCODE, GEO and in-house experiments. Furthermore, we intend to take advantage of the Gene Transcription Regulation Database (GTRD), which is a comprehensive compendium of ChIP-seq experiments covering the existing multiple ChIP-seq databases  (14) , to expand the coverage of TFs in MethMotif.
MethMotif classifies DNA-interacting proteins according to DNA methylation profiles The integration of WGBS with ChIP-seq datasets allowed us to profile the DNA methylation landscapes surrounding binding loci of DNA-bound proteins in vivo, at the genome scale. We employed this strategy to capture the CpG methylation patterns in a ±100 bp window surrounding the peak summits of ENCODE ChIP-ed proteins with high reproducibility in different cell types (Figure  1A ). As described previously  (9) , DNA-binding proteins exhibit distinct DNA methylation levels around their occupancy regions and accordingly can be classified into different sub-groups (Figure  1B , Supplementary Figure  S1 ). In myelogenous leukaemia K562 cells, we were able to classify 250 ChIP-ed proteins based on DNA methylation landscapes around binding regions into three groups (I, high; II, medium and III, low methylated DNA binding affinity) and one outlier (very high methylated binding affinity --ZBTB33) (Supplementary Figure  S1 ).
MethMotif introduces a new dimension to Position Weight Matrix (PWM) A key feature of TFs is their ability to bind DNA by the recognition of a specific DNA motif. However, ChIPseq peak regions are not necessarily associated with direct binding sites  (25)  and DNA methylation profiling around all aforementioned peaks may not reflect the influences of DNA methylation on the recruitment of TFs onto DNA sequences. Therefore, we inferred TFBSs by selecting genomic loci that contained a centrally enriched DNA motif surrounding ChIP-seq centres  (25). TFBS was characterised using the MEME-ChIP package  (24)  in ±100 bp regions surrounding peak centres discovered by the IDR pipeline. This strategy allowed us to capture the DNA methylation landscape within each TFBS motif. In order to intuitively illustrate TFBS coupled with DNA methylation, we introduced a novel graphical representation combining a motiflogo  (26)  with cumulative bar charts displaying three different DNA methylation levels: (i) homogenously low (less than 10% sequenced CpGs of a given site are methylated); (ii) homogenously high (more than 90% of sequenced CpGs of a given site are methylated) and (iii) heterogeneously methylated (10-90% sequenced CpGs of a given site are methylated) (Figure  1C  and D ).
Numerous TFs exhibit distinct binding site sequences and/or distinct binding site methylation profiles across different cell types In contrast to pre-existing TFBS databases, MethMotif records TFBSs computed in a cell specific manner. Our meta-analysis shows that numerous TFs exhibit either distinct TFBSs, or distinct DNA methylation profiles, or both, depending on cell types. Notably, when comparing ChIPseq performed in K562 and GM12878 cells, we found that the basic leucine zipper factor NFE2 has the ability to bind distinct DNA motifs (Figure  3A ). Indeed, in K562, NFE2 recognises an extended AP-1-like motif, (T/C/A)GCTGA(C/G)TCA(T/C), while the motif identified in GM12878 is similar to the USF binding site (Supplementary Figure  S2A ). Interestingly, both motifs are supported by the literature.
Specifically, NFE2 has been shown to bind an AP-1-like motif as a heterodimer with MAF family members, such as MAFF and MAFK  (33) ; and, in another context, NFE2 was characterised to belong to a complex including USF  (34). We were able to corroborate these facts by using the MethMotif batch query module with all NFE2 binding sites in K562 and GM12878 cells (Supplementary Figure  S2B ). In addition, we found that the length of spacers of leucine zipper dimers, such as JUN, varies with cell types. For example, in hepatocyte carcinoma HepG2 and embryonic stem cell line H1-hESC, the main motif spacer of JUN is a CG dinucleotide, while it amounts to only a single base, either C or G, in breast cancer MCF-7, lung adenocarcinoma A549 and myelogenous leukaemia K562 cells (Figure  3B ). Interestingly, the UniProbe TFBS database, which records in vitro characterised DNA binding sites, contains another AP-1 leucine zipper TF, JUNDM2 (Jun dimerisation protein 2), that recognises motifs similar to JUN with a spacer that can vary from 1 to 2 nucleotides (UniProbe accession number: UP00103)  (35).
MethMotif batch query: a case study MethMotif portal includes a batch query tool which allows users to study the occurrences of TFBSs and their respective DNA methylation states within a given list of genomic loci. As a proof of concept, we ran MethMotif batch query using a list of CEBPB binding sites characterised by a ChIP-seq experiment in HCT116 cells (Supplementary Data 1). As expected, the most enriched TFBS found by MethMotif is CEBPB (4846 overlapped occurrences, Figure  2D  and Supplementary Figure  S4 ). Furthermore, MethMotif batch query brought to light 12 co-factors that overlap our input list from 1 to 300 co-occurrences (Supplementary Figure  S4 ). Results include known CEBPB co-factors such as ATF3 (300 co-occurrences)  (38)  and JUND (74 cooccurrences)  (39). Interestingly, only CEBPB binding loci harbour methylated CpG sites (Supplementary Figure  S4 ).
Identification of methyl-cytosine binding TFs by Meth-Motif is the initial but crucial step to study the crosstalk between TFs and DNA methylation. While we provide compelling evidence that numerous TFs bind differentially to methylated and non-methylated DNA, ChIP-BS-seq experiments  (27)  will be required to confirm these interactions. Nonetheless, the current version of MethMotif remains a valuable resource for guiding researchers in the usage of ChIP-BS-seq as an alternative to ChIP-seq for studying methyl-binding TFs. In conclusion, MethMotif complements current TFBS databases by integrating DNA methylation as a new epigenetic dimension with TFBS, thereby providing a useful resource for the study of DNA methylation and TF recruitment dynamics.
These heatmaps are accessible from the 'Explore' section of the MethMotif website (B). Finally, the direct binding motifs of sequence-specific TFs are identified. The DNA methylation level within TFBS is captured and shown in a MethMotif logo. MethMotif logos are collected in 'MethMotif database' section of the MethMotif website (C). The methylation levels within each logo can be displayed according to three states: (i) all methylation levels compiled, (ii) methylated only and, (iii) unmethylated only (D).
ACKNOWLEDGEMENTS The authors thank  Morgane Thomas-Chollier  and  Daniel G. Tenen  for useful discussions and comments during the preparation of this manuscript, as well as  Mathanapriya Naidu  for her proof-reading. Authors contributions: Q. X. X. L. and T. B. designed the platform; Q. X. X. L. programmed the website and performed all analysis; O. A. participated in the graphical user interface implementation; S. S. generated the HCT116 WGBS dataset; Q. X. X. L. , D. T. , S. J. and T. B. interpreted the data; Q. X. X. L. and T. B. wrote the manuscript. T. B. directed the study.
FUNDING Work in the T. B. laboratory is supported by the  National Research Foundation , the  Singapore Ministry of Education  under its  Centres of Excellence initiative , the  National Medical Research Council of Singapore  [ NMRC/BNIG/2035/2015 ];  RNA Biology Center  at the  Cancer Science Institute of Singapore, NUS , as part of funding under the  Singapore Ministry of Education 's AcRF Tier 3 grants [ MOE2014-T3-1-006 ]. T. B. and D. T. collaboration is supported by the  Institut Francais à Singapour [Merlion Project  grant number  6. 10. 14 ]. S. J. was supported by grants from the  National Research Foundation Singapore  and the  Singapore Ministry of Education  under Nucleic Acids Research, 2019, Vol. 47, Database issue  D153 its Research Centers of Excellence initiative  to the  Cancer Science Institute of Singapore  [ R-713-006-014-271 ];  National Medical Research Council (NMRC)  [ CBRG-NIG BNIG11nov001 ];  Ministry of Education Academic Research Fund  [ MOE AcRF Tier 1 T1-2012 Oct-04  and  T1-2016 Apr-01 ];  RNA Biology Center at CSI Singapore ,  NUS , from funding by the  Singapore Ministry of Education 's AcRF Tier 3 grants [ MOE2014-T3-1-006 ].
Code Generation in Computational Neuroscience second is to allow model definitions in a high level interpreted language, although this may limit performance. Recently, a third approach has become increasingly popular: using code generation to automatically translate high level descriptions into efficient low level code to combine the best of previous approaches. This approach also greatly enriches efforts to standardize simulator-independent model description languages. In the past few years, a number of code generation pipelines have been developed in the computational neuroscience community, which differ considerably in aim, scope and functionality. This article provides an overview of existing pipelines currently used within the community and contrasts their capabilities and the technologies and concepts behind them.
Recently, such support has also been added to the NEST simulator via NESTML  (Plotnikov et al. , 2016 , see section 2. 4). Finally, other simulators (e. g. , Brian, Goodman 2010, see section 2. 1; The Virtual Brain, see section 2. 10) include model descriptions as integral parts of the simulation script, transparently converting these descriptions into executable code. These approaches to model descriptions have been complemented in recent years by various initiatives creating simulator-independent model description languages. These languages completely separate the model description from the simulation environment and are therefore not directly executable. Instead, they provide code generation tools to convert the descriptions into code for target environments such as the ones mentioned above, but also for more specialized target platforms such as GPUs (e.
Brian All versions of the Brian simulator have used code generation, from the simple pure Python code generation for some model components in its earliest versions  (Goodman and Brette, 2008, 2009) , through the mixed Python/C++ code generation in later versions  (Goodman, 2010) , to the exhaustive framework in its latest version (2. x) that will be described here. It now uses a consistent code generation framework for all model components, and allows for multiple target languages and devices  (Stimberg et al. , 2012 (Stimberg et al. , -2018a (Stimberg et al. , , 2014)). Brian 2 had code generation as a major design goal, and so the user model, data model, and execution model were created with this in mind (Figure  1 ). FIGURE 1 | Brian model structure. Brian users define models by specifying equations governing a single neuron or synapse.
Brian code: G = NeuronGroup(1, 'dv/dt = -v/tau : 1') "Abstract code" (internal pseudo-code representation) _v = v * exp(-dt/tau) v = _v C++ code snippet (scalar part) const double dt = _ptr_array_defaultclock_dt[0]; const double _lio_1 = exp((-dt)/tau); C++ code snippet (vector part) double v = _ptr_array_neurongroup_v[_idx]; const double _v = _lio_1 * v; v = _v; _ptr_array_neurongroup_v[_idx] = v; Compilable C++ code excerpt: // scalar code const double dt = _ptr_array_defaultclock_dt[0]; const double _lio_1 = exp((-dt)/tau); for(int _idx=0; _idx<_N; idx++) { // vector code double v = _ptr_array_neurongroup_v[_idx]; const double _v = _lio_1 * v; v = _v; _ptr_array_neurongroup_v[_idx] = v; } FIGURE 2 | Brian code generation pipeline. Code is transformed in multiple stages: the original Brian code (in Python), with a differential equation given in standard mathematical form; the internal pseudocode or "abstract code" representation (Python syntax), in this case an exact numerical solver for the equations; the C++ code snippets generated from the abstract code; the compilable C++ code.
However, for smaller networks that might need to be run repeatedly or for a long duration, these overheads can be significant. Brian therefore also has the standalone mode, in which it generates a complete C++ project that can be compiled and run entirely independently of Python and Brian. This is transparent for the users and only requires them to write set_device('cpp_standalone') at the beginning of their scripts. While this mode comes with the advantage of increased performance and portability, it also implies some limitations as user-specified Python code and generated code cannot be interspersed. Brian's code generation framework has been designed in a modular fashion and can be extended on multiple levels. For specific models, the user might want to integrate a simulation with hand-written code in the target programming language, e.
Main Modeling Focus The focus of GeNN is on spiking neuronal networks. There are no restrictions or preferences for neuron model and synapse types, albeit analog synapses such as graded synapses and gap junctions do affect the speed performance strongly negatively. class MyIzhikevich : public NeuronModels:: Izhikevich { public: DECLARE_MODEL(MyIzhikevich, 5, 2) SET_SIM_CODE( "if ($(V) >= 30. 0) {\n" " $(V)=$(c);\n" " $(U)+=$(d);\n" "}\n" "$(V) += 0. 5 * (0. 04 * $(V) * $(V)+5. 0 * $(V)+140. 0-$( U)+$(I0)+$(Isyn)) * DT;\n" "$(V) += 0. 5 * (0. 04 * $(V) * $(V)+5. 0 * $(V)+140. 0-$( U)+$(I0)+$(Isyn)) * DT;\n" "$(U) += $(a) * ($(b) * $(V)-$(U)) * DT;\n"); SET_PARAM_NAMES({"a", "b", "c", "d", "I0 The code example above illustrates the nature of the GeNN API. GeNN expects users to define their own code for neuron and synapse model time step updates as C++ strings.
Code Generation Pipeline The model description provided by the user is used to generate C++ and CUDA C code for efficient simulation on GPU accelerators. For maximal flexibility, GeNN only generates the code that is specific to GPU acceleration and accepts C/C++ user code for all other aspects of a simulation, even though a number of examples of such code is available to copy and modify. The basic strategy of this workflow is illustrated in Figure  3. Structuring the simulator framwork in this way allows achieving key goals of code generation in the GPU context. First, the arrangement of neuron and synapse populations into kernel blocks and grids can be optimized by the simulator depending on the model and the hardware detected at compile time. This can lead to essential improvements in the simulation speed.
Numerical Integration Unlike for other simulators, the numerical integration methods, and any other time-step based update methods are for GeNN in the user domain. Users define the code that performs the time step update when defining the neuron and synapse models. If they wish to use a numerical integration method for an ODE based neuron model, users need to provide the code for their method within the update code. This allows for maximal flexibility and transparency of the numerical model updates. However, not all users may wish to use the C++ interface of GeNN or undertake the work of implementing the time step ), either hand-crafted by a user or generated from a higher-level model description language such as SpineML or Brian 2 (see main text). The neuron model description is included into the GeNN compiler that produces optimized CUDA/C++ code for simulating the specified model.
, 2014)  scripts with GeNN as the backend and there is a separate toolchain connecting SpineCreator and SpineML (see section 2. 8;  Richmond et al. , 2014)  to GeNN to achieve the same. Although there can be a loss in computing speed and the range of model features that can be supported when using such interfaces, using GPU acceleration through Brian2GeNN can be as simple as issuing the command set_device('genn') in a Python script for Brian 2.
The mechanisms (particles, ions, channels, pumps, etc. ) are user-definable with object-based inheritance, e. g. , channels inherit properties based on their permeant ions. Simulations are represented as objects to facilitate iterative parameter searches and reproducibility of results. The inheritance functionality via Python's native object system allows access to properties of parent component and functionality can be extended and overridden at will. The intermediate interface layer flattens and translates the model into non-hierarchical nodes and coupling mechanisms for the solver using AST-to-AST translation of Python code to C. Accordingly, the top-level model definition syntax depends only on application-layer Python modules; in principle, additional such modules can be written for applications outside neuroscience, or to mimic the model definition syntax of other Python-based simulators.
Importantly, while this shared-memory design enables analog interactions to be parallelized efficiently, to take proper advantage of this capacity on GPUs, the simulation must execute on the GPU independently rather than being continuously controlled by the host system. To accomplish this, Myriad uses a code generation strategy embedded in its three-layer architecture (see section 2. 3. 2). The lowest (solver) layer is written in C99 for both CPUs and NVIDIA GPUs (CUDA). The solver requires as input a list of isometric nodes and a list of coupling mechanisms that connect pairs of nodes, all with fully explicit parameters defined prior to compilation (i. e. , execution of a Myriad model requires just-in-time compilation of the solver). To facilitate code reuse and inheritance from the higher (Python) layers, a custom-designed minimal object framework implemented in C  (Schreiner, 1999)  supports ondevice virtual functions; to our knowledge this is the first of its kind to execute on CUDA GPUs.
Additional top-layer modules can be written by end users for different purposes, or to support different code syntaxes. Execution of a Myriad simulation begins with a transformation of the user-specified model definition into two Python lists of node and mechanism objects. Parameters are resolved, and the Python object lists are transferred to the solver layer via a custom-built Python-to-C pseudo-compiler (pycast; an AST-to-AST translator from Python's native abstract syntax tree (AST) to the AST of pycparser (a Myriad dependency), facilitated by Myriad's custom C object framework). These objects are thereby rendered into fully explicit C structs which are compiled as part of the simulation executable. The choice of CPU or GPU computation is specified at execution time via a compiler option.
NESTML NESTML  (Plotnikov et al. , 2016; Blundell et al. , 2018; Perun et al. , 2018a ) is a relatively new modeling language, which currently only targets the NEST simulator  (Gewaltig and Diesmann, 2007). It was developed to address the maintainability issues that followed from a rising number of models and model variants and ease the model development for neuroscientists without a strong background in computer science. NESTML is available unter the terms of the GNU General Public License v2. 0 on GitHub (https://github. com/nest/nestml; Perun et al. , 2018b)  and can serve as a well-defined and stable target platform for the generation of code from other model description languages such as NineML  (Raikov et al. , 2011)  and NeuroML  (Gleeson et al. , 2010).
Classes can be specified by means of specifications of explicit names in the production names of attributes in the metamodel. NEST expects a model in the form of C++ code, using an internal programming interface providing hooks for parameter handling, recording of state variables, receiving and sending events, and updating instances of the model to the next simulation time step. The NESTML model thus needs to be transformed to this format (Figure  5 ). For generating the C++ code for NEST, NESTML uses the code generation facilities provided by the MontiCore workbench, which are based on the template engine Freemarker (https:// freemarker. apache. org/). This approach enables a tight coupling of the model AST and the symbol table, from which the code is generated, with the text based templates for the generation of code.