dataesr/scientific-paragraphs-categorization huggingface dataset:
VIOLA is designed around the information-seeking mantra and the concept of coordinated multiple views. 2D and 3D visualizations support the exploration of neuronal activity across space and time. The software can display raw spiking output as well as spatiotemporally binned data that may represent instantaneous spike counts gathered from nearby groups of neurons. Spike and LFP data can be displayed simultaneously, thus allowing for a multi-modal analysis. The manuscript is organized as follows: In Results we present different visualization types and their application. Subsequently (Methods) we describe their implementation in the visualization tool VIOLA, the example network model and the phenomenological model for the LFP signal. Finally in Discussion and Outlook we conclude our work and discuss general limitations of frameworks for explorative visualization and potential future developments.
Throughout this section, we use the spike output of the point-neuron network introduced in the Introduction as an example to demonstrate appropriate visualization types in an interactive and multi-view framework. Neurons in this network are placed in 2D sheets, and connections are drawn using distance-dependent probabilities between pairs of neurons. The model represents spatially heterogeneous neuronal activity across a 4 × 4 mm 2 cortical sheet. As we here focus on visualization methods in VIOLA, we refer the reader to Sections 3. 4-3. 5 for the details on our network implementation in NEST  (Kunkel et al. , 2017) , Python-based preprocessing steps and predictions of a mesoscopic population signal, the local field potential (LFP). We next describe in detail the different views of VIOLA and their use cases.
Views of VIOLA VIOLA incorporates two conceptually different visualization types with two separate 'views' each. The first visualization type (view 1 and view 2 in Figure  3 ) focuses on instantaneous snapshots of data across space. The second visualization type (view 3 and view 4 in Figure  4 ) shows time series of data. We first present the visualizations of preprocessed data described in Section 3. 1. Views 1-3 may also be used to visualize raw data (non-preprocessed) as shown in Figure  5.
Reference implementation We have made implementations of the visualization types discussed throughout this paper available in the tool VIOLA (VIsualization Of Layer Activity). Figure  10  illustrates the web-based JavaScript framework integrating the different visualizations we refer to as views. A central class named Main carries out the initialization and coordination of the views. The Graphical User Interface (GUI) is comprised of two main components, the Setup Panel and the Main Panel. The Main Panel also serves as a container for the views. The Setup Panel is the first entity presented to the user when the application is opened in a web browser. It serves mainly to specify the data types to be loaded and the basic data features (spatial dimensionality, time resolution) and visualization features such as the colors for each neuron population.
VIOLA whether to load raw or preprocessed data. These configuration files are JavaScript Object Notation 7  (JSON) files specifying the format of the loaded data, file names, and preset values for the visualizations. After confirming the entered information, the Main. setup() function extracts the entries and provides them globally to the other components. The Main Panel shown afterwards is used to load the input data files from the local file system using JavaScript FileReader, which includes setting up the internal data structure giving a coherent access to the data to be visualized. The Main. init() function then initializes the rendering loop, which is built into the web browser and controls the rendering of the various views. The Main. render() method is executed periodically by built-in functionality of the browser, which is further used to synchronize the rendering of all views.
2D and 3D view implementations This section describes the visualization algorithms used with the different view implementations in VIOLA as introduced throughout the Results. As the output data produced by the simulation are scalars organized on a regular grid (related to the neuron's position), visualization methods applicable to scalar data are employed as well as standard chart types  (Hansen and Johnson, 2011). View 1 implements a standard image plot in which the color of each spatial bin represents a spike-count rate value. The display maps a binned measure of neuronal activity on a color by using a lookup table ranging from black to white over red and yellow (often referred to as 'red hot' or 'white hot' lookup table). We selected this lookup table as it is widely used and offers (if non-linear interpolated) equidistant colors according to the CIE L*a*b* color space  [EN ISO 11664-4 from 1976]   8.
This color space is designed to represent equidistant colors according to human perception: a color twice as light in CIE L*a*b* space is also perceived twice as light by a human user  (Fairchild, 2013). Such a heat map  (Spence, 2001)  facilitates the representation of the spatial structure of the data. In the 3D visualization of view 2, VIOLA also implements a geometrical mapping of activity data to a cube's edge length, resulting in a cubic mapping of the single scalar value representing activity at each time step. The default scaling of the cube's edge length is such that the cube's volume is proportional to the data value in each bin. In view 3, the concept of a stacked bar chart supports a global perspective on the simulated model  (Spence, 2001). Individual populations in the model are color-coded to be separable in the bar chart.
The original parameters for the EX-IN network in the NEST example are modified for this VIOLA use case demonstration bringing the network in a state with spatially confined network activity. For this we increase the network's neuron count, reduce the ratio of inhibitory to excitatory weights g Y,IN and the membrane capacitance C m , while the postsynaptic amplitude J is increased. The parameter J is originally defined in units of mV, but is here re-defined in units of pA. Finally, the fixed conduction delay is replaced by a distance-dependent one. The data sets result from simulations of duration T sim with a temporal resolution of dt. We discard the startup transient period T trans and record all spike times from all neurons. The unprocessed spike times together with the corresponding neuron positions are considered as raw output.
( 3 ) This relation is also valid for a sphere current source (i. e. , our ball soma) centered at r 0 with total transmembrane current I m,soma and radius r sphere when |r γ -r 0 | ≥ r sphere. Thus φ soma (r γ , t) = 1 4πσ e I m,soma (t) |r γ -r soma |. (4) The elongated dendritic segments are treated as 'line sources', obtained by integrating the point-source formula along the central axis of the segments  (Holt and Koch, 1999; Lindén et al. , 2014) : φ dend (r γ , t) = 1 4πσ e n dend u=1 I m,u (t) ˆdr u |r γ -r u |. (5) The total extracellular potential from somatic and dendritic sources is then φ(r γ , t) = φ soma (r γ , t) + φ dend (r γ , t). Our calculations of extracellular potentials rely on the Python package LFPy 12   (Lindén et al. (2014) ;  Hagen et al. (2018) ). The tool implements the above forward-model formalism for extracellular potentials, and uses the NEURON simulation environment  (Carnevale and Hines, 2006)  to compute transmembrane currents I m (t) of multicompartment neuron models.
Note that we sum over all elements r in {| ∆|}. LFP output: Each H X is calculated at a spatial resolution ∆l φ and temporal resolution of dt (as in the network, cf. Table  2 ) for a total duration of 2τ s , with synapse activation time at time τ s. An identical spatial and temporal binning resolution is also used for spike events entering in (1). The spike rates in each bin are filtered by a length ∆t normalized boxcar filter using the scipy. signal. lfilter method prior to the convolution with the corresponding LFP kernel. Otherwise a temporal shift between the spatiotemporally binned spiking data (cf. Section 3. 1) and the downsampled LFP in the visualization occurs. Discrete convolutions are incorporated using numpy. convolve and scipy. signal. convolve2d methods in Python. The final LFP signals are low-pass filtered and downsampled to the time resolution ∆t of our preprocessed network output as described in  Hagen et al.
Software summary All source codes of the tool VIOLA, the example network model and the processing of model output are hosted at https://github. com/HBPVIS/VIOLA (SHA:ca2f3c5). We simulated the example network (topo_brunel_alpha_nest. py) with NEST v2. 12. 0 and Python v2. 7. 11. Further processing and plotting of Figures  1  and 2  (nest_preprocessing. py) also relied on Python with numpy v1. 10. 4, SciPy v0. 17. 0, and matplotlib v1. 5. 1. LFP signals (fake_LFP_signal. py) were computed using NEURON v7. 5 and LFPy from http://lfpy. github. io (SHA:5673a6). We visualized the neuronal activity with VIOLA using the Google  Chrome browser,. VIOLA used JavaScript V8 5. 8. 283. 38 with the 3D library three. js of revision 87, including WebGL and HTML5 build in the browser and Node. js v4. 8. 3.
For example, views 1 and 2 compare to series of snap shots (as in  Mehring et al. 2003; Yger et al. 2011; Voges and Perrinet 2012; Keane and Gong 2015) , but are here enhanced by the possibilities to show raw or preprocessed data, to specify visualization parameters interactively, and to provide a 3D and temporally animated view on the multi-dimensional data. View 4 presents a new concept combining 2D spatial and temporal resolution of multiple neuron populations, all shown simultaneously. This data representation delivers a wealth of information, but, to circumvent occlusion and instead expose interesting features of the data, it relies on interactive usage. The code of the reference implementation is open source and available in a public repository (https://github. com/HBPVIS/VIOLA) together with the revision history and documentation.
The present work uses the simulation code NEST to generate the data but the VIOLA implementation is completely independent of the former. The JavaScript code defines a standalone application (accessible at http://hbpvis. github. io/VIOLA) and interpretable by the browser running on the client device. In the last decade, JavaScript-based visualization got more and more versatile especially fostered by the introduction of HTML5 and its canvas environment. Furthermore, the development of WebGL enables the access to GPU-accelerated 3D rendering in the browser. Beside limitations regarding memory and access to low-level program control (as needed for controlled use of multi-threading), JavaScript offers the opportunity for simple deployment and handling of external libraries and dependencies. Unfortunately, JavaScript-based implementations tend to fail on one or the other browsers as browsers still differ in their interpretation of JavaScript and in the degree of following the HTML standard.
Another ongoing effort is the Neuroscience Gateway 14   (Sivagnanam et al. , 2013). Online embedding opens the possibility to accompany interactive visualization with server-side preprocessing steps and a database integration, in particular for simulation output being generated on the portal itself. This advances the goal of the HBP Collaboratory to provide a fully digitized workflow from data representation over model construction and simulation to model validation  (Senk et al. , 2017). We argue that interactive visual analysis of simulated data is an obvious feature of a collaboratory, in addition to non-interactive script-based plotting relying for example on matplotlib. The reference implementation accesses the file system of the host machine to load data. This is not recommended for web applications for security reasons.
If data processing and storage were handled on the server-side, SQL-like database queries could restrict communication to only the data needed for the different view instances. Communication does not have to be limited to the raw data. Binning operations similar to those performed in our preprocessing steps can be handled by the database in a straightforward manner, and could also be performed in parallel. The data format HDF 15  would also be an option to store and access large amounts of raw and preprocessed data with improved performance in terms of speed and compactness compared to the currently used text format. Inherent in interactive visualization is the problem of reproducibility. The raw data are insufficient to reproduce the visuals, only in combination with the full collection of GUI parameters adjusted by the researchers is the data set complete.
In the same way as experimental and simulated data need to be enriched with metadata in order to uniquely specify their origin and enable reuse  (Zehl et al. , 2016) , the visuals need to be enriched with the parameters of their creation. This new type of metadata could be stored in a database. The JavaScript implementation imposes other shortcomings. Prominent is its limited capability for numerical analysis. While the math. js 16 library provides a number of basic math functions and support for symbolic operations, complex numbers and arrays (matrices), the JavaScript libraries are not comparable to the Scientific Python stack (SciPy 17 ) which provides an ecosystem of fundamental tools and methods encountered in mathematics, engineering and science. VIOLA implements the function computing the spatial correlation of neuronal activity from scratch (not shown).
This approach has two conceptual weaknesses. First, the speed and accuracy of such functions are hampered by the fact that there is little native support for advanced mathematical operations, like the Fast Fourier Transform (FFT). Second, VIOLA there is no separation between the code carrying out the statistical analysis and the code performing the visualization. This cuts visualization off from the rich set of analysis tools developed by the community and their reliable implementations, for example as collected in the Elephant package  18. Future work needs to disentangle numerics from visualization code as separate building blocks in a visual analysis workflow. As VIOLA's main focus lies on responsive interactive visualization, the reference implementation uses WebGL for all views. Prior tests exposed the low efficiency of the Document Object Model (DOM) as used in Scalable Vector Graphics (SVG) based visualization libraries such as d3.
Nevertheless, any export mechanism needs to facilitate means of reproducibility. In particular metadata such as simulation and visualization parameters, time stamps, viewpoint angle and position etc. need to be bundled with the raw visualizations. As direct file writes may not be possible in a client side JavaScript application, one solution is server-based rendering and storage based on visualization parameters being communicated from the client back to the server. The resulting server-side rendered images are then stored as provenance information. Another option for reproducible visualization outcome is to only store the previously mentioned visualization parameters in the database, such that the client-side visualization application can be set back into the original captured state. If these parameters are captured over a longer period, the resulting data can ease the regeneration of content for demonstration purposes or a post-hoc video rendering.
ACKNOWLEDGMENTS This project received funding from the  European Union 's  Horizon 2020 research and innovation programme  under grant agreement No. 720270  ( HBP SGA1 ), the  European Union Seventh Framework Programme  [ FP7/2007[FP7/ -2013 ] ] under grant agreement No. 604102  ( Human Brain Project, HBP ), the  Helmholtz Association  through the  Helmholtz Portfolio Theme "Supercomputing and Modeling for the Human Brain ", the  Research Council of Norway (NFR)  through  COBRA.
The gyroscope measures pitch, yaw, and roll of the phone. HydroColor uses the pitch and roll function to create an inclinometer display alongside the compass display. The inclinometer display guides users to position the phone 40° or 130° from nadir, for the water and sky images, respectively. The exact angle of the phone is saved in the HydroColor metadata when each image is captured. Therefore, the metadata can be used to ensure the images were captured at the correct angle.
Extracting Radiance from Images A digital smartphone camera, while not meant to be a quantitative environmental sensor, can be used to measure light intensity. Most smartphone cameras use a complementary metal-oxide semiconductor (CMOS) as the light sensor. In the HydroColor application, light intensity is extracted from compressed images captured by the camera. Ideally, raw data from the CMOS sensor should be Even though the surface reflection cannot be eliminated, it can be significantly reduced by collecting the water image at an angle of 135 • from the sun and 40 • from nadir. HydroColor collects a water image at these specific angles by taking advantage of the smartphone's clock, GPS, compass, and gyroscope. HydroColor uses the current GPS coordinates and the current UTC time to determine the position of the sun in the sky.
HydroColor puts this information into a simple sun position model that runs onboard the phone  [14]. HydroColor uses the resulting sun azimuth angle to create a compass display. The compass display guides users to point the phone ±135 • from the plane of the sun. The sun zenith angle is not used; however, it is saved along with the rest of the data. It can be used later for quality control. The gyroscope measures pitch, yaw, and roll of the phone. HydroColor uses the pitch and roll function to create an inclinometer display alongside the compass display. The inclinometer display guides users to position the phone 40 • or 130 • from nadir, for the water and sky images, respectively. The exact angle of the phone is saved in the HydroColor metadata when each image is captured. Therefore, the metadata can be used to ensure the images were captured at the correct angle.
Extracting Radiance from Images A digital smartphone camera, while not meant to be a quantitative environmental sensor, can be used to measure light intensity. Most smartphone cameras use a complementary metal-oxide semiconductor (CMOS) as the light sensor. In the HydroColor application, light intensity is extracted from compressed images captured by the camera. Ideally, raw data from the CMOS sensor should be used. However, due to limitations of the standard application program interface (API) of common smartphones cameras, compressed image data are used. Compression introduces some nonlinearity into the camera response. However, it was found that light measurements were not greatly influenced by image compression (Figure  2 ). HydroColor measures relative light radiance using the following equation: L rel = DN αS ( 2 ) where DN is the digital pixel value (0-255) from the camera image in either the red, green, or blue channel, α is the exposure time, and S is the ISO speed.
Field Tests Field data were collected in three different campaigns. The first campaign was designed to compare HydroColor measurements to precision radiometers and turbidimeters for a wide range of water types. The second campaign was a volunteer driven HydroColor collection day, to demonstrate HydroColor as a citizen science tool. The third campaign was a brief comparison of HydroColor measurement from Android and Apple devices. In the first campaign in 2013, field data were collected at three locations: the Columbia River mouth, the coast of Maine, USA, and the coast of Georgia, USA. Data were collected during the summer months under a variety of meteorological conditions, ranging from clear sky to fully overcast. An Apple iPhone 4, iPhone 5 or iPod touch where used to collect HydroColor measurements.
Measurements were made under calm conditions where wind speed was less than 5 m s -1. The measurements were made in coastal case II waters where CDOM and mineral particles greatly influenced the water leaving radiance. Coastal Georgia measurements contained the highest amounts of mineral particles compared to the other study sites. Nearly all the field sites were influenced by freshwater input. HydroColor data were collected in parallel with an above water radiometer and a turbidimeter. The concurrent data were used to validate HydroColor's calculation of R rs and provide a calibration for the measurement of turbidity. A total of 63 HydroColor measurements collected during the first campaign were accompanied by measurements with a Water Insight Spectrometer (WISP). Both HydroColor and the WISP are designed to measure R rs.
In this study, we used turbidity measured in nephelometric turbidity units (NTU) as a proxy for SPM concentration. Turbidity was measured using a Hach 2100Q portable turbidimeter. Using turbidity simplified the methodology and was a convenient choice since it is used by many environmental monitoring agencies. The turbidity dataset is made up of 58 different measurements collected on an iPhone 5, iPhone 4 or iPod touch. The turbidity measurements were made at the same study sites as the radiance measurements. The second field campaign consisted of HydroColor measurements collected by volunteer citizen scientists. San Francisco Bay National Estuarine Research Reserve members organized volunteers to collect HydroColor measurements and water samples on 24 July 2014. In total, 14 measurements were collected along the shores of San Francisco Bay.
Validation of Reflectance Measurement Equation (  3 ) was applied to the WISP field data using the spectral sensitivity curve (Figure  3 ) from the camera used to collect the concurrent HydroColor measurement. For each color channel, a regression line was fit to the WISP and HydroColor R rs using type-I least-squares linear regression. After the initial fit, the standard deviation of the absolute error between the models predicted values and the measured values were calculated. Any data falling more than 3. 5 standard deviations outside the median fit error were considered outliers and were removed from the regression. The regression line was then fit to the dataset with the outliers omitted. The HydroColor measured R rs compares well with concurrent WISP measurements (Figure  4 ). The majority of data points fall close to the one-to-one line.
The scatter of the data around the one-to-one line is similar for all channels (note the difference in scale for the blue channel in Figure  4 ). The range of R rs values spanned in the data set represent a wide range of conditions. However, HydroColor has yet to be tested in highly turbid waters (turbidity >80 NTU). The median percent error of the HydroColor measurement of R rs relative to the WISP was 18%, 16% and 26% for the red, green, and blue channels, respectively. The median bias for the same comparison was 1. 3 × 10 -4 sr -1 , -5. 2 × 10 -4 sr -1 , and-9. 5 × 10 -4 sr -1 , respectively. The error in ρ is not realized in this comparison because the same value of ρ is used for both the HydroColor and WISP calculations of R rs. Sensors 2018, 18, 256 8 of 15 The peak near 490 nm in the green response of several cameras appears to be an artifact.
Validation of Reflectance Measurement Equation (  3 ) was applied to the WISP field data using the spectral sensitivity curve (Figure  3 ) from the camera used to collect the concurrent HydroColor measurement. For each color channel, a regression line was fit to the WISP and HydroColor Rrs using type-I least-squares linear regression. After the initial fit, the standard deviation of the absolute error between the models predicted values and the measured values were calculated. Any data falling more than 3. 5 standard deviations outside the median fit error were considered outliers and were removed from the regression. The regression line was then fit to the dataset with the outliers omitted. The HydroColor measured Rrs compares well with concurrent WISP measurements (Figure  4 ). The majority of data points fall close to the one-to-one line.