dataesr/scientific-paragraphs-categorization huggingface dataset:
CupCarbon Architecture CupCarbon is developed in Java. Its architecture consists of two layers: The first layer concerns the modules used to build the simulation. The second layer concerns the simulation itself. Figure  6  shows the different modules of CupCarbon. Four main modules can be distinguished: • Agents Module: it includes devices and events necessary to prototype wireless sensors networks and to prepare and configure the simulator. • OpenStreetMap Module: it allows designing wireless sensors on an OSM map. • WiSen Simulator Module: it allows to simulate wireless sensor networks. This module is connected to the simulator agents. • Solver Module: it integrates a set of optimisation algorithms such as routing, coverage, etc. The current version integrates an algorithm for solving the set covering problem used to determine the minimum number of sensors that detect the maximum of targets.
Simulation Setup Once the CupCarbon tool is started and a new project is created, it is possible to create a network of sensors directly on a geographical map which represents the main window of the software. It is possible to create routes to be assigned to mobiles. It is also possible to create mobiles, gas and a cloud of insects. For the sake of simplicity, we have chosen as an example a simple network consisting of eight sensors as shown in Figure  9. Once the network is developed, the different communication scripts must be created and assigned to each sensor. One script can be assigned to multiple sensors. In our case, we create a single script that is assigned to all sensors. The script is shown in Figure  10. This script allows a sensor to send 10 bytes with the maximum signal power (100%).
Material and methods aCGH analysis was carried out in 37 non-syndromic individuals that clinically presented with either one or a combination of aforementioned phenotypes. Of which, 13 cases had congenital anomalies with or without mental retardation [Group-1]. Remaining 24 cases presented developmental and learning disabilities with seizure [Group-2]. Conventional cytogenetic [GTG-] banding analysis showed apparently normal chromosomal pattern at 550-band resolution. Hence, all 37 cases were further analyzed using Agilent 60k oligonucleotide array-Comparative Genomic Hybridization (aCGH). Sex matched genomic DNA (Promega Corporation, Madison, WI, USA) was used as reference. Relative fluorescence intensity data was analyzed with the aCGH analysis software v3. 4 (Agilent Technologies Inc. , Santa Clara, CA, USA) by applying Z-score segmentation algorithm with a window size of 10 points to identify chromosome aberrations.
TheVirtualBrain (TVB) is a neuroinformatics Python package representing the convergence of clinical, systems, and theoretical neuroscience in the analysis, visualization and modeling of neural and neuroimaging dynamics. TVB is composed of a flexible simulator for neural dynamics measured across scales from local populations to large-scale dynamics measured by electroencephalography (EEG), magnetoencephalography (MEG) and functional magnetic resonance imaging (fMRI), and core analytic and visualization functions, all accessible through a web browser user interface. A datatype system modeling neuroscientific data ties together these pieces with persistent data storage, based on a combination of SQL and HDF5. These datatypes combine with adapters allowing TVB to integrate other algorithms or computational systems.
TVB provides infrastructure for multiple projects and multiple users, possibly participating under multiple roles. For example, a clinician might import patient data to identify several potential lesion points in the patient's connectome. A modeler, working on the same project, tests these points for viability through whole brain simulation, based on the patient's connectome, and subsequent analysis of dynamical features. TVB also drives research forward: the simulator itself represents the culmination of several simulation frameworks in the modeling literature. The availability of the numerical methods, set of neural mass models and forward solutions allows for the construction of a wide range of brain-scale simulation scenarios. This paper briefly outlines the history and motivation for TVB, describing the framework and simulator, giving usage examples in the web UI and Python scripting.
INTRODUCTION Neuroscience has evolved through extensive interactions among disciplines to advance our appreciation of the relation between brain and behavior. The interdisciplinary nature of the field presents formidable challenges for effective collaboration. These challenges call for two kinds of solutions. First, there is a need for comprehensive, modern computational libraries written in widely used and available programming languages; current examples include MNE-Python  (Gramfort et al. , 2013) , a Python package for treating M/EEG data via time-frequency analyses and inverse solutions and the Brain Connectivity Toolbox  (Rubinov and Sporns, 2010)  for analyzing the graph theoretic properties of structural and functional connectivity. Second, there is a need for the implementation of collaborative infrastructure for sharing not only data, but expertise; CARMEN  (Austin et al.
, 2011)  and G-Node  (Herz et al. , 2008)  are two such examples of developing platforms for collaborative work and data sharing, in the domains of cellular and systems neurophysiology. TheVirtualBrain (TVB) provides new tools to facilitate the collaboration between experimentalists and modelers by exposing both a comprehensive simulator for brain dynamics and an integrative framework for the management, analysis, and simulation of structural and functional data in an accessible, web-based interface. The choice of Python was made based on its wide use as the high-level language in scientific programming, the unparalleled open-source libraries and tools available, and strong software engineering culture. This choice was confirmed by the publication of the first issue of Python in Neuroscience and has made it possible for the entirety of TVB from the numerical algorithms to the web server to be written in Python.
OVERVIEW TVB consists of a framework and a simulator. The framework manages projects involving various data, subjects, and users and the different roles that the users might play in the projects  (modeler, clinician, etc. ). The framework also maintains a database of the different operations performed by the users in each project as well as the various data associated with those operations, such as structural and functional neuroimaging data. The simulator provides numerical methods to construct and simulate models based on human cortical and sub-cortical anatomy and dynamics. It employs principally a neural mass approach, incorporated realistic long-range (delayed) and short-range connectivity kernels, as well as stochastic fluctuations. To make the connection with experimental data, it provides forward solutions to compute neuroimaging data (fMRI, M/EEG) from the underlying neural dynamics.
OBTAINING AND USING TVB The easiest way to get started with TVB is to download a distribution 1  , which is available for Windows, Mac OS X and Linux. This distribution includes all of pieces, from the simulator to the web interface, and has no requirements other than a modern web browser supporting WebGL, SVG and HTML5. Alternatively, because TVB is licensed under the GPL v. 2, the sources may be readily obtained from the public Git repositories hosted on GitHub 2   (Dabbish et al. , 2012). In order to use the simulator, only the standard scientific Python packages are required (NumPy and SciPy). The framework and web interface depend on a few more packages. Documentation including an installation guide, web interface and console user guides as well as other information are available online.
ARCHITECTURE TVB's architecture, illustrated in Figure  1 , was designed for the integration of disparate computational tools, allowing different kinds of data to be managed within one system, and different routines and processes to work with the kinds of data in the system. To facilitate this integration, two abstractions have been introduced, around which the framework is oriented: datatypes and adapters, serving, briefly, as heavily annotated structures and functions allowing for programmatic interoperation with the database and generation of and interaction with the user interface.
DATATYPES Concretely, a TVB datatype is a Python class with one or more attributes that are traits, where a trait specifies both the kind of data expected for the corresponding attribute, as well additional metadata to aid in storage and user interface construction. During the development of the datatype and traits system, existing implementations of the concepts of traits were considered, notably Enthought's extensive implementation designed to accelerate the design of graphical scientific applications and IPython's lighter-weight system designed, to a large extent, to provide a robust configuration system. In both cases, the traits are used to explicitly specify types, allowing runtime values' types to be validated, as well as other forms of introspection. This is the case for TVB's traits as well, however, Enthought's implementation has significant compiled extensions (where TVB is intended to be pure-Python); IPython's implementation does not provide support for arrays, and neither provides integration or mapping to a database.
Lastly, Nipype  (Gorgolewski et al. , 2011)  provides an approach specifically targeted toward neuroimaging, but is focused on data processing, whereas TVB required database and UI integration. For these reasons, it was judged useful to develop a system adapted to the needs of TVB. class Point2D(MappedType): x = Float(label="x", doc="horizontal position of point") y = Float(label="y", doc="vertical position of point") Code 1: Example of a simple datatype modeling a point in two dimensions. Listing 1 shows a datatype modeling a point in two dimensions, consisting of two floating point values, x and y. This class derives from MappedType whose metaclass, before creating the class object, filters attributes for trait instances or types and creates a corresponding SQLAlchemy model, which results in mapping instances of Point2D to a corresponding table in TVB's SQL database.
The trait base class implements a data descriptor protocol, i. e. , __set__ in addition to __get__ methods, which, for a MappedType instance, forwards calls to the get and set methods to the corresponding SQLAlchemy method, in turn, interacting with the database. When methods of such a class with annotated attributes are invoked, they may use the traited attributes directly, accessing either a default value or one given during the instantiation of the object. Additionally, this allows the web-based user interface to introspect a class for all of its attributes and their descriptions, to provide help and choose the proper display form. The explicit typing also allows such classes to be nearly automatically mapped to storage tables, providing persistence, when the storage layer is enabled. Lastly, because such metadata is used to build the docstring of a class, the console user also may obtain extensive descriptions of class, attributes, methods and arguments in the usual way.
ADAPTERS The adapter pattern allows arbitrary processes to be invoked by a generic framework by detailing the required input data, the outputs, and providing a method for invoking the process. The input and output data are described in terms of TVB's datatypes, which allows processes with different data formats to interact as long as an intermediate, common datatype is available. In TVB, this abstraction extends not only to computational processes such as simulation and analysis, but data import, export and, notably visualizations. class DistanceAdapter(ABCAdapter): def get_input_tree(self): return 'p': Point2D(), 'q': Point2D() def get_output(self): return [Float] def launch(self, x, y, sqrt=math. sqrt): return sqrt((p. x -q. x) ** 2 + (p. y -q. y) ** 2) Code 2: Example of a minimal adapter.
This script is with MATLAB or Octave via a call to the os. system function. Several alternatives to this approach are possible, such as invoking the MATLAB engine directly via ctypes and the MATLAB Engine API, or compiling the MATLAB functions with the MATLAB Compiler. Each, including our approach, has advantages and disadvantages. In our case, when configuring TVB, the administrator is asked to provide the path to the MATLAB or Octave executable, and TVB attempts to verify that this executable can be invoked. Beyond this, no other verification or protection is currently provided against problematic situations, in part because we have found it to be sufficiently robust. Launching MATLAB can be a relatively slow operation (cold startup 8 s, cached 1 s; on a Linux workstation), and where Octave is available, it is faster (0.
1 s). For our use cases, e. g. , launching analyses, this works without problems in a single user situation. In the case that many operations are necessary, they can be batched into the same script such that MATLAB is called but once. One of the uses of this adapter, employs a well-known toolbox for characterizing anatomical and functional connectivity, the Brain Connectivity Toolbox  (Rubinov and Sporns, 2010). In TVB, the set of functions, their inputs and outputs are summarized in an XML file, which is read by a generic adapter, which handles the data appropriately.
Analysis and visualizers TVB does not intend to provide fully featured, complex data analysis techniques, which have been well covered by other packages. Instead, we offer a minimal set of standard algorithms to quickly validate simulation results or compare with imported patient data; these include principal and independent component analyses, Fourier and wavelet spectral analyses, correlation and coherence analyses. TVB visualizers employ different techniques, depending on the nature of the data to display and degree of interactivity required, including WebGL, D3. js generated SVG, Matplotlib's HTML5 Canvas backend, as well as other HTML5 Canvas Javascript libraries for simpler, static graphs. In each case, an adapter is developed to abstract over the differences between these techniques, allowing the framework to treat it without knowing the details.
In TVB the network is defined with neural mass or field models  (Deco et al. , 2008; Coombes, 2010)  rather than cellular models. The spatial extent of the modeled dynamics is macroscopic and scales reasonably to the entire cortex, and uses empirical measurements of corticocortical connectivity. Several technical issues are unique to this scale, such as efficient handling of dense N 2 inter-regional delays and integration of neural field-like models and connectivity on triangular meshes in 3D. Finally, comparison with experimental data requires forward solutions that transform physiological signals to the commonly used imaging modalities such as EEG, MEG and fMRI. For these reasons, TVB required a new simulator, built around the paradigm of whole-brain scale simulation. The simulator in TVB resembles popular neural network simulators in many fundamental ways, both mathematically and in terms of informatics structures, however, we have found it necessary to introduce auxiliary concepts particularly useful in the modeling of large scale brain networks.
FORWARD SOLUTIONS TVB provides forward solutions to generate neuroimaging data from simulated neural activity based on biophysical models  (Jirsa et al. , 2002; Buxton et al. , 2004). Practically, it is also often necessary to simply reduce the size of data, especially in the case of surface simulations. TVB implements these two functionalities in a set of classes called Monitors, each of which receives the raw simulation output and applies a spatial, temporal or spatiotemporal kernel to the output to obtain the simulation output passed to the user or stored. Where necessary, monitors employ more than one internal buffer. In the case of the fMRI monitor, a typical sampling frequency of simulation may be upward of 64 kHz, and the haemodynamic response function may last several seconds, using only a single buffer could require several gigabytes of memory for the fMRI monitor alone.
PERFORMANCE A priority of the simulator in TVB is to attain a high level of performance while remaining in pure Python. In order to see where the simulator spends most of its time, we have profiled a set of eight characteristic simulations on function timing as measured by the cProfile module of the standard library. Measurements were performed on an HP Z420 workstation, with a single Xeon E5-1650 six-core CPU running at 3. 20 GHz, L1-3 cache sizes 384, 1536, and 12 MB, respectively, with main memory 4 × 4 GB DDR3 at 1600 Mhz, running Debian 7. 0, with Linux kernel version 3. 2. 0-4-amd64. The 64-bit Anaconda Python distribution was used with additional Accelerate package which provides acceleration of common routines based on the Intel Math Kernel Library. A Git checkout of the trunk branch of TVB was used with SHA 6c644ab3b5.
Eight different simulations were performed corresponding to the combinations of either the generic 2D oscillator or Jansen-Rit model, region-only or use of cortical surface, and two conduction speeds, v c = 2. 0 and v c = 20. 0 (m/s). In each case, a temporal average monitors at 512 Hz is used, and the results are discarded. The region-only simulation was run for 1 s while the surface simulation was run for 100 ms. As can be seen in Table  2 , significant time is spent on array manipulations written in C (marked by those function names surrounded by angle brackets), from the NumPy and SciPy libraries, including the spare matrix-vector multiplication used to compute the local connectivity. In some cases, such as the neural mass model definitions, large expressions implicitly generate many temporary arrays, which can be ameliorated by using the numexpr module to compute the expressions element-wise: TVB's JansenRit model is implemented as regular Python expressions of NumPy arrays, while a subclass JRFast uses numexpr.
evaluate, resulting in a 40% improvement in overall runtime. Given that the numerical routines are written in Python to maintain a high level of flexibility, it is expected that there are limits on the performance, especially compared to compiled languages. Ongoing work on the simulator will take advantage of newer programming paradigms and hardware, such as OpenCL and graphics processing units; this sort of programming is facilitated by Python libraries such as PyOpenCL  (Klöckner et al. , 2012).
FUTURE WORK Since the recent release of the 1. 0 version of TVB, it has been officially considered feature complete, however, in several cases, the development of features has outstripped documentation and testing. Going forward, general priorities include advancing test coverage, improving documentation for users, and preparing PyPI and Debian packages. In the mean time, TVB's Google groups mailing list continues to provide an open forum for troubleshooting and sharing of user experiences. While several mathematical challenges are presented by the TVB models, one of the bottlenecks is the speed of the numerical simulation. To address this, continued optimization of C and GPU code generation will take place, e. g. , to perform parallel parameter sweeps. Additionally, an interface from MATLAB to TVB is being developed to allow use of the simulator through a simple set of MATLAB functions.
ACKNOWLEDGMENTS Several authors have also participated in the development of TVB. They are listed in the AUTHORS file of the source code and deserve our warm acknowledgments. Laurent Pezard wishes to thank specifically  Y. Mahnoun  for his role in the design and development of the first prototype of the TVB architecture. The authors wish to thank two anonymous reviewers for their constructive comments and questions. The research reported herein was supported by the  Brain Network Recovery Group  through the  James S. McDonnell Foundation  and the  FP7-ICT BrainScales. Paula Sanz-Leon  and  M. Marmaduke Woodman  received support by from the  French Ministère de Recherche  and the  Foundation de Recherche Medicale.
Ascending order for indices is considered when displaying use_storage When False, current attribute is not stored in database or file storage file_storage Valid values for this attribute are: None , HDF5, or expandable_HDF5, When None, current attribute is not stored in the file-storage at all. When HDF5, we use regular HDF5 file storage When expandable_HDF5 value is set, a HDF5 stored in chunks is used.
The application and assessment of our method is performed in line with the efforts of the IMILAST project. We used the same time periods and input data sets in order to make our results comparable with those of the aforementioned project. In Sect. 2 we describe cycloTRACK in detail, our cyclone detection and tracking algorithm. In Sect. 3 we present the results of several sensitivity tests of our method, applied to the ERA-Interim (ERA-I) data set for the winters (December-January-February) of the period  1989 -2009. Finally, Sect. 4  presents the conclusions and our prospects for future research.
Identification and tracking algorithm In this section we present our algorithm, cycloTRACK, and its application to the vorticity fields at 850 hPa level within the extratropical latitudes of the Northern Hemisphere during the winters of 1989-2009. We use meteorological data from the 6-hourly ERA-I reanalyses with a horizontal resolution of 1. 5 • × 1. 5 •  (Uppala et al. , 2008). The algorithm is composed of two independent steps. In the first step, we identify all cyclonic features for all time steps of a data set, and in the second step we build the cyclone tracks.
For example, our algorithm would not choose the track passing from the points 2(12), 3(4) and 4(8) in Fig. 3 , since the consecutive displacements present an angle of 74 • (marked in red), which is less than the 90 • threshold. Finally, cycloTRACK returns one matrix as output for each track that contains information on the cyclone's track and its physical characteristics. Each matrix has one row for each of the track points and one column for each of the standard outputs and the optional physical diagnostics. These optional output diagnostics may vary depending on the study and the data inputs. Labeling the cyclonic circulations (Sect. 2. 1. 1) and the cyclonic centers (Sect. 2. 1. 2) within the tracks permits a post-processing analysis for determining potential merging and splitting of cyclones.
Sensitivity of filtering the relative vorticity field We tested three different filter strengths (described in Sect. 2. 1. 1) with the ERA-I data set. The applied spatial filters correspond to 3 × 3, 5 × 5 and 7 × 7 grid point filtering, named filter3, filter5 and filter7, respectively. Figure  6a  presents the number of detected cyclonic centers as a function of their relative vorticity for all three sensitivity tests, and Fig. 6b  presents their relative frequency. Since all tests are bounded to identify cyclones exceeding a common threshold of 3 × 10 -5 s -1 , and since filtering decreases the relative vorticity values due to its smoothing operation, it is not surprising that the total number of detected cyclone centers is reduced with increasing filtering intensity. Regardless of the spatial filtering strength, all three sensitivity tests present an exponential distribution (Fig.
(1998)  and  Inatsu (2009)  to link enclosed areas. This decision was made because large cyclonic circulations would not correspond to a single cyclone if enclosed areas were linked, and additional criteria -and/or filtering -would be needed, while weak cyclones would be neglected. Further development of our algorithm includes the extension of the identification part to three dimensions and the extension of the method's adaptability for different atmospheric features such as MCSs. CycloTRACK was implemented in MatLab, and its source code is freely available from the corresponding author upon request.