dataesr/scientific-paragraphs-categorization huggingface dataset:
FMRI retinotopic mapping is a non-invasive technique for the delineation of low-level visual areas in individual subjects. It generally relies upon the analysis of functional responses to periodic visual stimuli that encode eccentricity or polar angle in the visual field. This technique is used in vision research when the precise assignation of brain activation to retinotopic areas is an issue. It involves processing steps computed with different algorithms and embedded in various software suites. Manual intervention may be needed for some steps. Although the diversity of the available processing suites and manual interventions may potentially introduce some differences in the final delineation of visual areas, no documented comparison between maps obtained with different procedures has been reported in the literature.
, 2010). Slight errors in segmentation or alignment can hamper the cortical organization assessment  (Olman et al. , 2010). Spatial smoothing in the surface and detection of visual field sign allow manual or automatic delineation for retinotopic visual areas. The visual field sign can be computed as the Jacobian of the visual field representation on the surface  (Sereno et al. , 1995; Warnking et al. , 2002). All these steps rely on various methods embedded in different software suites such as BALC  (Warnking et al. , 2002) , MrVista  (Wandell et al. , 2000) , BrainVoyager  (Goebel et al. , 2006) , FreeSurfer  (Fischl et al. , 2001 ), or Caret (Van Essen et al. , 2001). We hypothesized that the diversity of the suites used and the manual intervention needed for some steps (i. e. , functional and structural perfect alignment in the occipital lobe, correction of cortical volume topology or delineation of the areas borders) may introduce potential differences on the final visual area localization.
The goal of our study was to document these differences if any and to explore their impact on the interpretation of the cognitive activation projected onto these maps. For this purpose, we report the retinotopic maps obtained using two experts and two software suites: BALC and BrainVoyager and document their consistency and differences. Generally, fMRI retinotopic maps are computed and then used as localizers in relation with a specific cognitive experiment. Indeed, cortical activation produced by a cognitive experiment in individuals is projected onto the corresponding retinotopic maps revealing which visual areas are involved in information processing. We document the consistency between color center mapping data projection using one chain or the other. Our goal was not to demonstrate the superiority of one solution to the other.
These software were chosen because they were mastered by the authors and were representative of possible solutions for retinotopic mapping. Our results confirm the robustness of the activation induced by phase-encoded designs for low-level areas identification and the consistency between data projection in most cases using one chain or the other. Beyond V3, delineation requires a careful mastering of the phase encoding technique, the introduction of additional knowledge or hypothesis as a priori information (like V4 having an hemifield rather than quarterfield representation  Brewer et al. , 2005)  to obtain accurate and reliable maps for all subjects. Our results also indicate that the procedure to assign to individual retinotopic map the cortical activation following a cognitive experiment is not free of error.
Experiments All subjects participated in two fMRI experiments. Experiment 1, retinotopic mapping, was aimed at localizing retinotopic visual areas. Experiment 2, color center mapping, was aimed at localizing the functional responses produced by the introduction of chromatic contrast. Visual stimuli were created with Matlab (Mathworks, Inc. , Natick, MA) and controlled during the experiment by a PC, running Windows XP with customized software written in C++ and using the SDL library for a precise control of timing. The stimuli were presented to the subjects using a video-projector (Epson 7250 M, Epson Inc. , Long Beach, CA). Stimuli were back-projected on a translucent screen positioned at the rear of the magnet. Subjects viewed this screen at a distance of 222 cm via a mirror fixed on the head coil.
MR Data Acquisition Images were acquired on a Bruker 3T Medspec S300 system whole body scanner (Grenoble MRI facility IRMaGE). A transmit-receive quadrature birdcage headcoil (Bruker) was used. Structural, functional, and static magnetic field (for B0 field inhomogeneity correction) data were acquired in a single scanning session. Static field homogeneity was optimized prior to acquiring the structural data, using the routine first-order shimming procedure. High-resolution structural images were acquired using a T1-weighted 3D MP-RAGE sequence optimized based on  Deichmann et al. (2000). For each subject 176 sagittal partitions were acquired in two segments with an image matrix of 256 x 112 (read x phase). Further imaging sequence parameters were: TR/TE/TI: 16/4. 96/903 ms, excitation pulse angle: 8 • , acquisition matrix: 256 x 224 x 176 (CC, AP, LR), fast phase encoding direction: AP (112 steps per RAGE train, 2 segments), slow phase encoding direction: LR, isotropic nominal resolution: 1 mm, BW = 130 Hz/Px, readout direction: CC, number of averages: 1 and total measurement time: 14 min 40.
The conjoint field correction and realignment procedure was realized using the SPM8 Unwarp toolbox. In a final step, all EPI data sets were aligned with the structural data set using the SPM8 rigid body coregistration procedure. Spontaneous blinks during fMRI generate strong BOLD activation in the visual cortex and this activation strength is comparable to that evoked by visual stimulation  (Hupé et al. , 2012a). We analyzed the oculomotor signal using a custom interactive software developed in Matlab  (Hupé et al. , 2009)  and using the basic data structure of ILAB software  (Gitelman, 2002). Based on our expertise and the use of our interactive software, we properly identified the set of spontaneous blinks with a semi-automated procedure. For Experiment 2, for each run and subject, we computed a predictor based on eye blinks (blinks predictor).
Volume-Based Analysis of Color Center Data We used the data of the color localizer sequence to identify hot spots of maximum color sensitivity in each subject. The logic and the precise procedure are detailed in the supplemental information of  Hupé et al. (2012b). We used the ROIs defined for that study. Briefly, for each subject we used a conjunction contrast: we considered voxels as active if they responded more to both colored and achromatic Mondrian compared to the fixation point, and more to colored than achromatic Mondrians. We added a predictor based on eye blinks as a non-interest factor. For each subject, we first set the threshold at the 0. 05 FDR level (False Discovery Rate), which value ranged between t = 3. 37 and t = 5. 21 (average t = 4. 31). Then we increased the threshold in order to capture a larger number of active clusters within the ventral cortex (color centers), in or anterior to V4 (threshold values ranged between t = 2 and t = 3.
Retinotopic map generation The EPI datasets were analyzed voxel-wise by complex valued Fourier transformation, to determine amplitude and phase of the signals at the stimulation frequency (see details in  Warnking et al. (2002) ). The results of the volume-based analysis of the (four) retinotopic experiments were stored, for each visual coordinate, as a pair of parametric data volumes containing respectively phase and signal-to-noise ratio at the stimulation frequency. For generating retinotopic maps, phases were assigned to the cortical surface model as described in  Warnking et al. (2002). The phase at each node of the surface model was estimated as a linear combination of the phases stored in a selection of voxels from the parametric data volume. Voxels from the parametric data volume that were retained in this selection had their center at most 3 mm away from the closest node of the surface model.
Retinotopic map generation We averaged (using Matlab) the two wedges and rings recordings, one of them read backwards before averaging. This procedure is convenient for generating modulated sinusoidal signals within retinotopic areas and cancelling out phase errors caused by hemodynamic delays  (Warnking et al. , 2002). With BV we computed correlation analyses with 16 sinusoidal functions with different phases (phase difference equal 0. 2 rad between two consecutive functions) to obtain power and phase maps for both eccentricity and polar mapping. Phase maps were thresholded at a correlation of 0. 2 (t = 3. 15, p = 0. 001) and projected on the cortical flat maps. V1 was identified as running along the calcarine sulcus. Borders between visual areas (identified as phase reversals) were then drawn by hand (and not automatically and then manually refined as done with BALC) on the polar phase maps, with simultaneous visualization of the eccentricity map to insure that the borders ran perpendicularly to the eccentricity gradient.
Corresponding functional images were first preprocessed with the identical SPM pipeline and then processed using two chains, BALC or BrainVoyager (BV). Structural images were segmented using an unique software (LOCUS) and only the surface reconstruction is software (BALC or BV) dependent. Top: with BV, starting from a segmented structural image, a 3D model of the cortical surface was reconstructed (here seen from the back and slightly below). Based on wedges (top) and rings (below) recordings, retinotopic areas were manually delineated and labeled on the surface. Bottom: using BALC, the region of each hemisphere posterior to the parieto-occipital sulcus was unfolded. Projection onto these surfaces of functional data corresponding to wedges (top) and rings (below) allowed the automatic delineation of the retinotopic areas.
Functional retinotopic mapping involves several generic prone-to-error key steps: cortical surface reconstruction, 3D functional data projection to the surface and area borders delineation. Our study accurately documents the generated errors intrinsic to the procedure, implemented in two different ways and including a manual or automatic delineation of the area borders. Because other available software suites such as MrVista  (Wandell et al. , 2000) , FreeSurfer  (Fischl et al. , 2001 ), or Caret (Van Essen et al. , 2001)  rely on the same generic steps, we may suppose that, similarly, differences would be observable in the majority of subjects. Our results demonstrate that despite differences in data processing, retinotopic maps are coherent between different chains. This indicates that individual functional retinotopic maps obtained in different centers with different procedures may be shared in freely available databases for the design of functional landmark-based probabilistic atlas of low level visual areas  (Corouge et al.
Funding Cécile Bordier  is recipient of a post-doctorate grant from the  Institut de la Santé et de la Recherche Médicale (INSERM, France). Research funded by  Agence Nationale de la Recherche   ANR-11-BSH2-010. Grenoble MRI facility IRMaGe was partly funded by the  French program  " Investissement d´avenir " run by the  Agence Nationale pour la Recherche  grant " Infrastructure d´avenir en Biologie Santé " - ANR-11-INBS-0006.
The manual scoring of these CAs proved to be straightforward and reliable. This improvement has made it possible to establish the first dicentric doseeresponse curve for a PCC fusion. In addition, a software tool was developed (PCC-TCScore) for the automation of dicentric and centric ring scoring in PCC fusions. Using this approach, it was possible to generate a doseeresponse curve for dicentric and centric rings indistinguishable from that generated by manual scoring.
Slide scanning, interphase acquisition, and CA detection The PCC fusions were automatically detected using MSearch software (MetaSystems, Altlussheim, Germany). Telomere and centromereestained PCC fusions were acquired using automated acquisition module Autocapt software (MetaSystems, version 3. 9. 1) using a Zeiss Plan-Apochromat 63Â/1. 40 oil and CoolCube 1 Digital High Resolution CCD Camera (Carl Zeiss, Jena, Germany). Manual scoring of PCC aberrations was performed using Isis software (version 5. 5; MetaSystems). For automatic scoring of CA after TC staining of PCC fusions, the acquired gallery was exported as a series of RGB bitmap images exploitable by any image-processing software. The 3-channel image contained the DAPI (4 0 ,6diamidino-2-phenylindole) information in the blue channel, and the telomere and centromere information in the red and green channels, respectively.
Using the software tool developed in our laboratory (PCC-TCScore), the chromosomes were automatically segmented on the DAPI channel, where those of CHO were detected and filtered. A spatial position map of the telomeres and centromeres was created using information from the red and green channels. The chromosomes were then defined by classifying each object according to its corresponding attributes, and finally each was assigned to a corresponding aberration class (dicentric, centric ring, and acentric chromosome). The results must then be validated by the operator (Supplementary Data E3; available online at www. redjournal. com).
All of the information provided by TC staining allowed us to precisely calculate the number of DSBs that generated the CA: either a dicentric or a centric ring with a fragment containing 4 telomeres was considered as 2 DSBs. Excess acentric chromosomes are considered as resulting from 1 DSB for terminal deletions with only 2 telomeres and 2 DSB for interstitial deletion fragments with no telomeres. The formula used to calculate the DSB is provided in Supplementary Data E4 (available online at www. redjournal. com). Automatic scoring was performed only on TC-stained PCC fusions because there is no existing image analysis system for uniformly stained PCC fusions. To avoid observer bias, the slides were prepared, coded, hybridized, and analyzed blindly.
After the successful detection of CAs in PCC fusions and the establishment of a doseeresponse curve, the second step of this work was the semiautomation of the scoring of these aberrations using a new software that we have developed, called PCC-TCScore, which is independent of the image analysis system used. Using PCC-TCScore we have successfully detected on average 95% of dicentrics and centric rings compared with manual scoring, with the level of automated detection at or near 100% below 4 Gy, falling to 95% at 6 to 8 Gy. This high rate of detection is made possible owing to the robust recognition of CAs after TC staining, the high quality of the PCC fusions, and the validation step by the observer. It may be equally important to apply these tools to the field of low dose exposure, which is currently a growing public health concern.
It is nonetheless a very important property: It would allow users to assess the impact of the hardware on the software's performance-something that is very valuable in particular for developers of run-time systems-and it would allow other researchers to reproduce experiments on their system. Essentially, by deploying software and environment modules, HPC support teams find themselves duplicating the work of GNU/Linux distributions, but why is that? Historical package managers such as APT and RPM suffer from several limitations. First, package binaries that every user installs, such as. deb files, are actually built on the package maintainer's machine, and details about the host may leak into the binary that is uploaded-a shortcoming that is now being addressed (see Section 6. ) Second, while it is in theory possible for a user to define their own variant of a package, as is often needed in HPC, this is often difficult in practice.
Users of RPM-based systems, for example, may be able to customize a. spec file to build a custom, relocatable RPM package, but only the administrator can install the package alongside its dependencies and register it in the central yumdb package database. The lower-level rpm tool can use a separate package registry, which could be useful for unprivileged users; however RPM package databases cannot be composed, so users would need to manually track down and register the complete graph of dependencies, which is impractical at best. Third, these tools implement an imperative and stateful package management model  [3]. It is imperative in the sense that it modifies the set of available packages in place. For example, switching to an alternative MPI implementation, or upgrading the OpenMP run-time library means that suddenly all the installed applications and libraries start using them.
Functional Package Management Functional paradigm. Functional package management is a discipline that transcribes the functional programming paradigm to software deployment: build and installation processes are viewed as pure functions in the mathematical sensewhose result depends exclusively on the inputs-, and their result is a valuethat is, an immutable directory. Since build and installation processes are pure functions, their results can effectively be "cached" on disk. Likewise, two independent runs of a given build process for a given set of inputs should return the same value-i. e. , bit-identical files. This approach was first described and implemented in the Nix package manager  [3]. Guix reuses low-level mechanisms from Nix to implement the same paradigm, but offers a unified interface for package definitions and their implementations, all embedded in a single programming language  [2].
An obvious challenge is the implementation of this paradigm: How can build and install processes be viewed as pure? To obtain that property, Nix and Guix ensure tight control over the build environment. In both cases, build processes are started by a privileged daemon, which always runs them in "containers" as implemented by the kernel Linux; that is, they run in a chroot environment, under a dedicated user ID, with a well-defined set of environment variables, with separate name spaces for PIDs, inter-process communication (IPC), networking, and so on. The chroot environment contains only the directories corresponding to the explicitly declared inputs. This ensures that the build process cannot inadvertently end up using tools or libraries that it is not supposed to use. The separate name spaces ensure that the build process cannot communicate with the outside world.
Although it is not perfect as we will see in Section 5, this technique gives us confidence that build processes can indeed be viewed as pure functions, with reproducible results. Each build process produces one or more files in directories stored in a common place called the store, typically the /gnu/store directory. Each entry in /gnu/store has a name that includes a hash of all the inputs of the build process that led to it. By "all the inputs", we really mean all of them: This includes of course compilers and libraries, including the C library, but also build scripts and environment variable values. This is recursive: The compiler's own directory name is a hash of the tools and libraries used to build, and so on, up to a set of pre-built binaries used for bootstrapping purposes-which can in turn be rebuilt using Guix  [2].
1. Guix package recipe of Open MPI. Package recipes in Guix are written in a domain-specific language (DSL) embedded in the Scheme programming language. Figure  1  shows, as an example, the recipe to build the Open MPI library. The package form evaluates to a package object, which is just a "regular" Scheme value; the define form defines the openmpi variable to hold that value. ;; Query the direct and indirect inputs of Open MPI. ;; Each input is represented by a label/package tuple. (map (match-lambda ((label package) (package-full-name package))) (package-transitive-inputs openmpi)). yields: ("hwloc-1. 10. 1" "gfortran-4. 8. 5" "pkg-config-0. 28") Fig. 2. Querying the dependencies of a package object. Line 14 specifies that the package is to be built according to the GNU standards-i. e. , the well-known.
/configure && make && make install sequence (similarly, Guix defines cmake-build-system, and so on. ) The inputs field on line 15 specifies the direct dependencies of the package. The field refers to the hwloc, gfortran-4. 8, and pkg-config variables, which are also bound to package objects (their definition is not shown here. ) It would be inconvenient to specify all the standard inputs, such as Make, GCC, Binutils so these are implicit here; as it compiles package objects to a lower-level intermediate representation, gnu-build-system automatically inserts references to specific package objects for GCC, Binutils, etc. Since we are manipulating "normal" Scheme objects, we can use the API of Guix to query those package objects, as illustrated with the code in Figure  2 , which queries the name and version of the direct and indirect dependencies of our package  3.
With that definition in place, running guix build openmpi returns the directory name /gnu/store/rmnib3ggm0dq32ls160ja882vanb69fi-openmpi-1. -8. 1. If that directory did not already exist, the daemon spawns the build process in its isolated environment with write access to this directory. Of course users never have to type these long /gnu/store file names. They can install packages in their profile using the guix package command, which essentially creates symbolic links to the selected /gnu/store items. By default, the tree of symbolic links is rooted at ~/. guix-profile, but users can also create independent profiles in arbitrary places of the file system. For instance, a user may choose to have GCC and Open MPI in the default profile, and to populate another profile with Clang and MPICH2.
It is now gradually replacing other methods of software distribution, such as statically linked binaries on group network shares, relocatable RPMs installed into group prefixes, one-off builds on the cluster, and user-built software installed in home directories. The researchers use tens of bioinformatics tools as well as frameworks such as Biopython, NumPy, SciPy, and SymPy. The functional packaging approach proved particularly useful in the ongoing efforts to move dozens of users and their custom software environments from an older cluster running Ubuntu to a new cluster running a version of CentOS, because software packaged with Guix does not depend on any of the host system's libraries and thus can be used on very different systems without any changes to the packages. Research groups now have a shared profile for common applications, whereas individual users can manage their own profiles for custom software, legacy versions of bioinformatics tools to reproduce published results, bleeding-edge tool chains, or even for complete workflows.
;; This file can be passed to 'guix package --manifest'. (use-modules (gnu packages base) (gnu packages gcc) (my-openmpi)) (packages->manifest (list glibc-utf8-locales gnu-make gcc-toolchain openmpi)) Fig. 3. Declaring the set of packages to be installed in a profile. Guix supports two ways to manage a profile. The first one is to make transactions that add, upgrade, or remove packages in the profile: guix package --install openmpi --remove mpich2 installs Open MPI and removes MPICH2 in a single transaction that can be rolled back. The second approach is to declare the desired contents of the profile and make that effective: the user writes in a file a code snippet that lists the requested packages (see Figure  3 ) and then runs guix package --manifest=my-packages. scm. This declarative profile management makes it easy to replicate a profile, but it is symbolic: It uses whatever package objects the variables are bound to (gnu-make, gcc-toolchain, etc.