dataesr/scientific-paragraphs-categorization huggingface dataset:
Code Generation Pipeline The simulation description consists of a collection of PyNN Populations and Projections, where Populations represent a collection of neurons of a given model_class, that embodies a specific neuron model and synapse type that itself embodies a specific set of equations. For example, the PyNN IfCurExp model embodies the mathematical equations for a leaky integrate-andfire neuron  (Gerstner and Kistler, 2002)  with instantaneousrise-exponential-decay synapses. The Projections represent the physical synapses between neurons of two populations. New models therefore are represented by a new type of Population and the SpiNNaker software supports a template for creating a new neuron model and how to add this into a standard PyNN script  (Rowley et al. , 2017). In terms of data and execution, a SpiNNaker simulation consists of a set of distinct stages as shown in Figure  13 , and described here (a more detailed description of these stages can be found in  Stokes et al.
The more general framework will make it easier to support code generation, as the rules will not generally be split into the components in this fashion. The general interface for describing neuron models will utilize differential equations, such as that provided by Brian (see section 2. 1;  Goodman and Brette, 2008, 2009). Initially this would provide support for general linear systems, and the Adaptive Exponential model only. The reason for adopting this position is that SpiNNaker-1 has the limitation of expensive division and integer (or fixed-point) arithmetic only; both of these problems are eliminated in the new SpiNNaker-2 hardware, which is based on the ARM Cortex-M4F core, and thus has hardware support for single precision float and both floating-point and integer division. The obvious approach to linear ODE systems is to reduce the equations to Matrix Form.
Fitness functions can incorporate extended aspects of empirical data, enabling inference of neural mass model parameters through exploration of parameter space. A general description of the simulation can be seen in Figure  14. The current implementation of TVB is written in Python using NumPy with limited large-scale parallelization over different paramaters. The objective of the TVB-HPC project is enable such large-scale parallelizating by producing a highlevel description of models in all stages in the simulation workflow which can then be used to automatically generate high-performance parallel code which could be deployed on multiple platforms. In particular, this allows reifying data flow information. With this approach, neuroscientists can define their pre-processing kernels, coupling, neural mass models, integration schemes, and post processing kernels using a unique interface and combine them to create their own workflows.
The resulting observables are fed back to the coupling kernel and forward to a post-processing kernel to compute derived signals such as BOLD or EEG data for comparison to experimental results. Since there are no dependencies between distinct instances of the network kernel, this data flow can be parallelized over each set of model parameters. and ranges for values and access limits to the data structures to control data handling. Loopy assembles the computation within a loop-like environment where each iteration is independent. Code can then be produced for a target platform in the target's specific language. The BaseModel class has functions which translate the information provided in the attributes of a model instance in several steps which ensures the repeatable, coherent and robust generation of code.
The steps to follow in order to generate the code are as follows: 1. The kernel's data structures are generated. 2. The kernel domain is defined by setting the limits of the desired iname variable. The domain is the main loop within which the parallelization will take place, and the iname is the variable which identifies different instances of parallel executions of this loop. 3. Types for the attributes of the model are specified. Loopy can, in most cases, guess the nature of variables and attiributes, but the user can explicitly state these types as to avoid confusion in the code generation. 4. Expression for constants and distribution of the values for the input, states and parameters are generated. 5. A set of auxiliary expressions which aid the data manipulation inside the kernel may be generated.
0) 42 --------------------------------------------------- Loopy's debug output elucidate the quantitative kernel analysis. Notably, this includes complete information on the kernel's input ("ARGUMENTS": datatype, shape, strides), sequence & dataflow of instructions ("INSTRUCTIONS"), as well as temporary variables ("TEMPORARIES": type, shape, scope of allocation), and finally the loop domains, including their mapping to hardware domains ("INAME IMPLEMENTATION TAGS") such as local or global work group. As a concrete use case of TVB-HPC, a kernel which includes the whole workflow described in Figure  14  is presented. The following example shows the generation of a merged kernel including the coupling, the neural mass model and the integration step: The target code generated for Numba + CUDA:.
, 2016; Wang et al. , 2018). Currently no tools or workflows exist to directly derive an FPGA design from a neural model description. Closing this gap is a topic of research. Given the multitude of programming paradigms and architectural designs used on modern CPU-, GPGPU-, and FPGA-based systems and their complexity, it is impossible for a novice programmer in the field of neuroscience to write efficient code manually. Code generation is thus often the only way to achive satisfactory performance and system resources utilization.
Collaboration Platforms The great variety of code generation pipelines introduced in the previous sections allows neuroscientists to chose the right tool for the task in many modeling situations. However, setting up the pipelines and getting them to play nicely with the different hardware platforms can be a challenging task. In order to ease this task, several collaboration platforms were created in the past years. The Open Source Brain platform (OSB, http://www. opensourcebrain. org) is intended to facilitate the sharing and collaborative development of models in computational neuroscience. It uses standardized representations of models saved in NeuroML (section 2. 5) and shared on public GitHub (https://github. com) repositories to allow them to be visualized in 3D inside a browser, where the properties of the cells and networks can be analyzed.
In addition to viewing the NeuroML models, users who have registered and logged in to the OSB website can run simulations of the models (potentially having edited some of the parameters of the model through the web interface). The NeuroML representation is sent to the OSB server, which uses the code generation options included with the jNeuroML package (section 2. 5) to create simulator specific code which can be executed. Currently there are options to execute the model using jNeuroML (limited to point neuron models), the NEURON simulator directly, or in NEURON via the NetPyNE package (http://www. netpyne. org), which allows network simulations to be distributed over multiple processing cores. More simulation platforms are in the process of being added. The default execution location is to run the simulation on the OSB servers directly, but there is an option to package the simulations and send to the Neuroscience Gateway (NSG, https:// www.
Moreover, the Collaboratory provides access to the BrainScaleS and SpiNNaker neuromorphic hardware systems and to several European supercomputers, for which users, however, have to provide their own compute time grants. The main interface to the underlying tools are Jupyter notebooks, which can be used as collaborative workbenches for Python-based scientific collaboration between different users and teams of the system. In addition to interactive instruction, automation and exploration, the notebooks are also used for documentation and to allow neuroscientists to easily share ideas, code and workflows. For live interaction, the system integrates a web chat system. In the context of the HBP Collaboratory, neuronal description languages and code generation also serve as a means to isolate users from the system in the sense that they can still provide their own model specifications but do not require direct access to compilers on the system.
CONCLUSION In order to integrate and test the growing body of data in neuroscience, computational models have become increasingly complex during recent years. To cope with this complexity and unburden users from the task of manually creating and maintaining model implementations, code generation has become a popular approach. However, even though all code generation pipelines presented in this article try to reduce the users' load, they differ considerably when it comes to which aspects they simplify for the user. While, for example, NeuroML (section 2. 5) and NineML (section 2. 6) aim for simulator independence, and their associated code generation tools do not at present perform heavy transformations on the equations contained in a model specification, NESTML (section 2. 4) targets only NEST and analyzes the equations and tries to find the most accurate and efficient solver for them.
Myriad (section 2. 3) on the other hand has a focus on the automatic parallelization of multicompartment cells on CPU and GPGPU systems but only provides two built-in solvers. The emphasis for Brian (section 2. 1) is on the simplest possible user syntax and flexibility of the code generation process (e. g. , easily incorporating user-defined functions). One important use case of code generation in computational neuroscience is the separation of users from the underlying hardware system and corresponding libraries. The fact that platform specific code is generated from a higher-level description instead of directly written by the user allows model implementations to be generated for multiple simulators and certain parts of the execution system to be exchanged without any need for changes in the original model description.
On web-based science portals like the Open Source Brain or the Human Brain Project Collaboratory (section 3) this aspect can prevent the execution of arbitrary code by users, which increases the overall security of the systems. AS, DL, and AR are the authors of the SpiNNaker software and have written the SpiNNaker section. GT has written passages on classical processors and accelerators, EM has written the passages about neuromorphic hardware. JE and PG wrote the section about collaboration platforms. AD and TGC participated in the development of the NineML specification and the Python NineML library, and wrote the section on NineML, Pype9, and 9ML-toolkit. TGC developed PyPe9. PR, AT, CF, and DC have written the section on SpineML and GPU code generation. PR is an author of SpineML and AT is the author of libSpineML.
FUNDING The work by AM, DP, IB and JE on NESTML and the work by GT is funded by the  Excellence Initiative  of the German federal and state governments and the  Jülich Aachen Research Alliance High-Performance Computing , the  Initiative and Networking Fund of the Helmholtz Association , and the  Hemholtz Portfolio Theme Simulation and Modeling for the Human Brain. AD, AM, AS, AR, DL, DP, IB, JE, and GT received funding from the  European Union 's  Horizon 2020 research and innovation programme  under grant agreement No. 720270  and  785907  ( Human Brain  Project  SGA1  and  SGA2 ). TN was also funded by the  EPSRC  (grants  EP/J019690/1 ,  EP/P006094/1 ). RB and MS were supported by  Agence Nationale de la Recherche  ( ANR-14-CE13-0003 ). DC, PR, and AT gratefully acknowledge that this work was funded by  BBSRC  under grant number  BB/M025527/1  and  The Open Science Prize.
PR is also supported by  EPSRC  Grant  EP/N018869/1. NMODL related code generation work is supported by  NIH  grant  R01NS11613 ,  European Union 's  Horizon 2020 Research and Innovation Programme  under grant agreement No. 720270  ( Human Brain  Project  SGA1 ), and  ETH Board Funding  to the  Blue Brain Project. AP and SD-P would like to thank the funding received from the  German Federal Ministry of Education and Research (D-USA   Verbund: Mechanistische Zusammenhänge Zwischen Struktur und funktioneller Dynamik im Menschlichen Gehirn , project no. 01GQ1504B ). BM was supported by the  São Paulo Research Foundation (FAPESP) , grant  2017/04748-0. BM, and PG were supported by the  Wellcome Trust  ( 086699/101445 ).
Methods: We discuss and explain key concepts and illustrate how to conduct GWAS using example scripts provided through GitHub (https://github. com/MareesAT/GWA_tutorial/). In addition to the illustration of standard GWAS, we will also show how to apply polygenic risk score (PRS) analysis. PRS does not aim to identify individual SNPs but aggregates information from SNPs across the genome in order to provide individual-level scores of genetic risk.
knowledge of genetics, statistics, and (bio)informatics. This paper aims to provide a guideline for conducting genetic analyses by introducing key concepts and by sharing scripts that can be used for data analysis. The aim of genome-wide association studies (GWAS) is to identify single nucleotide polymorphisms (SNPs; see Box 1 for an explanation of all terms that are printed in bold throughout the manuscript) of which the allele frequencies vary systematically as a function of phenotypic trait values (e. g. , between cases with schizophrenia and healthy controls, or between individuals with high vs. low scores on neuroticism). Identification of trait-associated SNPs may subsequently reveal new insights into the biological mechanisms underlying these phenotypes. Technological advancements allow investigation of the impact of large numbers of SNPs distributed throughout the genome.
, 2012; Ruderfer et al. , 2014; Smoller, 2013; Stringer, Kahn, de Witte, Ophoff, & Derks, 2014). Even though recent GWAS have led to the identification of significantly associated SNPs for many phenotypic traits, the contribution of social scientists and clinicians to the genetics field can improve our understanding of the precise nature of the specific behavioural, cognitive, or neural correlates of identified risk SNPs. However, the analysis of genetic data requires the execution of several quality checks and careful conductance of statistical analyses to avoid spurious associations due to several potential sources of confounding (e. g. , ethnic stratification). In addition, at least a fair knowledge of genetic power calculation is necessary to avoid performing underpowered studies. For more information on how to conduct power analyses, we refer to another tutorial of our group  (Stringer et al.
, 2015). This tutorial provides a guideline to researchers who wish to incorporate genetics into their studies but do not have a formal background in this topic. First, we will show how to apply rigorous quality control (QC) procedures on genotype data prior to conducting GWAS, including the use of appropriate methods to take into account ethnic heterogeneity. Second, we illustrate commonly used tests of association between SNPs and phenotypic traits of interest while controlling for potential confounders. Third, we will show how to conduct PRS analysis. Example R and Unix scripts are provided at https://github. com/ MareesAT/GWA_tutorial/. We do not elaborate on SNP imputation of unmeasured SNPs based on reference data. Although imputation is a commonly used method in GWAS, it is beyond the scope of this article.
| SOFTWARE QC procedures and statistical analyses will be illustrated using the free, open-source whole-genome association analysis toolset PLINK version 1. 07  (Purcell et al. , 2007)  that can be downloaded from http://zzz. bwh. harvard. edu/plink/. The PLINK 1. 9 beta version contains the same options, while being much faster https://www. cog-genomics. org/ plink/1. 9/. As PLINK 1. 9 is currently a beta version, we have used the official PLINK version in this tutorial. However, it is also possible to complete all tutorials using PLINK 1. 9. Even though some of the steps discussed in this article could be performed in conventional statistical packages such as R, a software package specifically dedicated to the analysis of genetic data is much more convenient to use. In addition to PLINK, there are many other good options available for the analysis of SNP data such as Genabel  (Aulchenko, Ripke, Isaacs, & Van Duijn, 2007)  and SNPTEST  (Marchini, Howie, Myers, McVean, & Donnelly, 2007).
Furthermore, methods that allow for testing association in family-based GWAS have also been developed  (Chen & Yang, 2010; Ott, Kamatani, & Lathrop, 2011). We advise to use GNU/ Linux-based computer resources although many of the options are also available through the windows version of PLINK. A basic introduction to shells and command lines can be found at http://www. ee. surrey. ac. uk/Teaching/Unix/. All graphs generated by the GitHub example scripts will be obtained using the free, open-source programming language R (https://www. r-project. org/).
| Data format PLINK can either read text-format files or binary files. Because reading large text files can be time-consuming, it is recommended to use binary files. Text PLINK data consist of two files: one contains information on the individuals and their genotypes (*. ped); the other contains information on the genetic markers (*. map; see Figure  1 ). In contrast, binary PLINK data consist of three files, a binary file that contains individual identifiers (IDs) and genotypes (*. bed), and two text files that contain information on the individuals (*. fam) and on the genetic markers (*. bim; see Figure  1 ). For example, in a study of bipolar disorder, the *. bed file would contain the genotyping results of all patients and healthy controls; the *. fam file would contain the subject-related data (family relationship with other participants in the study, sex, and clinical diagnosis); whereas the *.
| Basic PLINK command PLINK is a command line program; hence, its usage requires an active shell waiting for commands. This can be recognized by its prompt ($ or >) just before the cursor. Often, the path of the current directory will be displayed before the prompt, as in Figure  2. The current directory is a central notion for PLINK usage, because by default, PLINK will load data files from, and save result files in this directory. The current directory can be changed to any directory using conventional Unix commands, typically cd. After the prompt, the use of PLINK is indicated by typing the plink keyword. If PLINK is not installed in a standard directory, the path to the directory where PLINK is installed has to be typed in front of the command, for instance, /usr/local/bin/plink. After the plink keyword, other options controlling PLINK's workflow will follow, separated by spaces.
These options all begin with two dashes (--). One of the first options to provide is the format and the name of the data files: use --file {your_file} for text files and --bfile {your_file} for binary files. After that, all other required options can be added, for instance, the --assoc option to perform an association analysis as displayed in Figure  2 ; this specific option will tell PLINK to perform an X 2 test for each SNP to the phenotype of interest. Multiple options can be combined within a single command line. Within PLINK, a default order is implemented, which works regardless of the order of the commands within the command line. A useful, and sometimes mandatory, option is --out {outfile}, which provides a name to output files (suffixes will be added as needed by PLINK). Beware that PLINK will delete without notice any existent file with the same name.
| QC OF GENETIC DATA A vital step that should be part of any GWAS is the use of appropriate QC. Without extensive QC, GWAS will not generate reliable results because raw genotype data are inherently imperfect. Errors in the data can arise for numerous reasons, for example, due to poor quality of DNA samples, poor DNA hybridization to the array, poorly performing genotype probes, and sample mix-ups or contamination. For instance, failing to thoroughly control for these data issues has led to the retraction of an article published by  Sebastiani et al. (2010)  in Science  (Sebastiani et al. , 2010 (Sebastiani et al. , , 2011;; Sebastiani et al. , 2012; Sebastiani et al. , 2013). The results of the retracted article were affected by technical errors in the Illumina 610 array and an inadequate QC to account for  *Not all shells will show this.
| Data simulation using HapMap data To be able to illustrate all analysis steps using realistic genetic data, we simulated a dataset (N = 207) with a binary outcome measure using the publicly available data from the International HapMap Project (http:// hapmap. ncbi. nlm. nih. gov/downloads/genotypes/2010-05_phaseIII/ plink_format/;  Gibbs et al. , 2003). For this tutorial, in order to create an ethnically homogenous dataset, we only included Utah residents with ancestry from Northern and Western Europe (CEU). Because of the relatively small sample size of the HapMap data, genetic effect sizes in these simulations were set at values larger than usually observed in genetic studies of complex traits. It is important to note that larger sample sizes (e. g. , at least in the order of thousands but likely even tens or hundreds of thousands) will be required to detect genetic risk factors of complex traits.
, 2008). More complex analyses (e. g. , Cox regression analysis and cure models)  (Stringer, Denys, Kahn, & Derks, 2016 ) can be performed by using R-based "plug-in" functions in PLINK. Example scripts for the association analyses described below are located at https://github. com/MareesAT/GWA_tutorial/ (3_Association_GWAS. zip). the preceding represents the default options in PLINK and can be changed) can be tested with the options --assoc or --logistic. The --assoc option in PLINK performs a X 2 test of association that does not allow the inclusion of covariates. With the --logistic option, a logistic regression analysis will be performed which allows the inclusion of covariates. The --logistic option is more flexible than the --assoc option, yet it comes at the price of increased computational time.
Moreover, this method has its own limitation as SNPs and thus p values are not independent whereas this is an assumption of the FDR method  (Benjamini & Hochberg, 1995). To easily apply Bonferroni and FDR correction, PLINK offers the option --adjust that generates output in which the unadjusted p value is displayed, along with p values corrected with various multiple testing correction methods. Finally, permutation methods can be used to deal with the multiple testing burden. To calculate permutation-based p values, the outcome measure labels are randomly permuted multiple (e. g. , 1,000-1,000,000) times which effectively removes any true association between the outcome measure and the genotype. For all permuted data sets, statistical tests are then performed. This provides the empirical distribution of the test-statistic and the p values under the null hypothesis of no association.
The original test statistic or p value obtained from the observed data is subsequently compared to the empirical distribution of p values to determine an empirically adjusted p value. To use this method, the two PLINK options --assoc and -mperm can be combined to generate two p values: EMP1, the empirical p value (uncorrected), and EMP2, the empirical p value corrected for multiple testing. This procedure is computationally intensive, especially if many permutations are required, which is necessary to calculate very small p values accurately  (North, Curtis, & Sham, 2003). 6 | PRS ANALYSIS 6. 1 | Computing a PRS Single variant association analysis has been the primary method in GWAS but requires very large sample sizes to detect more than a handful of SNPs for many complex traits  (Gratten, Wray, Keller, & Visscher, 2014; Visscher, Brown, McCarthy, & Yang, 2012).