dataesr/scientific-paragraphs-categorization huggingface dataset:
Noise image In order to select a sample of radio sources above a given threshold, defined in terms of local signal-to-noise ratio (S/N), we derived a noise image using the task RMSD in the Astronomical Image Processing System (AIPS). The rms was calculated for each pixel based on the data in the box surrounding the pixel. The size of the box was chosen to be 60 pixels (i. e. 60 × 60 ). The rms was calculated on a multi-iteration basis, which excludes the points that are more than 3 times the rms derived from the previous iteration until convergence is reached. The noise distribution is not entirely Gaussian owing to the presence of residual sidelobes around the many bright radio sources in the field. The median rms is 50 µJy/beam. About 3% of the noise values are higher than 200 µJy and are located around the brightest sources in the mosaic.
RA and 2 DEC must be estimated from comparison with external data with better positional accuracy than the one tested. We calculated our calibration terms from the comparison between the position of single-component XXL ATCA radio sources with S/N>10 and their optical counterpart (62 sources in total). The mean values and standard deviations found from this comparison are ∆RA = 0. 24 ± 0. 34 arcsec and ∆DEC = -0. 12 ± 0. 22 arcsec. These position offsets are barely significant (6 and 4 times the error on the mean, respectively). Given the size of the beam and the error associated with the position of the bulk of weaker sources (comparable to or larger than the previous offsets) at this stage we assume no significant offset between the radio and optical frames. Once the full XXL-S field has been covered, we plan to investigate in greater detail any possible systematic and/or position-dependent offsets between the radio and optical positions.
Therefore, in the error budget we assume a calibration error 2 RA = 0. 34 arcsec in RA and 2 DEC = 0. 22 arcsec in DEC. An example page of the final source catalogue is shown in Table  1. The full catalogue is available as a queryable database table 'XXL_ATCA_15' via the XXL Master Catalogue browser 2. A copy will also be deposited at the Centre de Données astronomiques de Strasbourg (CDS) 3.
XXL ATCA source counts In this section we report the 2. 1 GHz radio source counts obtained in our ATCA observation in the XXL-S field. The completeness of the sample will be tested with the appropriate simulation (see  Bondi et al. 2003  for the description of the method) when the full radio data set becomes available over the entire XXL-S field. Therefore, in order to reduce problems with possible spurious sources near the flux limit and the effects of incompleteness, we construct the 2. 1 GHz ATCA radio source counts considering only the 1003 sources in the pilot survey with a flux density greater than 0. 35 mJy, corresponding to S/N 7. 0 (assuming an average rms of 0. 05 mJy, see section 3. 1). The source counts from our pilot sample are summarised in Table  2  where, for each flux density bin, we report the minimum and mean flux density, the observed number of sources, the differential source density n = dN/dS (in sr -1 Jy -1 ), the normalised differential counts nS 2.
cea. fr/xxl. Multiband information and spectroscopic follow-up of the X-ray sources are obtained through a number of survey programmes, summarised at http://xxlmultiwave. pbworks. com/. The Australia Telescope Compact Array is part of the Australia Telescope National Facility which is funded by the Commonwealth of Australia for operation as a National Facility managed by CSIRO. This research was funded by the European Union's Seventh Framework program under grant agreement 333654 (CIG, 'AGN feedback'). VS, JD and MN acknowledge funding from the European Union's Seventh Framework program under grant agreement 337595 (ERC Starting Grant, 'CoSMass'). VS acknowledges funding from the Australian Group of Eight European Fellowships 2013. FP acknowledges support from the BMBF/DLR grant 50 OR 1117, the DFG grant RE 1462-6 and the DFG Transregio Programme TR33.
Computing context As presented in part 1. 2, we used the ROMEO supercomputer to perform our tests and computations. On this supercomputer SLURM  [16]  is used as a reservation and a job queue manager. This software allows two reservation modes: a static one-job limited reservation or an opportunity to dynamically submit several jobs in a Best-Effort manner. Static distribution -In this case we used the synchronous distribution presented in 3. 3. 3. We submited a reservation with the number of MPI processes and the number of cores per process. This method is useful to get the results quickly if we can get at once a large amount of computation resources. It was used to perform the computation of small problems, and even for L(2, 23) and L(2, 24). As an issue, it has to be noted that it is difficult to quickly obtain a very large reservation on such a shared cluster, since many projects are currently running.
We empirically chose to run 15-20 minute tasks and thus we considered p = 15 for n = 27 and p = 17 for n = 28. The best effort based algorithm is presented on Fig. 16. The task handler maintains a maximum of 256 tasks in the queue; in addition the entire process is designed to be faulttolerant since killed tasks have to be launched again. When finished, the tasks generate an ouput containing the number of solutions and computation time, that is stored as a file or database entry. At the end the outputs of the different tasks are merged and the global result can be provided.
Best-effort overhead -With L(2, 27) we used a specific database to maintain information concerning the tasks: 617 tasks were aborted [by regular user jobs] before finishing (1. 9%), with an average computing time of 766" (43% of the maximum requested time for a task). This consumed 472873", which overhead represents 1. 6% of the effective computing effort. Cluster occupancy -Fig. 17  presents the tasks resolution over the two computation days for L(2, 27). The experiment elapse time was 164700" (1. 9 days). Compared to the effective computation time, we used an average of 181. 2 machines (CPU-GPU couples): this represents 69. 7% of the entire cluster. Fig. 18  presents the tasks resolution flow during the 23 days computation for L(2, 28). We used about 99 machines, which represents 38% of 230 available nodes.
Programs for Bayesian inference of phylogeny currently implement a unique and fixed suite of models. Consequently, users of these software packages are simultaneously forced to use a number of programs for a given study, while also lacking the freedom to explore models that have not been implemented by the developers of those programs. We developed a new open-source software package, RevBayes, to address these problems. RevBayes is entirely based on probabilistic graphical models, a powerful generic framework for specifying and analyzing statistical models. Phylogeneticgraphical models can be specified interactively in RevBayes, piece by piece, using a new succinct and intuitive language called Rev. Rev is similar to the R language and the BUGS model-specification language, and should be easy to learn for most users.
The strength of RevBayes is the simplicity with which one can design, specify, and implement new and complex models. Fortunately, this tremendous flexibility does not come at the cost of slower computation; as we demonstrate, RevBayes outperforms competing software for several standard analyses. Compared with other programs, RevBayes has fewer black-box elements. Users need to explicitly specify each part of the model and analysis. Although this explicitness may initially be unfamiliar, we are convinced that this transparency will improve understanding of phylogenetic models in our field. Moreover, it will motivate the search for improvements to existing methods by brazenly exposing the model choices that we make to critical scrutiny. RevBayes is freely available at http://www. RevBayes. com.
As an example of this model life cycle, consider the approach for averaging over substitution models proposed by  Huelsenbeck et al. (2004). This model was initially implemented in a computer program that was quite limited in its capabilities; the user could not consider alternative models of rate variation or priors on the branch lengths, etc. The substitution-model averaging approach only gained traction when it was implemented almost a decade later in the program MrBayes  (Ronquist et al. 2012b). Second, existing software, such as MrBayes  (Huelsenbeck and Ronquist 2001; Ronquist and Huelsenbeck 2003; Ronquist et al. 2012b) , can be difficult to extend as new models are described. Every computer program has a basic architecture that is developed around the set of models that had been described at the time the program was written.
These considerations motivated the development of our new software package, RevBayes, an opensource program written in the C++ language. RevBayes was initially conceived as a major rewrite of the popular Bayesian phylogenetic-inference program MrBayes  (Huelsenbeck and Ronquist 2001; Ronquist and Huelsenbeck 2003; Ronquist et al. 2012b ). However, RevBayes shares no code with MrBayes and uses an entirely new way of specifying phylogenetic models. Indeed, we devised a language for specifying phylogenetic models that is similar to the R language (R Core Team 2014). RevBayes is a stand-alone software package, but relies heavily on the Nexus Class Library for parsing data  (Lewis 2003). The resulting program had only superficial similarity to MrBayes, so we rechristened the program RevBayes (The new name also reconciles a criticism by Joe Felsenstein that Thomas Bayes was a reverend and would have been addressed as such.
) to distinguish it from its predecessor. Similar shortcomings have been identified by other researchers, which led to different solutions implemented in BEAST 2  (Bouckaert et al. 2014) , a re-implementation of the popular BEAST program  (Drummond and Rambaut 2007; Drummond et al. 2012). General similarities between RevBayes and BEAST 2 include a modular and flexible software design that enables model diversity, complexity, and extensibility. The main differences include the user interface (XML vs. Rev) and our strict adoption of the graphical-model framework. For example, BEAST 2 focuses on method developers by providing a plugin mechanism for adding new features written in Java, whereas RevBayes focuses on high-end users writing new models in Rev (similar to developments in R). Our development of RevBayes was guided by a few key principles: (i) the program should enable flexible-model specification and implementation; (ii) the program should be easy and intuitive to use, and; (iii) the program should provide fast computation and efficient inference.
THE Rev LANGUAGE FOR USER INTERACTION We have developed a new programming language, Rev, for interacting with RevBayes. Rev is suitable for both interactive use and batch processing. Through Rev, users define graphical-model components in a succinct and intuitive way. Rev is inspired by the R (R Core Team 2014) language and the BUGS  (Lunn et al. 2009 ) model-specification language; their popularity should reduce the Rev learning curve. However, Rev differs from these other languages because of the primary focus of RevBayes on Bayesian inference of phylogeny, for which R or BUGS are not compatible. That is, R and BUGS are designed for statistical inference and visualization of numerical data (e. g. , regression analysis and ANOVA). By contrast, the specialized parameter types used in phylogenetic inference-for example trees and nucleotide characters-need entirely different data structures and algorithms for parameter estimation.
These scripts should be easier to read and understand, and can easily be adapted to incorporate model variants. Moreover, Rev itself can easily be extended over time by adding new functions, distributions, data types, and inference algorithms. In the previous section, we introduced the three components of a graphical model; constant, stochastic, and deterministic variables. Figure  1  illustrates how these model variables are represented in Rev code. We will provide a more extensive treatment of the Rev language in a forthcoming paper; here we present examples for constructing models using Rev.
BENCHMARKS The success of a program like RevBayes depends on its ease of use, the diversity of models it implements, and also its efficiency. One might expect the efficiency of RevBayes to be hindered by the generality of its model-specification framework. To address this concern, we compared the efficiency of RevBayes to Notes: BEAST and MrBayes were run with and without the CPU implementation of the BEAGLE library for fast computation  (Ayres et al. 2012). Exactly one substitution model parameter was updated per iteration, ensuring recomputation of the entire tree likelihood. All analyses used the same fixed tree topology and branch lengths under one of four substitution models: HKY  (Hasegawa et al. 1985) , HKY+  (Yang 1994) , GTR  (Tavaré 1986) , or GTR+  (Yang 1994). Run times are given in seconds on a MacBookPro with a 3 GHz Intel Core i7 processor for 10 5 iterations on a molecular data set with 12 species and 898 sites.
the two most popular Bayesian phylogenetic software packages: BEAST  (Drummond and Rambaut 2007; Drummond et al. 2012; Bouckaert et al. 2014)  and MrBayes  (Huelsenbeck and Ronquist 2001; Ronquist and Huelsenbeck 2003; Ronquist et al. 2012b ). The efficiency of a Bayesian phylogeny inference program can be measured in three ways. First, we can evaluate how fast the software computes the likelihood under a given model. This speed is particularly important because computing the likelihood of a phylogenetic tree is time-consuming, and typically needs to be performed millions of times over the course of a MCMC simulation. Second, we can compare run times for a MCMC simulation, which emphasizes shortcuts taken in the MCMC algorithm to avoid unnecessary calculations. This is particularly critical when few parameters of a model change during an update in the MCMC run, where only a small part of the entire model likelihood needs to be recomputed.
Third, we can evaluate the MCMC algorithm itself according to how well and fast it explores parameter space. Here, we focus on the first two efficiency criteria, as the third aspect of efficiency is a property of the algorithm rather than the software. However, we note that RevBayes incorporates new MCMC algorithms-such as slice-sampling  (Besag and Green 1993)  and the guided-tree proposals described by  Höhna and Drummond (2012)  to efficiently explore tree space-and can easily incorporate new algorithmic developments. Note that RevBayes currently does not use any external library for fast likelihood computation, for example BEAGLE  (Ayres et al. 2012)  or PLL  (Flouri et al. 2015) , but these could be included in the future. The results demonstrate that RevBayes performs equally well or better than the basic implementations of MrBayes and BEAST in terms of the speed of likelihood computations (Table  1 ).
Only BEAST with BEAGLE outperformed our implementation in RevBayes. The likelihood implementation in MrBayes is actually faster than the implementation of MrBayes with BEAGLE, which is due to the overhead of function calls to the BEAGLE library and the comparably Notes: The GTR substitution model  (Tavaré 1986 ) was fixed but the tree was updated using either the Nearest Neighbor Interchange (NNI) or the Node-Slide move  (Lakner et al. 2008; Höhna et al. 2008; Yang 2014). Other test conditions were identical to those described in Table  1. modest speed improvement of BEAGLE for nucleotide substitution models. In terms of MCMC shortcuts, RevBayes outperformed all competing software (Table  2 ). These benchmarks show that the graphicalmodel framework-which is generic and thus cannot use shortcuts specifically designed for a particular modelcan compete in terms of computational efficiency with the most popular dedicated software used today.
Gene-Tree Species-Tree Models RevBayes allows simultaneous inference of gene trees and species trees. In this example, we use a birth-death process prior on the species tree and a multispecies-coalescent process with constant, homogeneous population size as the prior for each gene tree  (Rannala and Yang 2003 ; Figure  5 ). Each gene tree is, in turn, used as a parameter of the Phylo-CTMC for the corresponding sequence data and can have its own substitution process, as defined in the partitioned-data example above. Current variations of this model include branch-specific population sizes. The choice of a prior distribution on the population size is only restricted to positive real numbers but otherwise can be any distribution. Additionally, RevBayes allows you to create any relationship between the gene trees and partition-specific substitution models; for example, data partitions with distinct substitution models can share the same gene trees, or data partitions with distinct gene trees can share the same substitution model.
For example, morphological data can be partitioned, and rates of morphological evolution across branches can be FIGURE  5. A species-tree model depicted in graphical-model notation (left) and the corresponding specification in the Rev language (right). Here, we extend the simple model depicted in Figure  2  by allowing the topology to vary across N genes (identical model components are grayed out). Specifically, we invoke the multispecies-coalescent process  (Rannala and Yang 2003)  with constant population size, N e = where we assume each gene has an independent substitution process, Q i , and gene-tree topology, g i. Graphical-model notation follows the descriptions in Figures  1 2. FIGURE 6. A model depicted in graphical-model notation (left) and the corresponding specification in the Rev language (right).
There are several extensions to the Brownian-motion model that have been implemented in RevBayes, such as the Ornstein-Uhlenbeck processes  (Hansen 1997) , Lévy jump processes  (Landis et al. 2013b) , and the multivariate normal distributed traits  (Harvey and Pagel 1991; Lartillot and Poujol 2011)  model. Additionally, all FIGURE  7. A continuous-trait model depicted in graphical-model notation (left) and the corresponding specification in the Rev language (right). Here we use a fixed phylogeny, psi, which is read in from a file. The rate of Brownian motion, sigma, is drawn from an exponential distribution with rate parameter 10. The observed traits, T, are distributed according to a dnPhyloBrownianREML, which is a Brownian-motion process using the phylogenetic-independent contrasts method to integrate over the unobserved states at the internal nodes.
Graphical-model notation follows the descriptions in Figures  1 2. An alternative continuous-trait model depicted in graphical-model notation (left) and the corresponding specification in the Rev language (right). Again, phylogeny, psi, is assumed to be known and the rate of the Brownian motion, sigma, is drawn from an exponential distribution with rate parameter 10. The root state, T[2K -1], where K is the number of tips, is drawn from a uniform distribution between 0 and 10. The tree-plate notation explicitly specifies that traits evolve according to a normal distribution with mean T  [psi. parent(i) ] (the trait value of the parent branch) and variance scaled by the branch length, sigma 2 * psi. branchLength(i). Only the values of the tips are clamped. Graphical-model notation follows the descriptions in Figures  1 2.
Joint Inference of Combined Data In the examples above, we described how to design analyses for different types of data. These analyses can be performed independently or jointly, as has been advocated by  Nylander et al. (2004)  and  Ronquist et al. (2012a). Every analysis can be performed jointly if at least one variable in the model is shared. A shared variable will cause the resulting model graph to be connected, which is the only requirement in RevBayes. Note that we used the same variable for the tree (psi) for all the examples. Thus, we could jointly infer the phylogeny from molecular data, discrete morphological data, continuous-trait data, and biogeographic data. At the same time, we would accommodate uncertainty in the phylogeny when estimating parameters of the evolutionary process, such as the ancestral morphological states or species ranges.
VALIDATION The models used in the preceding examples have previously been described and tested in their original publications. Owing to its tremendous flexibility, it is FIGURE  9. A biogeographic model depicted in graphical-model notation (left) and the corresponding specification in the Rev language (right). Provided rates of dispersal (d) and extirpation (e), Q encodes the instantaneous-rate matrix used to compute transition probabilities for range evolution during anagenesis (along branches). P gives the transition probability of cladogenic events, where the probabilities of event types are given by the distribution, c. Graphical-model notation follows the descriptions in Figures  1 2. impossible to present a detailed validation of all possible models that can be specified in RevBayes.
Instead, we outline our efforts to validate our implementation. Our general strategy for validating our implementation of models in RevBayes entails several steps: (i) we directly compared the computed probabilities and/or function-return values in the C++ code (low-level comparison) to those of other established such as R, MrBayes, Phycas, and BEAST; (ii) we compared the computed probabilities and/or function-return values in small Rev examples (high-level comparison); (iii) we ran analyses on small data sets and compared the results to either MrBayes or BEAST, where applicable. Most importantly, we implemented an automatic procedure to validate our implementation as follows. A developer or user specifies any model in Rev as if performing an analysis. Next, RevBayes simulates parameter values and data utilizing the imbedded simulation routines.
LIMITATIONS Understandably, only a subset of all possible models are implemented in RevBayes. Nevertheless, the diversity of models implemented in RevBayes exceeds that of most other programs, such as MrBayes, owing to the immense flexibility for combining models using the Rev language. The addition of many other phylogenetic models will, of course, require extensions of the underlying C++ code. For example, it is currently not possible to specify models for genetransfer or gene-duplication-and-loss that are available in other more specialized software  (Arvestad et al. 2003; Szöllősi et al. 2012; Boussau et al. 2013). As the development of RevBayes continues, such models will become available to users. The fact that not all conceivable models are currenly available in RevBayes, however, should not detract from its primary design strength: the capacity of RevBayes to easily add and extend existing models.
ACKNOWLEDGMENTS The authors wish to thank the  National Evolutionary Synthesis Center (NESCent)  for sponsoring the  NESCent Academy Course  entitled "Phylogenetic analysis using RevBayes". The participants of this course provided extremely valuable feedback that significantly improved RevBayes and the  Rev language. Furthermore , the developers of RevBayes acknowledge generous contributions from:  Lars Arvestad ,  Daniel Ayres ,  Karen Cranston ,  Johan Dunfalk ,  Will Freyman ,  Laurent Guéguen ,  Mark Holder ,  Seraina Klopfstein ,  Bret Larget ,  Sibon Li ,  Ben Liebeskind ,  Mike May ,  Emily Jane Conor Meehan ,  Will Pett ,  Ben Redelings ,  Felix Reichert ,  Isabel Sanmartín ,  Donald Simon ,  Tanja Stadler ,  Marc Suchard ,  Gergely Szöllősi ,  Paul van der Mark ,  April Wright , and  Chi Zhang.