dataesr/scientific-paragraphs-categorization huggingface dataset:
Populate the Database There are several possibilities to populate the database. The most direct is to fill the data directly in SQL command lines or through an external graphical tool like "PHP MyAdmin" (https://www. phpmyadmin. net) which facilitates the access and the management of a database. Some recurring operations will be easier by using some dedicated scripts that will have to be developed. For example, importing data from RNA-Seq to populate the database is almost impossible to do without using a script that retrieves the values from a raw file and converts them into SQL entries. It will then be necessary to develop a series of scripts, in Python or in a language familiar to the database manager. If the database is extended, it will be necessary to develop several scripts and to check that the logic of filling the database is respected: some tables must be filled before others, some records must be mandatory, others optional (see Note 10).
Design and Create the Main Webpages In addition to the classical sections such as a Home page describing the project and an About page displaying the various contact details, the important parts of the website will have to be decided in close collaboration with the main end-users. In our example, NvERTx presents a dedicated page for displaying the data of co-expression clusters of embryogenesis versus regeneration and a dedicated page displaying RNA-Seq differential expression by sample type. Each of these webpages are linked to selection menus allowing to display specific information. Forms to search information must be clearly visible. The entry boxes to search using terms like gene names or by IDs will be often used. They must be accessible directly, e. g. , from the left or top main menu.
Implementing Data Visualization and Mining Tools It is necessary to establish the list of features that will be required to achieve the project (e. g. , count tables, expression plots, expression clusters). These functionalities can be classified into two sets: tools to visualize the data and tools to mine the data. 1. Tools to visualize the data are a way to make the content of the database user-friendly. This interface will be important to enhance the data (gene expression profiles at different timepoints, co-expression clusters, images, annotations, etc. ), but also for editing the data. Through interactive forms, this will be a graphical way for a user to add or modify certain information contained in the database as additional annotations or new entries. For NvERTx, expression profiles and volcano plots are generated dynamically using the Plotly javascript library (https://plot.
ly/javascript/), a free and open-source graphing library (Figs. 3  and 4 ). 2. Mining tools are a way to extend the use of the data. A user can experiment two kind of actions: deep information searches, usually for nucleotides/proteins sequences, and comparisons between sets. Sequence searches are done either by entering keywords, usually annotations related to the sequence searched, or by homology by entering a given sequence and asking the system to match all the sequences like it. This last type of search is performed using tools that evaluate the degree of homology of sequences pairwise. BLASTn (used by NvERTx, Fig. 2d ) is the most popular tool for this kind of applications, but there are other tools like BLAT, USEARCH, GHOSTX, or GHOSTM which can be used, and which are generally faster.
For sequence comparisons, there is a multitude of tools that can be integrated to a web GUI. The simplest ones can consist in multiple sequence aligners like MUSCLE but can be more elaborate like using specific suite as Shiny (https:// shiny. rstudio. com) or Ploty (https://plot. ly/javascript/) which allows to mix different sets of value to generate online graphics (3D histograms, heatmaps, or more sophisticated representations).
Accessibility If the website is hosted on a local web server, unless for a strict internal use, you will need external access permissions for the site to be visible to the rest of the world. The database itself does not necessarily need to have an open access to the outside because it will go through the website. It is recommended to have a real domain name associated with the website to improve its visibility. The NvERTx website is freely and openly accessible to the community (http://nvertx. kahikai. org). The source code for the website can be found at https://github. com/IRCAN/NvER_ plotter_django. Data sets from the database can be found at http:// nvertx. ircan. org/ER/ER_plotter/about. It is highly recommended to use a Docker container system (https://www. docker. com) or similar. This system allows to encapsulate the database, the site, and all the technical requirements in a single file.
This makes the project independent of the native server environment and avoids compatibility between different versions or other websites hosted on the same server. Moreover, a container is easily exportable and installable on another server without complicated technical modifications. NvERTx uses a Docker container (https://hub. docker. com/repository/docker/ ircan/nvertx). We recommend depositing all the developments of the project (database structure, website code, API, documents) on a source code development (SCM) platform such as GitHub. This has the advantage of making the code open-source and usable by anyone. Moreover, this kind of sharing platform facilitates collaborative development of IT projects: people who want to improve the project can contribute by modifying the code. The latest version of the project can be made available from this platform.
Documentation Several documents must be provided. These documents can be text files included at the root level of the GitHub project for example. There will be a README file giving the main lines of the project, an INSTALL detailing the technical procedure to install the database and the associated code of this project, a CHANGELOG specifying the modifications made since the last update of the code. Moreover, a document specific to the practical use of the database and the website is strongly recommended. It could be a pdf that can be downloaded directly from the site detailing the data available and all the items/tools available the site or an "how to" tutorial.
Evaluating the Impact of the Database User feedback is the best way to evaluate the usage and user friendliness of a given database. Those feedbacks may not only help to improve the database usefulness itself but also for the development of any potential upgrade or future in silico database. Several tools exist to gain information on the statistics such as number, origin, session durations, etc. of the database users (e. g. , GOOGLE analytics). However, certainly the most valuable evaluation factor for scientific databases is its referenced usage by the larger scientific community, i. e. , the resulting citations or collaborations. Thus, providing information on how to cite the database is crucial and should be implemented in the webpage (e. g. , the FAQ section).
Notes 1. A unique file containing genome sequence + annotations (. gbk or. embl) could also be provided instead, but is less useful since the integrated webtools usually needs fasta or gff as separate files, i. e. , the blast database indexing requires fasta format only. 2. If no transcriptome is available or if the database manager prefers to use its own transcriptome, the file must be a single fasta file. Each entry in the file has to be a single transcript sequence and the related description should preferably contain some useful IDs to be used for crossing with other databases (e. g. , Ensembl, ReSeq, nt). 3. It is possible to add usual short annotations directly into the description lines of the transcriptome fasta file: GeneSymbol name, ortholog names/IDs, GO term ID, or other information specific to the transcript.
4. MySQL is an open-source relational database management system widely used in the biology field. Its capabilities allow to support a high number of entries as well as a powerful engine for complex queries. For small databases is also possible to use SQLite instead, having the advantage to be lighter and using an independent file system for storing data. Like the webserver, prefer to install and run your database server into a separate Docker container. 5. Another option is to use "Ruby on Rails" (https://rubyonrails. org) instead of Django. This framework is similar to Django with some differences like a fully object-oriented language with a more powerful frontend part. Ruby is probably slightly more difficult to handle for beginner developers. 6. Start from your personal / the labs' needs and exchange with the community to determine additional functionalities to be Often additional functionalities arise during the test phase of the database/website.
Once launched, consider taking users' feedback for a future update of the data mining tools. 7. Some data require high amount of space storage such as raw sequence or high-definition images. They can be stored outside the database, in files. Exporting this big data will keep the database quite light; however, it will be required to add links to these external files into the database (system directory paths, external URLs, etc. ). 8. The database should be modular enough to allow additional tables or fields in the future. 9. Apply the traditional rules of database design, i. e. , to avoid redundancy, to propose unique keys for each table, to organize the data in the different tables in a way that is neither too large nor too small, and to create intermediate tables containing the keys of the tables whose records are to be crossed.
We advise to carefully read up some documentation on relational database conception to avoid certain errors because it can be very difficult to modify the structure of the database once it contains the data and starts to be used. 10. The development of these small pipelines can be organized in such a way that it will constitute a real Application Programming Interface (API), which can be reused during the construction of the website. 11. The code and the SQL queries generated when validating the forms must be clear and modular. The possible APIs developed to fill the database can be reused here. The developer can use free existing templates and CSS files to build the site, or he can decide to develop the site from scratch. He can also use a content management system (CMS) to set up the website (such as Zope for Django), but we do not advise this solution as these CMS are not appropriate for very specialized sites like NvERTx.
Whole brain network models are now an established tool in scientific and clinical research, however their use in a larger workflow still adds significant informatics complexity. We propose a tool, RateML, that enables users to generate such models from a succinct declarative description, in which the mathematics of the model are described without specifying how their simulation should be implemented. RateML builds on NeuroML's Low Entropy Model Specification (LEMS), an XML based language for specifying models of dynamical systems, allowing descriptions of neural mass and discretized neural field models, as implemented by the Virtual Brain (TVB) simulator: the end user describes their model's mathematics once and generates and runs code for different languages, targeting both CPUs for fast single simulations and GPUs for parallel ensemble simulations.
High performance parallel simulations are crucial for tuning many parameters of a model to empirical data such as functional magnetic resonance imaging (fMRI), with reasonable execution times on small or modest hardware resources. Specifically, while RateML can generate Python model code, it enables generation of Compute Unified Device Architecture C++ code for NVIDIA GPUs. When a CUDA implementation of a model is generated, a tailored model driver class is produced, enabling the user to tweak the driver by hand and perform the parameter sweep. The model and driver can be executed on any compute capable NVIDIA GPU with a high degree of parallelization, either locally or in a compute cluster environment. The results reported in this manuscript show that with the CUDA code generated by RateML, it is possible to explore thousands of parameter combinations with a single Graphics Processing Unit for different models, substantially reducing parameter exploration times and resource usage for the brain network models, in turn accelerating the research workflow itself.
To this end, we have developed RateML, a modeling workflow tool that uncouples the specification of Neural Mass Models (NMMs) and Brain Network Models (BNMs) from their implementations as machine code for specific hardware. It is based on the existing domain specific language 'Low Entropy Model Specification' (LEMS;  Cannon et al. , 2014) , which allows the user to enter declarative descriptions of model components in a concise XML representation. RateML enables users to generate brain models based on an XML format in which the generic features of rate-based neuron models can be addressed, without needing extensive knowledge of mathematical modelling or hardware implementation. In addition to providing code generation of the described models in Python, it is also possible to generate Compute Unified Device Architecture (CUDA)  (NVIDIA et al.
, 2020)  code in which variables of interest can be designated with a range for parameter exploration. The generated Python code can be directly executed within the TVB simulation framework, whereas the CUDA code has a separate driver module which is also generated before execution. The generated driver module enables the user to perform the explorations on any CUDA capable Graphics Processing Unit (GPU). In this article we describe and benchmark the model generator RateML. In addition to the performance of the generated models, we investigate the maximum capacity for parameter sweeps and the scaling of the application on HPC. This article is structured as follows: after a summary of the state of the art in Section 2, we describe the model generator and the elements which are the building blocks for both the Python and CUDA models in Section 3.
We then employ a use-case derived from a study on the impact of neuronal cascades on the causation of whole-brain functional dynamics at rest  (Fox and Raichle, 2007)  as a scaffold to demonstrate how to set up an existing model and validate it. In this study a parameter space exploration on two parameters of the Montbrió NMM is performed. Section 4 details the steps taken to express the Montbrió NMM in RateML. For the validation of the models generated by RateML, we reproduce the study's parameter space exploration and analyse the results of this in Section 4. 2. In Section 5, we examine the benchmark results for the Python and CUDA frameworks, comparing the Kuramoto  (Kuramoto, 1975) , Reduced Wong Wang  (Wong and Wang, 2006)  and Epileptor  (Jirsa et al. , 2014)  models. From the benchmarks we observe that the application scales linearly with parameter space size and that it is memory bound.
, 2010)  is able to describe single cells and networks of cells, and NineML  (Davison, 2013)  focuses on networks of point neurons. Some simulators such as GeNN  (Yavuz et al. , 2016)  and Brian  (Stimberg et al. , 2019)  provide their own pipelines to transform abstract representations of models either in C or in Python and transform them into efficient executable code. Here, we focus on frameworks suitable for representing the dynamic variables of mesoscopic brain activity models. One such framework mentioned by  Blundell et al. (2018)  is LEMS, a metalanguage designed to generate simulator-agnostic domain-specific languages (DSL) for graph-like networks  (Cannon et al. , 2014). Each node can have local dynamics described by ordinary differential equations, using the provided standardized structured descriptions.
When the models are described in the LEMS XML format, a one-to-one mapping of these abstract components to the simulator specific functionality in the model file can be performed. The Mako templating library written in Python is well suited for such operations. Mako is an embedded Python language providing placeholders and logic to build a template from the ordered LEMS components. Mako is fast and supports Python control structures such as loops and conditionals, and code can be organized using callable blocks. LEMS is a strong standard for the description of neural models and networks, used by a variety of simulators from the neuroscience community. It offers a set of generic building blocks, but currently, no domain specific language building on LEMS supports the whole variety of features required to express BNNs and NMNs.
For example, if a user would like to perform large parameter explorations on models defined with the standard LEMS, she would need to rely on external software to coordinate the execution of parallel instances of the model on the target computing resources, also considering configuration and computing/memory access performance. As an alternative to LEMS, PyRates is a Python framework that provides intuitive access to and modification of all mathematical operators in a graph  (Gast et al. , 2019). This enables a highly generic model definition. The aim of PyRates is to configure and simulate the model with only a few lines of code. Each model must be represented by a graph (circuit) of nodes and edges. The nodes represent the model units (for example, the cell populations) and the edges represent the information transfer between them.
Individual network nodes consists of operators, which define scopes in which a set of equations and related variables are uniquely defined. The mathematical syntax closely follows the conventions used in Python. Vector and higher-dimensional variables may be used and it follows the conventions of NumPy  (Harris et al. , 2020). For the actual simulation, the user can choose between two backend implementations. The first is the default NumPy backend which provides relatively fast simulations on a single CPU, or on multiple CPUs in combination with the Python distribution provided by Intel. The second is the Tensorflow 2. 0 implementation, which makes use of dataflow graphs to run parallel simulation on CPUs or GPUs  (Abadi et al. , 2015). It can also apply vectorization, which reduces identical nodes to one vectorized node.
PyRates offers parallelization based on the inherent capabilities of Tensorflow. This generic approach has the downside that it does not optimize the parallelization depending on specific characteristics of the model to be executed. Therefore, there is still a need for an automatic code generation framework that not only shares important qualities of the aforementioned tools, such as compact model specification and direct connection to simulation backends, but that is also able to support parameter sweep specification and highly optimized model-specific code generation.
THE RATEML FRAMEWORK In this manuscript we present RateML, a tool that enables users to generate BNNs and NMNs from a declarative description in which the mathematics of the model are described without specifying how their simulation should be implemented. Furthermore, RateML provides language features that permit parameter sweeps to be easily specified and deployed on high performance systems. By building on LEMS, RateML joins a widely used standard which is in continuous development. RateML is able to automatically generate code which can be executed on CPUs and CUDA-compatible GPUs. RateML's optimized CUDA backend takes full advantage of the device in order to maximize the occupancy based on the characteristics of the model like state variables and memory requirements. RateML also offers a Numba-based vectorized backend for execution on CPUs.
In case of the latter, a generalized universal function using Numba's guvectorize decorator is generated. Using this decorator, a pure Python function that operates over NumPy arrays can be compiled directly into machine code. This is as fast as a C implementation and it automatically uses features such as reduction, accumulation and broadcasting to efficiently implement the algorithm in question  (Lam et al. , 2015). This section provides an overview of the implementation of the RateML framework which supports the definition of models and generation of both Python and CUDA code.
RateML Syntax LEMS was originally designed to specify generic models of hybrid dynamical systems  (Cannon et al. , 2014). The LEMS language can be used to define the structure and dynamics of a wide range of biological models. The ComponentType building blocks can be defined as templates for model elements. Many of the ComponentTypes used in LEMS have a one-to-one mapping with the building blocks that make up the models for the TVB simulator. For instance, TVB has models which are defined by the dynamics of state variables represented by time derivatives, for which LEMS has placeholders. For these reasons, we adopted LEMS to create the code generation tool RateML, using the ComponentTypes as place holders to build and directly parse the NMMs dynamical models. Because not all ComponentTypes are necessary for the TVB models, RateML implements its syntax on top of a subset of components from LEMS.
1. 3 describes how stochastic integration is enabled. The Python models only require the definition of the time derivatives, while the CUDA models also require the parameter space exploration (PSE) to be configured and the coupling and stochastic integration of the time derivatives to be defined (if needed by the modeller). An empty XML template called model_template. xml, can be found in the XMLmodels folder of RateML in the TVB repository 1  and can be used as a blank template to start the construction of a model. The same folder hosts XML examples of the Kuramoto, Wong Wang, Epileptor, Montbrió, and Generic 2D oscillator models. Further documentation is also available in this repository. Listing 1 XML derivatives definition for the CUDA Kuramoto model.
Stochastics Listing 3 XML stochastics definition for the CUDA Kuramoto model. To enable stochastic integration, a ComponentType with the name noise can be defined, see Listing 3. As discussed above, this is only implemented for the CUDA variant. The CUDA code generation makes use of the Curand library (NVIDIA, 2008) to add a normal distributed random value to the calculated derivatives. This corresponds to term C in Eq 1. As mentioned in Section 3. 1. 1, if the derivatives ComponentType has a derived parameter with the name nsig, a noise amplification/ attenuation is applied to the noise before it is added. In listing 1 an example of this derived parameter is shown on line 7. In this case the value for nsig is dt √ p 2. 0p1e -5 √ , which acts as a multiplicative term to the noise term and is a commonly used attenuation in TVB.
XML to Model When the XML file is complete, the NMM can be generated. RateML is part of the TVB main repository; installing TVB through: pip install tvb-library also installs the command line interface operated RateML. To use RateML, a user must import and create an object of the RateML class, enter the arguments model filename, language, XML file location and model output location, and run the code: or run from command line: The XML file is converted into a model file using the Mako template engine for Python. When a model generation is started, the flow depicted in Figure  2  is started. The PyLEMS  (Vella et al. , 2014)  expression parser is used to check and parse mathematical expressions of the XML file. The expression parser embedded in the LEMS library recognises a variety of fundamental mathematical function and operators 2.