dataesr/scientific-paragraphs-categorization huggingface dataset:
SpikeSorters The spikesorters 8  package provides a straightforward interface for running spike sorting algorithms supported by SpikeInterface. Modern spike sorting algorithms are built and deployed in a variety of programming languages including C, C++, MATLAB, and Python. Along with variability in the underlying program languages, each sorting algorithm may depend on external technologies like CUDA or command line interfaces (CLIs), complicating standardization. To unify these disparate algorithms into a single codebase, spikesorters provides Python-wrappers for each supported spike sorting algorithm. These spike sorting wrappers use a standard API for running the corresponding algorithms, internally handling intrinsic complexities such as automatic code generation for MATLABand CLI-based algorithms.
Each spike sorting wrapper is implemented as a subclass of a BaseSorter class that contains all shared code for running the spike sorters. To run a specific spike sorting algorithm, users can pass a RecordingExtractor object to the associated function in spikesorters and overwrite any default parameters with new values (only essential parameters are exposed to the user for modification). Internally, each function initializes a spike sorting wrapper with the user-defined parameters. This wrapper then creates and modifies a new spike sorter configuration and runs the sorter on the dataset encapsulated by the RecordingExtractor. Once the spike sorting algorithm is finished, the sorting output is saved and a corresponding SortingExtractor is returned to the user. For each sorter, all available parameters and their descriptions can be retrieved using the get_default_params() and get_params_description() functions, respectively.
In the following code snippet, Mountainsort4 and Kilosort2 are used to sort an extracellular record-Running each algorithm (and changing the default parameters) can be done as follows: import spikeinterface. sorters as ss sorting_MS4 = ss. run_mountainsort4(recording, adjacency_radius=50) sorting_KS2 = ss. run_kilosort2(recording, detect_threshold=5) Our spike sorting functions also allow for users to sort specific "groups" of channels in the recording separately (and in parallel, if specified). This can be very useful for multiple tetrode recordings where the data are all stored in one file, but the user wants to sort each tetrode separately. For largescale analyses where the user wants to run many different spike sorters on many different datasets, spikesorters provides a launcher function which handles any internal complications associated with running multiple sorters and returns a nested dictionary of SortingExtractor objects corresponding to each sorting output.
Note that in the SpikeForest benchmarking software suite  [47] , the best-match strategy is used. Additionally, when comparing a sorting output to a ground-truth sorted result, each spike can be optionally labeled as: • True positive (tp): Found both in the ground-truth spike train and tested spike train. • False negative (f n): Found in the ground-truth spike train, but not in the tested spike train. • False positive (f p): Found in the tested spike train, but not in the ground-truth spike train. Using these labels, the following performance measures can be computed: • Accuracy: #tp (#tp + #f n + #f p) • Recall: #tp (#tp + #f n) • Precision: #tp (#tp + #f p) • Miss rate: #f n (#tp + #f n) • False discovery rate: #f p (#tp + #f p) While previous metrics give a measure of individual spike train quality, we also propose metrics at a unit population level.
e. accuracy). More sophisticated classification rules could involve a combination of accuracy, precision, and recall values, which can be easily computed for each unit with the spikecomparison module. The following code snippet shows how to perform all three types of spike sorter comparisons: import spikeinterface. comparison as sc comp_type_1 = sc. compare_two_sorters(sorting1, sorting2) comp_type_2 = sc. compare_multiple_sorters([sorting1, sorting2, sorting3]) comp_type_3 = sc. compare_sorter_with_ground_truth(gt_sorting, tested_sorting) Along with the three comparison functions, spikecomparison also includes a GroundTruthStudy that allows for the systematic comparison of multiple spike sorters on multiple ground-truth datasets. With this class, users can set up a study folder (in which the recordings to be tested are saved), run several spike sorters and store their results in a compact way, perform systematic groundtruth comparisons, and aggregate the results in dataframes  [52].
g. accuracy, precision, recall) with respect to a unit property (e. g. SNR), and the agreement between multiple sorting algorithms on the same dataset. The following code snippet demonstrates how SpikeInterface can be used to visualize ten seconds of both the extracellular traces and the corresponding raster plot: import spikeinterface. widgets as sw sw. plot_timeseries(recording, channel_ids=[0,1,2,3], trange=[0,10]) sw. plot_rasters(sorting, unit_ids=[0,1,3], trange=[0,10]).
Building a spike sorting pipeline So far, we have given an overview of each of the main packages in isolation. In this section, we illustrate how these packages can be combined, using both the Python API and the Spikely GUI, to build 11 https://github. com/SpikeInterface/spikewidgets a robust spike sorting pipeline. The spike sorting pipeline that we construct using SpikeInterface is depicted in Figure  6A  and consists of the following analysis steps: 1. Loading an Open Ephys recording  [70]. 2. Loading a probe file. 3. Applying a bandpass filter. 4. Applying common median referencing to reduce the common mode noise. 5. Spike sorting with Mountainsort4. 6. Removing clusters with less than 100 events. 7. Exporting the results to Phy for manual curation. Traditionally, implementing this pipeline is challenging as the user has to load data from multiple file formats, interface with a probe file, memory-map all the processing functions, prepare the correct inputs for Mountainsort4, and understand how to export the results into Phy.
Using the Python API Using SpikeInterface's Python API to build the pipeline shown in Figure  6A  is straightforward. Each of the seven steps is implemented with a single line of code (as shown in Figure  6B ). Additionally, data visualizations can be added for each step of the pipeline using the appropriate widgets (as described in the SpikeWidgets Section). Unlike handmade scripts, SpikeInterface has a wide range of unit tests, employs continuous integration, and has been carefully developed by a team of researchers. Users, therefore, can have increased confidence that the pipelines they create are correct and reusable. Additionally, SpikeInterface tracks the entire provenance of the performed analysis, allowing other users (or the same user) to reproduce the analysis at a later date.
Using the spikely GUI Along with our Python API, we also developed spikely 12  a PyQt-based GUI that allows for simple construction of complex spike sorting pipelines. With spikely , users can build workflows that include: (i) loading a recording and a probe file; (ii) performing pre-processing on the underlying recording with multiple processing steps; (iii) running any spike sorter supported by SpikeInterface on the processed recording; (iv) automatically curating the sorter's output; and (v) exporting the final result to a variety of file formats, including Phy. At its core, spikely utilizes SpikeInterface's Python API to run any constructed spike sorting workflow. This ensures that the functionality of spikely grows organically with that of SpikeInterface. Figure  6C  shows a screenshot from spikely where the pipeline in Figure  6A  is constructed.
Discussion In this paper, we introduced SpikeInterface, a Python framework designed to enhance the accessibility, reliability, efficiency, and reproducibility of spike sorting. To illustrate the use-cases and advantages of SpikeInterface, we performed a detailed meta-analysis that included: quantifying the agreement among 6 modern sorters on a real dataset, benchmarking each sorter on a simulated ground-truth recording, and investigating the performance of a consensus-based spike sorting and how it compares with manually curated results. To highlight the modular design of SpikeInterface, we then provided descriptions and code samples for each of the five main packages and showed how they could be chained together to construct flexible spike sorting workflows.
Although ensemble spike sorting is an exciting new direction to explore, there are other methods for curation that must be considered. One popular curation method is to accept or reject sorted units based on a variety of quality metrics (this is supported by SpikeInterface). Another method that is gaining more popularity is to use the large amount of available curated datasets to train classifiers that can automatically flag a unit as "good" or "noise" depending on some features, such as waveform shape. Finally, while manual curation is subjective and time consuming, it is the only method that allows for merging and splitting of units and, through powerful software tools such as Phy  [64, 65] , it allows for full control over the curation process. Future research into these different curation methods is required to determine which are appropriate for the new influx of high-density extracellular recording devices.
Comparison to other frameworks As mentioned in the introduction, many software tools have attempted to improve the accessibility and reproducibility of spike sorting. Here, we review the four most recent tools that are in use (to our knowledge) and compare them to SpikeInterface. Nev2lkit  [15]  is a cross-platform, C++-based GUI designed for the analysis of recordings from multi-shank multi-electrode arrays (Utah arrays). In this GUI, the spike sorting step consists of PCA for dimensionality reduction and then klustakwik for automatic clustering  [65]. As Nev2lkit targets low-density probes where each channel is spike sorted separately, it is not suitable for the analysis of high-density recordings. Also, since it implements only one spike sorter, users cannot utilize any consensus-based curation or exploration of the data.
The software is available online  13  , but it lacks version-control and automated testing with continuous integration platforms. SigMate  [48]  is a MATLAB-based toolkit built for the analysis of electrophysiological data. SigMate has a large scope of usage including the analysis of electroencephalograpy (EEG) signals, local field potentials (LFP), and spike trains. Despite its broad scope, or because of it, the spike sorting step in SigMate is limited to Wave clus  [19] , which is mainly designed for spike sorting recordings from a few channels. This means that both major limitations of Nev2lkit (as discussed above) also apply to SigMate. The software is available online  14  , but again, it lacks version-control and automated testing with continuous integration platforms. Regalia et al.
[61]  developed a spike sorting framework with an intuitive MATLAB-based GUI. The spike sorting functionality implemented in this framework includes 4 feature extraction methods, 3 clustering methods, and 1 template matching classifier (O-Sort  [67] ). These "building blocks" can be combined to construct new spike sorting pipelines. As this framework targets low-density probes where signals from separate electrodes are spike sorted separately, its usefulness for newly developed high-density recording technology is limited. Moreover, this framework only runs with a specific file format (MCD format from Multi Channel Systems  [5] ). The software is distributed upon request. Most recently, Nasiotis et al. [56]  implemented IN-Brainstorm, a MATLAB-based GUI designed for the analysis of invasive neurophysiology data.
IN-Brainstorm allows users to run three spike sorting packages, (Wave clus  [19] , UltraMegaSort2000  [37] , and Kilosort  [59] ). Recordings can be loaded and analyzed from six different file formats: Blackrock, Ripple, Plexon, Intan, NWB, and Tucker Davis Technologies. IN-Brainstorm is available on GitHub 15  and its functionality is documented  16. IN-Brainstorm does not include the latest spike sorting software  [65, 74, 20, 39, 58, 36] , however, and it does not cover any post-sorting analysis such as validation, curation, or sorting output comparison.
Outlook As it stands, spike sorting is still an open problem. No step in the spike sorting pipeline is completely solved and no spike sorter can be used for all applications. With SpikeInterface, researchers can quickly build, run, and evaluate many different spike sorting workflows on their specific datasets and applications, allowing them to determine which will work best for them. Once a researcher determines an ideal workflow for their specific problem, it is straightforward to share and re-use that workflow in other laboratories as the full provenance is automatically stored by SpikeInterface. We envision that many laboratories will use SpikeInterface to satisfy their spike sorting needs. Along with its applications to extracellular analysis, SpikeInterface is also a powerful tool for developers looking to create new spike sorting algorithms and analysis tools.
Developers can test their methods using our efficient and comprehensive comparison functions. Once satisfied with their performance, developers can integrate their work into SpikeInterface, allowing them access to a largecommunity of new users and providing them with automatic file I/O for many popular extracellular dataset formats. For developers who work on projects that utilize spike sorting, SpikeInterface can be used out-of-the-box, providing more reliability and functionality than lab-specific spike sorting scripts. We envision that many developers will be excited to use and integrate with SpikeInterface. Already, SpikeInterface is being used in a variety of applications. The file IO, preprocessing, and spike sorting capabilities of SpikeInterface are an integral part of SpikeForest  [47]  which is an interactive website for benchmarking and tracking the accuracy of publicly available spike sorting algorithms.
Only four spike sorters were capable of processing this data set (HS=HerdingSpikes2, KS=Kilosort2, IC=IronClust, HDS=HDSort). A) A visualization of the activity on the Biocam array (top, color indicates spike rate estimated on each channel evaluated with threshold detection) and of traces from the recording (below). B) The number of detected units for each of the 4 spike sorters. C) The total number of units for which k sorters agree (unit agreement is defined as 50% spike match). D) The number of units (per sorter) for which k sorters agree; Most sorters find many units that other sorters do not. Figure S4: (A) Precision versus recall for the ground-truth comparison the simulated dataset. Some sorters seem to favor precision (HerdingSpikes, SpyKING Circus, HDSort), others instead have higher recall (Kilosort2, Ironclust).
Figure2: Evaluation of spike sorters on a Simulated Neuropixels dataset. A) A visualization of the activity on and traces from the simulated Neuropixels recording. B) The signal-to-noise ratios (SNR) for the ground truth units. C) The number of detected units for each of the 6 spike sorters (HS=HerdingSpikes2, KS=Kilosort2, IC=IronClust, TDC=Tridesclous, SC=SpyKING Circus, HDS=HDSort). D) The accuracy, precision, and recall of each sorter on the ground truth units. E) A breakdown of the detected units for each sorter (precise definitions of each unit type can be found in the SpikeComparison Section of the Methods).
Ackowledgements This work was supported by the  Wellcome Trust  grant  214431/Z/18/Z  (MHH). APB is supported by an  ETH   Zurich Postdoctoral Fellowship   19-2 FEL-17 , and by the  Simula-UCSD-University of Oslo  Research and PhD training ( SUURPh) program , funded by the  Norwegian Ministry of Education and Research. CLH is supported by the  Thouron Award  and by the  Institute for Adaptive and Neural Computation, University of Edinburgh. JHS wishes to thank the  Allen Institute  founder, Paul G. Allen, for his vision, encouragement and support. We would also like to thank  Shangmin Guo  for his recent contributions to debugging and improving the codebase.
large set of either well-established or newly developed codes. In addition to functionality from the scientific point of view, the codes are very different with respect to performance, the need of hardware resources, documentation and user friendliness. As a general purpose package for quantum chemical calculations, MOLCAS, has made a long journey from a collection of homemade codes to a professional software with distributed development, automatic verification, user support, etc. Recently the vast majority of the codes in MOLCAS have been released as open sourcethe OpenMolcas project. This package is user-friendly and ready-to-use, and is also a developers' platform. While OpenMolcas is a free-of-charge package, with web based community support, the MOLCAS package is a licensed distribution of a refurbished version of the Open-Molcas package, with some additional external utilities.
The MOLCAS package is user-oriented and offers explicit support in installation, performance enhancement and basic calculations. For all practical purposes both packages offer the same or similar computational tools. In what follows we will make the distinction between MOL-CAS and OpenMolcas when so is called for, else-wise we will refer to both distributions as [Open]Molcas. There are several reviews describing new and recent features of MOLCAS  [2] [3] [4]  and OpenMolcas  5  , as well as the development infrastructure of the code  6  , external software interfaced to MOLCAS and Graphical User Interface programs  7, 8. For a more comprehensive list of features, computed properties, implementation details and theoretical description, we would suggest the reader to consult these papers, together with the manual 9.
II. PROGRAM OVERVIEW From the programming point of view, [Open]Molcas is a package that is composed of a large number of individual computational units, which run together driven by an input parser. The modularity simplifies the dis-This is the author's peer reviewed, accepted manuscript. However, the online version of record will be different from this version once it has been copyedited and typeset. PLEASE CITE THIS ARTICLE AS DOI:10. 1063/5. 0004835 tributed development and allows to have a better control over computational resources, especially memory. As a drawback of the module structure of [Open]Molcas there is a need to organize communication between executable codes, which includes handling of return codes, transferring the data, and keeping the parallel infrastructure. Currently there are two implementations of input parser, written in Perl/C (molcas.
exe in MOLCAS) and in Python (pymolcas in OpenMolcas). Both parsers use Enhanced MOLCAS Input Language (EMIL), described in details in the SI. The main computer language used in [Open]Molcas is Fortran. The majority of the code is compatible with the Fortran 77 standard, but some newer contributions are written in Fortran 90 or later. All systemdependent routines, like handling of memory, I/O and parallelization, are written in C language. Not surprisingly, the main computational tasks are related to linear algebra problems. The code has an interface to standard BLAS/LAPACK libraries, providing the best performance for production calculations, but at the same time there is a possibility to control the usage of mathematical libraries for development purposes. Despite the general trend of reducing the variety of hardware architecture and software, we continue to support [Open]Molcas not only on the mainstream setup (x86 64 CPU with Linux OS and GNU or Intel compiler), but also on marginal hardware and compilers.
Most of the modules are parallelized, however, a production run will require even more memory if parallelization is used  12. Recent development is also focused on creating data interface with other computational and visualization codes. In some cases the data exchange is customized (interface to other computational codes, e. g. QCMaquis, Columbus, etc. ), but the work in progress also includes a general HDF5-formatted interface and XML/json formatted output. The following sections present the main computational codes in [Open]Molcas. The flowchart of modules, as well as a short programming description of codes is presented in the SI. In order to distinguish, say, the SCF method and the scf program, the latter is printed in small capital letters.
A. Integrals, gradients, and second derivatives The original MOLCAS package has since its inception utilized Gaussian basis sets to expand the one-particle space. While the original MOLCAS 1. 0 used MOLECULE  13  , subsequent versions have used the seward,  14  alaska,  15  and mckinley  16  programs to compute integrals and up to second order derivatives of those. The hallmark of these modules is the efficient computation of integrals in the Gaussian basis of generally contracted basis functions. Moreover, the integral codes are implemented for the efficient use of real spherical harmonics of arbitrary order. The two-electron integrals, and associated derivatives are computed using the Rys-Gauss quadrature, while one-electron integrals are computed using the Hermite-Gauss quadrature. As any standard package OpenMolcas supports a large array of one-electron operators, but also some which are unique.
The latter is accessed in OpenMolcas with the mpssi program. This capability is decisive for the calculation of transition dipole moments as well as SO coupling matrix elements between states optimized separately as MPS-type wave functions. In Ref. 47 we showed with the example of actinide complexes that DMRG-SCF in combination with the MPSSI approach yields magnetic properties such as ground-and excited-state g-tensors in full agreement with data obtained from corresponding CASSCF/RASSI calculations. For an example that combines for the first time the DMRG-SCF/PT2/MPSSI functionality with the SINGLE ANISO approach, the reader is referred to Section III B 6. In addition, by taking advantage of the same implementation framework as the rassi module, the mpssi module facilitates the computation of Spin Orbit (SO) -coupled wavefunctions that are suitable for a subsequent ground-and excited-state bonding analysis as described in Section III D 4 and/or that can serve as input functions to the single aniso module  4.
[Open]Molcas contains a module, called expbas, which expands a wavefunction from a smaller basis set into a larger one, giving the user the ability to first find an active space in a small basis-either manually or through the AutoCAS algorithm described next, before choosing a larger, more expensive basis, for production calculations. An example of how to use expbas on a model [Co(H 2 O)(OH) 3 ]-system is given in the Supporting Information. This system serves as a minimal model for the interaction between a water molecule adsorbed on a Co 2 O 3 -surface. In the Supporting Information, we describe how to first select a small as possible ANO-type basis set for generating an initial guess for an active space consisting of the water molecule's valence orbitals as well as the Co 3d-and 3d /4d-orbitals.
III. TYPICAL PROBLEMS SOLVED BY [OPEN]MOLCAS In the following section several cases of the use of [Open]Molcas package in typical quantum chemical applications are described. In Supplementary information user can find corresponding inputs. A. Precise wave function calculations 1. RASSCF/RASPT2 electronic structure calculation An incomplete time line illustrates the evolution from the early times when only CASPT2 was available for dynamic correlation of CASSCF wave functions. This combination was then used extensively for molecules with lighter elements up to transition metal compounds. Spinorbit interaction could already be treated  73  , e. g. in the study of EPR g-tensors  74  , and by the Douglas-Kroll-Hess scalar relativistic integrals by  75  also calculations involving heavier elements including up to actinides became possible  [76] [77] [78].