dataesr/scientific-paragraphs-categorization huggingface dataset:
Relationship to other toolboxes NeuroPycon is not an alternative toolbox designed to replace or compete with existing software. On the contrary, the strength of Neu-roPycon is that it builds upon existing tools and brings them into a unifying framework, through the Nipype engine. This has several immediate advantages over individual toolboxes: (1) NeuroPycon can be used to compare results of using different algorithms from different existing toolboxes (e. g. wrapping MNE, brainstorm, SPM and fieldtrip, into a single NeuroPycon pipeline allows for simple and direct comparison of source estimation -implemented in distinct toolboxes-in a common framework), (2) NeuroPycon pipelines can be very exhaustive, including all processing steps needed to go from raw data (functional and structural) to group-level statistics of source-space connectivity and graphtheoretical analyses.
Because each pipeline is associated with a shareable parameter file with all the parameters for all the nodes, the whole analysis can easily be replicated. (3) The unifying framework of Neuro-Pycon also provides an ideal environment for multimodal fusion. For example, the graph package can be used with fMRI and MEG or EEG data from the same individuals and provides a practical framework to compare or integrate data from different brain imaging modalities, (4) A further advantage of NeuroPycon, compared to other available individual tools, is that it benefits from Nipype's efficient computing functionalities, such as embedded multi-threading for parallel processing and caching, which is very useful when it comes to data sets of large cohorts, (5) In addition to benefiting from the known advantages of Python, the fact that all the analyses happen in a single programming environment means that the user does not need to be familiar with different languages that the tools are programmed in, and (6) Finally, because NeuroPycon integrates available open tools, all improvements and new functionalities that are added to these toolboxes, will be readily available to NeuroPycon and so NeuroPycon's strength will continually grow as the individual toolboxes continue to improve.
Discussion NeuroPycon is an open-source analysis kit which provides python pipelines for advanced multiprocessing of multi-modal brain data. It consists of two primary, complementary components: ephypype, which facilitates preprocessing and source localization pipelines; and graphpype, which integrates spectral and functional connectivity pipelines, as well graph analysis pipelines. NeuroPycon is based on the Nipype engine and inherits thereby its philosophy of wrapping multiple established processing software tools into a common data analysis framework. The use of NeuroPycon allows for portability, simplified code exchange between researchers, and reproducibility of the results by sharing analysis scripts. Additionally, conducting graph-theoretical analysis in NeuroPycon allows for comparing and merging graph results from different imaging modalities and different toolboxes (which might be implemented in different programming languages).
NeuroPycon is designed for users with a reasonable knowledge of the software tools that it can wrap. But who would like to benefit from automatic implementation (ready-to-use pipelines) of features that would be otherwise more complex (or impossible) to implement. Parallel processing and caching are features that are particularly powerful and convenient when it comes to large data sets. NeuroPycon could also become very valuable for users who want to process multimodal data (e. g. MEG and fMRI) in a unified framework. Last but not least, students and researchers will hopefully find NeuroPycon to be a convenient framework to easily share MEG/EEG analysis pipelines. In terms of ongoing and future development, we plan-among other things-to make NeuroPycon BIDS-compatible so that the inputs are BIDS datasets and the intermediate outputs comply with the upcoming BIDS derivative specification.
Acknowledgements AP was supported by a  CNR  short-term mobility grant. KJ was supported by funding from the  Canada Research Chairs program  and a  Discovery Grant  ( RGPIN-2015-04854 ) from the  Natural Sciences and Engineering Research Council of Canada , a  New Investigators Award  from the  Fonds de Recherche du Qu ebec -Nature et Technologies  ( 2018-NC-206005 ) and an  IVADO-Apog ee fundamental research project grant. This research is also supported in part by the  FRQNT Strategic Clusters Program  ( 2020-RS4-265502  - Centre UNIQUE -Union Neurosciences & Artificial Intelligence -Quebec ).
In our new data reduction method, we use the 'zero-mask' method  (Holland et al. 2017) , which uses the Dynamic Iterative Map Maker within the SMURF package  (Chapin et al. 2013). This procedure assumes that the only astronomical signal is within a 60 arcsec diameter region centered on our target. We then apply a matched filter, where we convolve the image with the beam-size (∼13 arcsec). The pixel size of the final maps is one by one arcsec. We use the same data reduction technique on the flux calibrators to get an accurate flux conversion factor (FCF). The FCF for each source was derived by calibrator observations taken in the same night, and are linearly interpolated between multiple calibrator sources, depending on the time of the observation of the source. These FCFs range between 575 and 760 mJy pW -1 beam -1 , in range with the values seen in  Duivenvoorden et al.
R E F E R E N C E S Table A1. The HerBS sample -SPIRE and SCUBA-2 data. The HerBS number hyperlinks to the NED database at the position of the source. The RA and DEC are the SPIRE-positions, RA and DEC are the SPIRE positions minus the SCUBA-2 positions. Cursive SCUBA-2 observations are classed as non-detections, as discussed in section 3 of  Bakx et al. (2018). The spectroscopic redshifts are derived according to the protocols described in section 4 of  Bakx et al. (2018) , where cursive spectroscopic redshifts refer to single-line detections which are considered tentative. z phot,temp refers to the template derived in section 4 of  Bakx et al. (2018) , and z phot,Ivi refers to the photometric redshift estimates described in  Ivison et al. (2016)  and  Bakx et al. (2018). The bolometric luminosity is calculated using the fitted photometric template from  Bakx et al.
Most importantly, most bacterial chromosomes are circular. From the perspective of Hi-C visualization, this raises the ineluctable problem of representing a physical system with spherical symmetry using a two-dimensional Euclidean space. That is, the standard square matrix or horizontal band representations commonly used for Hi-C data are not appropriate for a system with periodic conditions as those associated with bacterial chromosomes. In particular, there is currently no tool, to the best of our knowledge, allowing to display Hi-C heat maps in a circular strip. Here, we fill this gap by developing a Python library, circhic, that efficiently displays bacterial Hi-C data accordingly. The library further includes the possibility to overlay genomic data. It also includes the possibility to handle linear chromosomes and, hence, can be used to visualize eukaryotic data.
III. IMPLEMENTATION We built upon the popular visualization library Matplotlib  (Hunter 2007) , using core libraries of the scientific Python ecosystem (numpy, pandas,. ). circhic relies on an object oriented approach, where a figure (the core object of the library) holds all the necessary elements for the visualization: the size of the genome, the orientation of the plot, and a number of information relating to the size and shape of the figure. A number of methods can then be executed to visualize the data: plot hic provides support for transforming the square contact count matrix into a circular one, and plot lines, plot bars,. allow to overlay relevant genomic information onto the contact count matrix.
Our approach for this evaluation is based on emulation: the largest part of real code that implement our system is used and the rest of the system is simulated. We use the LEPTON emulator  [29]  for conducting the evaluation (see  [29]  for a detailed description of the advantages of the emulation approach in opportunistic computing). This allows us to run the same code as the one we deployed on Android mobile devices for almost all the service middleware platform (the C3PO opportunistic networking layer as well as the service provision layer and the service composition layer), while remained simulated the mobility of nodes, the D2D radio communication, and the application behavior. We tried to be reasonably realistic when applying simulation. Although there are multiple situations in which our service platform could be used, we focused our evaluation on handheld devices powerful enough to run the platform (typically smartphones or nano computers), namely for practical reasons, and because there are generic enough to encompass a wide range of applications in which opportunistic networking is a necessity and the volume of data exchanged could be high (of the order of mega-bytes per transmission).
Context. Resonant lines are powerful probes of the interstellar and circumgalactic medium of galaxies. Their transfer in gas being a complex process, the interpretation of their observational signatures, either in absorption or in emission, is often not straightforward. Numerical radiative transfer simulations are needed to accurately describe the travel of resonant line photons in real and in frequency space, and to produce realistic mock observations. Aims. This paper introduces rascas, a new public 3D radiative transfer code developed to perform the propagation of any resonant line in numerical simulations of astrophysical objects. rascas was designed to be easily customisable and to process simulations of arbitrarily large sizes on large supercomputers. Methods. rascas performs radiative transfer on an adaptive mesh with an octree structure using the Monte Carlo technique.
2013) , or it may be necessary to post-process the simulation to estimate the emissivities of the gas. This first step is very simulation-and modeldependent, and rascas chooses to encapsulate it in a simulationplugin module and to implement two stand-alone pre-processing codes which generate an adaptive mesh with all the needed physical information about the gaseous medium, and the initial conditions for light emission in the form of lists of photon packets. These datasets, which could easily be generated from other simulations with any post-processing code, serve as inputs to rascas to perform the radiative transfer computation. The core of rascas, is then the second step, which is passive radiative transfer, passive in the sense that radiation does not affect the properties of the gas. Here rascas inherits directly from the code McLya  (Verhamme et al.
We detail below how we compute these terms in different configurations. In the framework of rascas, this first step is done by a standalone code which generates a simple photon packet initial con-L. Michel-Dansac , J. Blaizot, T. Garel, A. Verhamme, T. Kimm, M. Trebitsch : RASCAS dition (PPIC) file for each experiment. This file contains a list of photon packets, each with an ID, a position, a direction, and a frequency. These PPIC files are then fed to rascas, which propagates each photon packet regardless of the sources. This very flexible approach is possible because the radiative transfer done with rascas is passive (i. e. it does not change the properties of the gas). It allows statistics to be added incrementally by regenerating additional PPIC files on demand, and it makes it very easy to combine different signals (e.
Fluorescent lines A number of transitions of great observational interest originate from ions that have more complex level structures than simple resonant transitions, in the sense that one absorption channel, say from level l 1 to level u, leads to more than one decay channel, down to levels l 1 , l 2 ,. We refer to these transitions of type ul 2 as fluorescent, and a few examples are given in Table  A. 1. rascas deals with these lines easily by having one module per absorption channel. The absorption of photon packets is computed exactly as for resonant lines, but re-emission has a probability of being non-resonant according to the following ratio of Einstein coefficients: P ul i = A ul i i A ul i. ( 16 ) In the case of fluorescent re-emission, rascas simply casts a photon with ν ul i in the frame of the scatterer, assuming an isotropic phase function.
(2006)  who used an approach similar to that of  Neufeld (1990). Again, we confirm that rascas recovers the expected line profile well, especially in the very optically thick regime (τ H i 10 6 ). In order to test our code in a non-static experiment, we also perform the simulations of  Laursen et al. (2009b)  since no analytic solution exists for Lyman-α propagation in moving media. The bottom panel of Fig. 7  shows the spectra for three homogeneous spherical outflow models at T = 10 2 K where the gas velocity increases linearly with radius from 0 to a maximum velocity V max. For high outflow velocities (V max = 200, 2000 km s -1 ), the resulting line profiles are asymmetric and are shifted towards negative x (i. e. longer wavelengths), while for V max = 20 km s -1 a fraction of the photons can escape with positive x values (i.
Distributed radiative transfer on adaptive meshes In a typical rascas run, radiation is propagated in structured media defined on adaptive meshes, and within a finite volume. From that viewpoint, Sect. 3 describes what happens within a single simulation cell, and the present section explains how we apply MCRT to a full AMR simulation. One of the main requirements of rascas is to limit the memory footprint of the code so that it can be used to process very large simulation outputs on supercomputers with limited RAM per core. This is achieved with (1) domain decomposition (Sect. 4. 1), (2) a flexible interface to extract physical quantities from a simulation output (Sect. 4. 2), (3) efficient indexing (Sect. 4. 3), and (4) a distributed master-worker scheme with optimal adaptive load-balancing (Sect.
4. 4). The three first points above are dealt with in a pre-processing step using the stand-alone code CreateDomDump. This code re- Left: Mean number of scatterings until escaping the slab as a function of the vertical H i opacity τ H i. rascas runs are shown by black symbols for different assumed gas temperatures (T = 10, 10 2 , 10 4 K). The red dashed line corresponds to the analytic approximation found by  Harrington (1973) , N scatt = 1. 612τ H i. Middle: Variation of the emergent spectrum as a function of τ H i. The solid coloured lines are the results from rascas, while the black dashed curves are the analytic predictions of  Neufeld (1990). We assume T = 100 K, no recoil effect, and an isotropic angular redistribution. Right: Evolution of the Lyman-α escape fraction f esc as a function of dust optical depth (τ dust ) in the case of a slab with τ H i = 10 6 and T = 10 2 K.
We chose to keep this pre-processing step independent of the MCRT step, in the same spirit as for the casting of photons (see Sect. 2). There are three main reasons. First, this step is not CPU 6 Although rascas is not strictly object oriented, it is very much so in spirit, and we use the object-oriented nomenclature when it improves clarity. 7 The slab is literally a slice of the simulation box defined only by a thickness in one dimension, and infinite in the two other dimensions thanks to periodic boundary conditions expensive; on the contrary, it is I/O expensive and possibly requires a lot of memory. Second, it may be necessary to run this code iteratively in order to adjust the free parameters, for instance the parameters of the domain decomposition. Last but not least, it uses the simulation data, so it is best to run this code where the simulation data is stored and then to transfer the relatively light meshes to the computer where MCRT will be computed.
9 , where two data domains (blue and pink shells) are used to cover the computational domain (sphere outlined with the black circle). The data domains should overlap significantly to minimise photon packets bouncing back and forth between data domains. They should extend slightly beyond the computational domain in order to make sure that all cells intercepted by the computational domain are included in at least one data domain. Using small data domains has two advantages. The first is that the propagation through the mesh should be computationally efficient because it is compact in memory. The second is that each mesh has a controlled and limited size in memory, allowing us to post-process any simulation whatever the RAM of the machine. We provide a stand-alone code CreateDomDump, which can be used to perform domain decomposition for some pre-defined typical geometries.
RASCAS Laursen+09 Fig. 7 : rascas simulations of the transfer of Lyman-α photons (x in = 0) emitted at the centre of a uniform sphere at T = 10 2 K. Top: Variation of the emergent spectrum as a function of τ H i for a static sphere. The solid coloured lines are the results from rascas, while the black dashed curves are the analytic solutions of  Dijkstra et al. (2006). Bottom: Non-static sphere with a H i column density of 2 × 10 21 cm -2 in which the gas velocity increases linearly with radius from 0 at the centre to V max at the edge of the outflow. The spectra predicted by rascas (curves) are compared to  Laursen et al. (2009b) , who did the same experiments with their code (crosses). halo (Fig. 9 ), or as a series of cubes paving a large simulation box. Importantly, the data domains need not correspond to the domains that the simulation code (e.
In the current version of rascas these external subroutines are built for ramses  (Teyssier 2002)  and ramses-rt  (Rosdahl et al. 2013) , and packaged in a single ramses module. Such a module may easily be constructed for other simulation codes, and would simply need, in the above example, to contain subroutines that will compute n H i , v cell , v th , and n dust. Third, the gas_composition class implements public methods that return useful quantities such as the optical depth along a given distance, or that perform scattering and/or absorption events. These methods are easily written, as they also rely on external classes that package ion-transition and dust properties. The current implementation of rascas provides classes for transitions listed in Table  A. 1. They represent a vari-Fig.
2017, Sect. 2. 2). Here, we make the slightly different choice to rely on functions that are very closely connected to the simulation code (ramses in our current implementation) instead of generic functions that, although correct, may not be fully consistent with the assumptions made in the simulation. This choice is also motivated by the fact that we are mostly interested in processing ramses-rt simulations, which provide the non-equilibrium H i density in all cells directly, accounting for a non-uniform ionising radiation field. This being said, the modular nature of rascas makes it very easy to plug ion_balance or an equivalent into the gas_composition class instead of our default ramses module.
We cast N p = 10 6 photons (only 10 3 for the experiment with τ H i = 10 6 ) from the centre of the sphere in random directions, and integrated their travel distances. We then compared these distances to the theoretical distance. For the run with τ H i = 10 -10 , there is no scattering event, and the integrated distance is exactly equal to the theoretical distance. In other words, the relative error is zero for all photons. For τ H i = 10, almost all photon packets have scattered a few times, and there is a tiny difference between the integrated distance and the theoretical one. These errors are of the order of 10 -15 , the me-A&A proofs: manuscript no. rascas dian is zero and 98% of the photon packets have an error between -9 × 10 -16 and 9 × 10 -16. This error is comparable to the numerical precision ∼ 2 × 10 -16 of floating point in double precision in Fortran 9.
Scaling of the code In this section, we discuss the scaling of the code with the number of CPUs. We used rascas in a realistic set-up by running the following experiment. We propagated 10 6 monochromatic Lyman-α photon packets emitted in star-forming regions through the ISM and CGM of an idealised disc galaxy simulation. The gas is composed of H i, D , and dust. Photon packets were propagated until either they escape the virial radius of the dark matter halo or they are absorbed by dust. We repeated the same experiment for various numbers of CPUs ranging from 32 to 1024. The results are shown in Fig. 11  where the almost perfect scaling of rascas can be seen. This series of runs was done with one single data domain. In principle, this is the most favourable configuration, as it limits both the Red symbols show the results for the series where the computational domain is decomposed into one single data domain, whereas the blue crosses (respectively green crosses) are for the case where the computational domain is decomposed into 10 (resp.
Summary and conclusions In this paper, we have presented a new public 3D Monte Carlo code called rascas to compute radiative transfer of resonant lines in simulations of astrophysical objects. rascas is written in modern Fortran. The main features of rascas are the following: 1. rascas computes radiative transport of resonant-line photons through complex mixes of species (e. g. H i, Si ii, Mg ii) and dust. Although it is designed to accurately describe resonant scattering, rascas may also be used to propagate photons at any wavelength (e. g. stellar continuum or fluorescent lines). 2. rascas performs RT on an adaptive mesh with an octree structure very similar to that used and produced by ramses. With very little effort, rascas can be extended to use any (irregular) mesh structure. 3. rascas can be easily used to perform RT experiments through idealised gas distributions (e.
g. expanding shells, discs) instead of simulations. 4. rascas includes tools which allow the user to sample different sources of radiation. In the current distribution, these include a code to spawn photon packets from star particles, taking into account their ages and metallicites and using various SED libraries, and a code to spawn Lyman-α photons emitted by the gas, taking into account both recombination and collisional contributions. rascas also features a simple code to produce ad hoc sources which may be used for tests or idealised models. 5. The default outputs of rascas are lists of photon packets collected when they escape the computational domain. These are typically analysed through a python class that is provided in the distribution. 6. rascas also features a standard peeling algorithm which allows the user to construct mock observations in the form of spectra, images, or datacubes on-the-fly.
9. rascas has been fully tested against RT problems with analytic solutions and against various test cases proposed in the literature. In all cases, the agreement between rascas and published results is very good. 10. The rascas code is publicly available 11. Future developments of the code will be released and documented at the same URL. rascas has been designed to be both easy to use and easy to develop, and we hope to share future developments with a growing community.