dataesr/scientific-paragraphs-categorization huggingface dataset:
Visual reports can be opened with Firefox or Chrome browsers, and graphics acceleration support is ◼ RECOMMENDED. Computing software. fMRIPrep can be manually installed ("bare-metal" installation as per its documentation) on GNU/Linux and OSX systems, or executed via containers (e. g. , using Docker for Windows). When setting up manually, all software dependencies must also be correctly installed (e. g. , AFNI  25  , ANTs 26 , FSL 10 , FreeSurfer 27 , Nilearn 28 , Nipype 9 , etc. ) When using containers ( ◼ RECOMMENDED ), a new Docker image is provided from the Docker Hub for each new release of fMRIPrep , and it includes all the dependencies pinned to specific versions to ensure the reproducibility of the computational framework. Containers encapsulate all necessary software required to run a particular data processing pipeline akin to virtual machines.
However, containers leverage some lightweight virtualization features of the Linux kernel without incurring much of the performance penalties of hardware-level virtualization. For these two reasons (ease and reproducibility), container execution is preferred. This protocol recommends running quality control on the original data before preprocessing, using MRIQC. MRIQC is a companion tool to fMRIPrep to perform a quality assessment of the anatomical and functional MRI scans, which account for the most relevant data within the typical fMRI protocol. The tool is distributed as a Docker image (recommended), and as a Python package. Box 2. Using DataLad to fetch a BIDS dataset from OpenNeuro. DataLad 30 is a convenient scientific data management tool that allows access to all data hosted in OpenNeuro.
First, visit the OpenNeuroDatasets organization at GitHub ( https://github. com/OpenNeuroDatasets ) and locate the dataset by its accession identifier (in this example, ds000003 ). Then visit the repository of the dataset and copy the URL provided by the "Clone or download" green button (top-right), placing it as the argument to the datalad install tool as follows: datalad install -g https://github. com/OpenNeuroDatasets/ds000003. git For directions on the installation of DataLad, please follow the instructions given in its documentation ( https://www. datalad. org ).
Preliminary work: acquisition and/or formatting inputs Alternative (a): acquiring a new dataset. i. a | Participant preparation ( • TIMING 15min per subject). Obtain informed consent from subjects, collect prescribed phenotypic information (e. g. , sex, handedness, etc. ), and prepare the participant for the scanning session. ii. a | MRI acquisition ( • TIMING 30-60min per subject). ▲ CRITICAL Run the prescribed protocol, including at least one high-resolution (at least 1mm  3  , isotropic) T1-weighted image for anatomical reference. ◼ RECOMMENDED To correct geometrical distortions introduced by field inhomogeneities, include a B0 field mapping scheme supported by fMRIPrep within the acquisition protocol. ◼ RECOMMENDED To afford higher accuracy in surface-based analyses, include one or anatomical T2-weighted images within the protocol.
The process can be made much more reliable and consistent with conversion tools such as HeuDiConv  29. ReproIn automates the conversion to BIDS with HeudiConv, ensuring the shareability and version control of the data starting from the earliest steps of the pipeline. ◼ RECOMMENDED If data are to be shared publicly, and depending on the applicable regulations, they must be anonymized and facial features may need to be removed from the anatomical images (some tools and recommendations are found with the Open Brain consent project  21  ). Alternative (b): reusing a publicly available dataset. i. b | Organize dataset in BIDS format ( • TIMING depends on the original data organization and availability of parameters). If the dataset is not originally shared in BIDS format, it must be reorganized to conform to the BIDS specification using custom scripts.
Dataset validation 0 | Make sure the dataset fulfills the BIDS specifications with the BIDS-Validator ( ◼ RECOMMENDED • TIMING 1min). To ensure that the dataset is BIDS compliant, use the online BIDS-Validator at https://bids-standard. github. io/bids-validator/ (or some up-to-date local native or containerized installation), specifying the path to the top-level directory of the dataset in the Choose File dialog. The online BIDS-Validator can be run in any modern browser without uploading any data. After confirming that the dataset is BIDS compliant, manually examine and validate relevant, but non-mandatory, metadata fields (e. g. , make sure that all field maps have set a valid IntendedFor key for susceptibility distortion correction).
Here and below $STUDY refers to the directory containing all study materials. Replace the path $STUDY/fmriprep-1. 4. 1. simg with the local install location for the container image, and be sure to indicate a specific version of fMRIPrep (version 1. 4. 1, in this example). In addition to fMRIPrep , this protocol leverages the BIDS-Apps standard with MRIQC29 and the exemplar analysis workflow. Container images for MRIQC and the analysis workflow are built with singularity build , again substituting the local installation path as appropriate: singularity build $STUDY/mriqc-0. 15. 1. simg docker://poldracklab/mriqc:0. 15. 1 singularity build $STUDY/analysis-0. 0. 3. simg docker://poldracklab/ds003-example:0. 0. 3 The location of the dataset (BIDS compliant) must also be noted. In this protocol, we use $STUDY/ds000003/ as an example; the dataset path should be substituted as appropriate.
The ◼ RECOMMENDED way of executing fMRIPrep is to process one subject per container instance. ◼ RECOMMENDED Each container instance can make use of multiple CPUs to accelerate subject level processing. ◼ RECOMMENDED Multiple container instances can be distributed across compute nodes to parallelize processing across subjects. ▲CRITICAL All datasets used in any study (and all subjects in any dataset) should be processed consistently, using the same version of fMRIPrep. The version of fMRIPrep previously used to process any dataset can be identified by consulting the PipelineDescription field of the dataset_description. json file in the top level of fMRIPrep 's output directory. 11 and inspect the visual reports ( ◼ OPTIONAL • TIMING 7-60min compute time and 5-15min researcher time per subject, scales with the BOLD-run count).
MRIQC is a tool to inspect the input dataset and flag subjects/sessions/runs that should be excluded from the analysis for their insufficient quality. Running MRIQC follows the same instructions given for fMRIPrep (see the following Step 3). First, create a batch prescription file $STUDY/mriqc. sbatch (see Box 3 for the example with fMRIprep ). Second, submit the job to the scheduler: sbatch $STUDY/mriqc. sbatch. Although the default options are probably sufficient, the documentation of MRIQC provides more specific guidelines.
| Run MRIQC After running MRIQC , inspect all the generated visual reports to identify images with insufficient quality for analysis. Although there is not a consensus on the rules for exclusion, and they depend on the analyses planned, we recommend having these criteria pre-defined before quality assessment. Some examples of artifacts that could grant exclusion of images from a study are T1w images showing extreme ringing as a result of head motion, irrecoverable signal dropout derived from susceptibility distortions across regions of interest, excessive N/2 ghosting within fMRI scans, excessive signal leakage through slices in multiband fMRI reconstructions, etc. In this protocol, no images were excluded from this dataset due to quality assessment.
Running first level analysis on a preprocessed dataset 6 | Run the analysis workflow ( • TIMING 5-60min compute time, depending on the number of BOLD runs and the workflow configuration). Determine an appropriate workflow and model design to be used for computing voxelwise activation contrasts. For this purpose, we provide reference Nipype workflows  34  execute first and second level on the example dataset using tools from FSL (principally FEAT , FILM , and FLAMEO ). To make use of these workflows with a new dataset, the code should be modified so that the statistical analysis is performed using the most appropriate contrasts. Create a batch prescription file $STUDY/analysis. sbatch akin to the script proposed in Box 3 , replace the singularity image with the one packing the analysis workflow  34  , and finally submit the job to the scheduler: sbatch $STUDY/analysis.
Participant-level task-activation maps. Figure  2  shows the activation maps for the subject with identifier "10" for the contrast task-vs-nontask in the example OpenNeuro dataset ds000003. These maps were created with the analysis workflow, processing derivatives produced by fMRIPrep as appropriate ( Box 4 ): Box 4. BIDS-Derivatives data structure. The directory tree of a BIDS-Derivatives  13  dataset generated from a run of fMRIPrep is shown below: The exemplar analysis workflow  34  requires some information encoded within the original BIDS dataset: derivatives/ ├── fmriprep/ │ ├── dataset_description. json │ ├── logs │ ├── sub-01. html │ ├── sub-01/ │ │ ├── anat/ │ │ │ ├── sub-01_desc-brain_mask. nii. gz │ │ │ ├── sub-01_dseg. nii. gz │ │ │ ├── sub-01_label-GM_probseg. nii. gz │ │ │ ├── sub-01_label-WM_probseg.
nii. gz │ │ └── sub-01_task-rhymejudgment_space-MNI152_desc-brain_mask. nii ○ The original events file that describes when the subject was exposed to the experimental manipulation (being the presentation of words or pseudowords in the example at hand): ds000003/sub-<subject_id>/ func/sub-<subject_id>_task-rhymejudgement_events. tsv. ○ The repetition time for the BOLD acquisition, which is a mandatory metadata field of every BOLD run in the dataset. 4. Group level task-activation maps. Figure  3  displays the group level activation map resulting from group analysis.
Limitations Please consider several areas that may fall outside of the present protocol and other considerations (such as limitations of fMRIPrep precluding the execution on particular datasets): HCP and Singularity. This protocol assumes that execution takes place on an HPC cluster, and both the SLURM scheduler and the Singularity container framework are installed. However, we understand that execution on more flexible systems (e. g. , commercial Cloud or PC) should be easier than HPC systems. Other fMRI techniques. fMRIPrep does not preprocess non-BOLD fMRI data. Of note, the current BIDS specification does not support these data types. Animal species. fMRIPrep currently does not support nonhuman species, although we are currently exploring the processing of nonhuman-primate and rodent BOLD fMRI.
Acknowledgements We thank the many community contributors who have helped fMRIPrep with code and documentation ( github. com/poldracklab/fmriprep/blob/master/. maint/contributors. json ). This work was supported by the  Laura and John Arnold Foundation  (R. A. P. and K. J. G. ), the  NIH  (grant NBIB  R01EB020740 , S. S. G. ), and  NIMH  ( R24MH114705  and  R24MH117179 , R. A. P. ). KF was supported by the  Foundation for Polish Science, Poland  ( START 23. 2018 ). DG was supported by a  Marie Curie   FP7-PEOPLE-2013-ITN "Initial Training Networks" Action  from the  European Union  [Project Reference Number: 608123]. FL was supported by the  University Research Priority Program "Dynamics of Healthy Aging " at the  University of Zurich. NJ was supported by  National Science Foundation Graduate Research Fellowship  [grant number  DGE 16-44869 ].
8as the base dataset. ds000003/ ├─ CHANGES ├─ dataset_description. json ├─ participants. tsv ├─ README ├─ sub-01/ │ ├─ anat/ │ │ ├─ sub-01_inplaneT2. nii. gz │ │ └─ sub-01_T1w. nii. gz │ └─ func/ │ ├─ sub-01_task-rhymejudgment_bold. nii. gz │ └─ sub-01_task-rhymejudgment_events. tsv ├─ sub-02/ ├─ sub-03/.
Introduction In the past two decades, the architecture of Graphical Processing Units (GPUs) have made them the tool of choice in scientific computing to solve massively parallel problems  [1, 2]. CPUs spend a sizable fraction of their transistors budget on caching and control units. This allows CPUs to quickly serve data that are often accessed (e. g. , for database server) and to handle complex and varied flows of instructions (e. g. , out-of-order or speculative execution), but this comes at a cost of a reduced number of computing units (arithmetic logic units). By contrast, GPUs spend almost all their transistor budget on arithmetic logic units, because they were initially designed to handle homogeneous but massively parallel flows of instructions (typically the rendering of graphical scenes, which heavily relies on linear algebra).
This focus on computing units enables GPUs to beat CPUs on problems that can be formulated in a parallel manner. For instance, GPUs typically accelerate dense matrix multiplication (a classical, though somewhat artificial, benchmark for supercomputers) by a factor of 6 over CPUs  [3] , and most supercomputers now embark GPUs to accelerate their computations. This speedup comes at a cost: it is necessary to write specific code to fully exploit the parallelism of GPUs. This porting has been facilitated by CUDA libraries  [4] , which provide a middle-level programming interface for NVIDIA GPUs and have enabled GPU-enabled software in many areas of scientific computing. For instance, the meteoric rise of deep learning in the past decade is often attributed to the availability of GPU-enabled frameworks (TensorFlow  [5] , PyTorch  [6] ,.
). Molecular dynamics has also tremendously benefited from GPUs  [7] [8] [9] , and most major packages are now GPU-accelerated (LAMMPS, AMBER, CHARMM,. ). In many of these cases, GPUs offer sizable speed up on real-world problems (typically ∼10-100×). GPUs are also a powerful tool for the Finite Element Method (FEM)  [10]. These simulations are routinely used by scientists and engineers to solve Partial Differential Equations that describe physical phenomena on prescribed geometries: mechanical stress, heat dissipation, dispersion of chemicals, and so on. The literature on FEM and GPUs is now abundant  [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] , yet FEM software still heavily rely on CPUs for their computations, and few support GPUs (e. g. , COMSOL  [23] , a popular commercial software, does not support GPUs).
In absence of routine GPU-acceleration for FEM software, it is difficult to judge if a particular physical PDE could benefit from GPUs without actually implementing the FEM resolution at a low level on the GPU. The goals of this paper are twofold. First and foremost, we set out to investigate if the community of DNA nanotechnology and microfluidics could benefit from GPU-accelerated simulations. In recent years, progresses in DNA nanotechnology have enabled the programming of chemical reaction networks with advanced dynamics (oscillations, multi-stability. )  [24] [25] [26] [27] [28] [29]  and information-processing capabilities  [30] [31] [32] [33] [34] [35] [36]. Coupled to microfluidics and microfabrication which allow the massive screening of experimental conditions, the fabrication of chemical reactors with arbitrary geometries or the control of chemical reactions with electrical or opticals signals  [37] [38] [39] [40] [41] [42] [43] , the community of DNA nanotechnology has been exploring reaction-diffusion as a way of building and programming matter at the micro-scale  [44] [45] [46] [47] [48].
GPUs have also boomed thanks to the coming of age of deep learning, which has prompted massive investment on GPU-based technologies. Their memory and their precision (two of their historical weak points) have increased in the past decade. Professional GPUs now routinely embark ∼10-20 GB of RAM and support double precision computations, which enable much finer grained simulations than was possible a decade ago. On the software side, CUDA libraries have matured in the past decade, with noticeable gains in performance. It is thus an interesting exercise to revisit the gain of performance with state-of-the-art CPUs (20 cores), GPUs (Titan V) and software libraries (CUDA 10). Reaction-diffusion systems are a perfect example of PDEs with complex dynamics, describing chemicals diffusing freely in a space while reacting with each other.
Contrary to the fixed grid of the finite difference method, meshes allow for a flexible attribution of the computational budget. The physics of regions with an irregular geometry (e. g. , turns in a maze) can be better fit by devoting more cells to their approximation. It must be noted that the problem of tessellating a geometric region into a mesh is an active topic of research, and will not be covered in this paper (we produce the mesh with Mathematica  [69] ). A mesh is associated with a basis of function ϕ i (x), which is commonly defined to be 1 at the node i, and null on the other nodes. Again, there are many possible ways of defining how ϕ i (x) varies between nodes (piece-wise linear, piece-wise quadratic,. ), and we use the basis of functions selected by the FEM software. Following the Galerkin method  [70] , we search for solution of Equation (  3 ) on the basis of functions ϕ i (x) N(x, t) = ∑ m i=1 N i (t)ϕ i (x) P(x, t) = ∑ m i=1 P i (t)ϕ i (x) (4) where N i (t) and P i (t) are the concentrations of species N and P at the node i and time t, and m is the number of nodes.
Assembly of Stiffness and Damping Matrices We used Mathematica  [69]  to assemble the stiffness and damping matrices. We started from a PNG image of a maze, which we binarized and converted into a geometrical region. We then discretized this region into a mesh with the FEM package of Mathematica, and assembled the corresponding damping and stiffness matrices. We controlled the size of the matrices (and the number of elements in the mesh) by changing the maximum allowed cell size during the discretization (smaller cells yield larger matrices). We then exported the matrices in CSV format.
Resolution of the Matrix Differential Equations The bulk of the resolution was handled at a high level by a python program, which in turns called a C++ library accelerated using CUDA libraries (including CuBLAS  [74]  and CuSparse  [75] ) and home-made CUDA kernels to solve equation at a low level on the GPU. After parsing the damping and stiffness matrices from the CSV file, the python program loaded them onto the GPU. For the diffusion operator, we solve the linear system with the conjugate gradient method (CGM) [72,  73, 76] , as described in Algorithm 1. Each iteration of the CGM consists mostly of three operations:  (1)  products between a sparse matrix and a vector (which are handled by CuSparse  [75] ); (2) additions of two vectors (detailed in Algorithm 2); and (3) dot products between vectors.
Comparison GPU and CPU We compared the performances of the GPU and the CPU with the same algorithm (pointwise operation for the chemical reaction operator, and conjugate gradient method for the diffusion operator). We solved the system on GPU with a NVIDIA GPU Titan V (5120 CUDA cores, 12 GB memory, peak performance of 14. 90 TFLOPS for FP32 and and 7. 450 TFLOPS for FP64). We solved the system on CPU with a Intel Xeon Gold 6148 (20 Cores, 40 threads, base frequency 2. 40 Ghz) equipped with 188 GB ECC RAM. We estimated the power consumed by the GPU with the nvidia-smi command, and the power consumed by the CPU with the powerstat command (the power consumed by other electronic components such as the RAM or the disk is negligible). Simulations were performed in a Linux Mint 19. 2 environment, with the CUDA library 10.
Crowdsourced Detection We rely on three different crowdsourced detection methodologies to start a CsLoc analysis. Note that they may trigger CsLoc independently, therefore several triggers may exist for the same earthquake. CsLoc is initiated by the detection of increased traffic at the EMSC website, www. emsc-csem. org (Bossu et al. , 2014) ; the detection of increased number of launches of the EMSC LastQuake smartphone application  (Bossu et al. , 2018) ; and the detection from the Twitter Earthquake Detection (TED,  Earle et al. , 2011)  system that follows the keyword "earthquake" in 59 languages in tweets of less than seven words because people tend to react to stressful events such as earthquakes in just a few words. The TED system was developed by the United States Geological Survey National Earthquake Information Center (NEIC), and it is currently used in the EMSC crowdsourced detection system.
As the EMSC becomes more known by the public, we will probably need to adjust our triggering system to take account of greater levels of traffic but the current system has worked well for since 2014. Crowdsourced detections are typically obtained before the first seismic location is made, therefore the CsLoc procedure starts without having a location provided by local or regional seismic networks. Once a crowdsourced detection is made, the centroid of the largest cluster of geolocations of the users within 120 s before the detection time and within the country where the detection was made is passed to the CsLoc association module  (Steed et al. , 2019). The cluster centroid and the crowdsourced detection time serves as an initial guess for the earthquake location, and as noted above, several CsLoc processes could be initiated for the same event.
The system collects arrival picks within 1000 km (for regions with sparse networks up to 2000 km) distance of the crowdsourced initial location from the global GEOFON Program (73 FDSN networks as used in  GEOFON Data Centre, 2019; Steed et al. , 2019)  that includes some 800 stations. The P-wave arrival picks are received in real time from 210 s before until 120 s after the crowdsourced detection time using the GEOFON HTTP Message Bus  (Heinloo, 2016).
The LastQuake app asks for the user's permission to access their mobile phone's location, otherwise it determines the user's location using triangulation or wifi. Some 80% of users allow the use of location services, therefore the app triggers are considered the most accurate. Furthermore, the website and app detection systems are monitored in each country separately. The Twitter  detection system determines the location of the user from the profile of the author found in each tweet. It also tries to divine the user's location based on the language used in the tweet. Therefore, the accuracy of TED triggers may also exhibit a large scatter. Because of the various triggers, it is not uncommon that there are several crowdsource detections for the same event. CsLoc is robust enough to reach accurate locations, even if the initial location is far off.
However, it helps to identify these multiple strains early on. We analyzed our data set to find reasonable criteria to decide if two crowdsourced detections are generated by the same event. We found that events with a large number of seismic arrivals and those with just a few seismic arrivals require separate logic. We rely on the assumption that if two solutions share a fair amount of common seismic arrival picks then the events are likely to be the same. For candidate events for multiple triggers we check the number of common seismic arrivals for each event pair. If the number of common seismic arrival picks is larger than 20, we declare the two events common. For events with just a few picks, we require at least three common seismic arrival picks and that 20% of the seismic phases be shared between the events to declare them the same.