dataesr/scientific-paragraphs-categorization huggingface dataset:
g. which imager filter to use, how many exposures to do, how many groups should be in each integration, etc). When running MIRISim at the command line, at least one input file is required (simulation. ini), with the understanding that the scene. ini file is specified within the simulation. ini, that it exists, and can be used. Alternatively, a scene file can be specified at run time by simply adding the name of the scene file to the end of the above command. This would override any file named in the simulation input file. Within Python a scene and a simulation can be built up in a much more dynamic way, by importing the various MIRISim components, as described in more detail in the User Guide.
RESULTS The results of a MIRISim simulation are output as FITS files in the same uncalibrated data format which will be delivered In accordance with this, the science images are stored in the SCI header extension by default. MIRISim creates an output directory in the current working directory with a pathname that contains the date and time the simulation was started (e. g. yyyymmdd hhmmss mirisim). In that directory, copies are made of the scene. ini and simulation. ini files used to drive the simulation (or created if the simulation was manually built within python), and a number of subdirectories are created depending on the type of simulation performed. For all optical paths, directories are created for intermediate product illumination models (illum models) and final product detector images (det images).
CONCLUSIONS MIRISim is the simulator developed by the MIRI instrument team which reproduces the expected on-orbit performance of the instrument. It simulates each of the light paths through MIRI with the exception of coronagraphy. It is built in Python, and comes bundled in an Anaconda environment which incorporates all of its dependencies. It can be used both at the command line, or interactively in a Python shell. It draws on the calibration data products (CDPs) developed by the MIRI team as we characterise the instrument. The products of MIRISim are FITS files with valid metadata and header information that allow them to be ingested into the JWST pipeline as if they were true MIRI data. MIRISim is expected to be used for various purposes by a broad range of communities. For instance, it will be used by the instrument team during commissioning to correlate observations with expected performances and help refining our understanding of the instrument.
ACKNOWLEDGEMENTS The authors would like to thank the anonymous referee for their suggestions which have improved the clarity of this manuscript. The acknowledgements were compiled using the Astronomy Acknowledgement Generator. This research made use of Astropy, a community-developed core Python package for Astronomy (Astropy Collaboration et al. 2018, 2013) This publication makes use of data products from the  Wide-field Infrared Survey Explorer  (Wright et al. 2010), which is a joint project of the  University of California, Los Angeles , and the.
Besides, experimental validations are expensive and difficult as it is very challenging to control, isolate or measure many real-world factors influencing the results, e. g. canting, tracking, surface slope error, weather conditions and measurement errors. In this paper, a thorough comparison of the results obtained from simulations of heliostat field optics with six well-known optical modelling tools is presented, with the emphasis on checking the implementation and accuracy of sunshape and slope error simulations. The main features of the tests and the selective results are discussed in this paper. The detailed parameters and results are available in the supplementary material for readers interested in further verification. The data and models can also be accessed via the Github repository 1  maintained by the Australian National University (ANU) Solar Thermal Group (STG).
Tonatiuh Tonatiuh is a C++ multi-threading open source Monte Carlo ray tracer package for optical modelling of all types of solar concentrators both reflective and refractive, jointly developed by the National Renewable Energy Centre of Spain (CENER) and the University of Texas at Brownsville (UTB) with the support of the National Renewable Energy Laboratory (NREL)  (Blanco et al. , 2009). A preliminary comparison against SolTrace was conducted in 2009 via three simulation scenarios (a parabolic dish, a parabolic trough and a solar furnace system with pillbox sunshape). The maximum difference was under 3%  (Blanco et al. , 2009). It was also validated with another two experimental data sets. The first was using the data gathered at CIEMAT's Plataforma Solar de Almería (PSA), although it was difficult to draw definite conclusions about the accuracy of flux estimation due to the lack of sunshape's circumsolar ratio and surface reflectivity of the secondary concentrator  (Blanco et al.
, 2010). The second was validated at the Mini-Pegase CNRS-PROMES facility, and a high level of similarity between the measured flux distributions and those calculated by Tonatiuh was observed  (Blanco et al. , 2011). Having been under development since 2004, Tonatiuh has a vast number of features to facilitate the modelling of any kind of solar concentrators, such as wizards that make it possible to very easily define solar tower systems with thousands of heliostats. Its plugin-based architecture also makes it easy to expand the program to incorporate new types of surfaces, materials or solar radiation models. It also incorporates scripting capabilities that make it easy to automate the running the program to achieve a large variety of purposes.
Tracer Tracer is an open source package implemented in Python, and utilising efficient numerical routines from SciPy  (Jones, 2001)  and NumPy  (Oliphant, 2006) , with 3D rending provided by Coin3D 2  and Pivy 3  in Python as well. Originally created by Yosef Meller at Tel Aviv University (TAU) in Israel 4  , Tracer was further developed by the Solar Thermal Group (STG) at the Australian National University (ANU) 5  for modelling CSP systems. New additions include parallel processing capability for faster tracing, simulations of slope errors and sunshape distributions. A TowerScene module has been recently developed, which includes flexibility for different heliostat tracking mechanisms (azimuth-elevation, pitch-roll), different aiming strategies (single-point aiming or multiple fixed points aiming), heliostat slope error distributions (normal and pillbox) and field layout options etc.
Solstice The SOLSTICE (SOLar Simulation Tool In ConcEntrating optics) is a free open source software released under the GPLv3+ license and jointly developed by PROMES-CNRS 6  and Méso-Star 7. The integral formulation Monte Carlo (IFMC) algorithm  (Delatorre and Baud, 2014)  was implemented to solve the concentrated solar flux on a receiver, which was experimentally validated by  Caliot et al. (2015). The convergence rate is faster than the collision-based algorithm (e. g. as used in SolTrace and Tonatiuh) as Solstice applies energy-partitioning method. It is also efficient in large field simulations due to its sampling rays of the first intersection on the primary reflector surface. It uses the Embree library from Intel® and is fully parallelisable on shared-memory architecture. The program is intended to be executed as a command-line tool enabling the user to couple the ray tracing simulation with other programs such as in optimisation loops and fluid mechanics or thermal software.
Heliosim Heliosim is an integrated central receiver CSP simulation and optimisation software developed by the Commonwealth Scientific and Industrial Research Organisation (CSIRO), Australia. It is a closed commercial source package. The motivation for the initial development of the ray tracing model used by Heliosim in 2007 was for supporting experiments (e. g. receiver design and providing inputs for CSIRO's heliostat control system software) performed using the two central receiver CSP facilities at the CSIRO Energy Centre in Newcastle, Australia (e. g. Kim et al. , 2013). As part of the Australian Renewable Energy Agency (ARENA) sponsored "Optimisation of central receivers for advanced power cycles" project, receiver thermal modelling, pipe stress modelling, heliostat field optimisation, and a graphical user interface were added to the Heliosim software  (Potter et al.
, 2017). The core physical modelling is implemented as a C++ library that is exposed as a plugin for Workspace  (Watkins et al. , 2017) , a scientific workflow framework developed by CSIRO. The desired behaviour of the software is encapsulated as a Workspace workflow, which is compiled into a standalone application with a graphical user interface created using the Qt framework. For simulating heliostat optics, Heliosim currently (version 5. 4. 0) implements a MCRT method where rays are cast from the primary reflector surfaces (i. e. the heliostat mirror facets). The incident direction, mirror intercept location and mirror surface normal direction for each ray are calculated via Monte Carlo sampling of cumulative distribution functions (CDF) using the function inversion method. As described in §4.
SolTrace SolTrace is generalised Monte Carlo ray tracing open source software that can model a wide variety of optical systems, surface geometries, and surface interactions by casting sun rays randomly over a region of interest, rather than by generating rays which originate from points on the heliostat surface. As such, it is not designed for efficient operation with power tower systems, but provides functionality that SolarPILOT  (Wagner and Wendelin, 2018)  utilises for that application, managing automated geometry definition, heliostat tracking, sun positions, and definition of error and sunshape distributions. The features are presented in detail by  Wendelin and Dobos (2013). It was validated through comparison with measurements taken at the NREL High Flux Solar Furnace  (Wendelin and Dobos, 2013).
SolarPILOT SolarPILOT is an open source software that utilises analytical methods for optical modelling  (Wagner and Wendelin, 2018). Instead of ray tracing, it uses the Hermite polynomial expansion technique to approximate reflected sun images as Gaussian distributions. It is a similar technique as applied in DELSOL that has been demonstrated by  Walzel et al. (1977) ,  Dellin (1979), and Kistler (1986). SolarPILOT implemented a number of improvements, including dynamic heliostat grouping, efficient annual performance prediction, and field layout generations that were reviewed by  Wagner and Wendelin (2018). The analytical method is significantly more computationally efficient than ray tracing methods, but has limitations in precise modelling of all optical conditions, e. g. (  1 ) non-Gaussian distributions, (2) multiple reflections in cavity-type receivers.
Models and Results The verification is done thoroughly by three rounds of tests, with gradually increasing complexity, from single heliostat to full field simulations. Descriptions of each case and selective results are presented and discussed in the following sections. Details are available in the supplementary material for readers who are interested in using these tests to verify their code. Data files can be accessed via the ANU STG Github repository 1 , include case descriptions, parameter list of each case, the heliostat field coordinates, result data files, and Python scripts of applying Tracer for running each of the test and data post processing.
To address this issue, polynomial calibration correlations are applied in both codes respectively to make CSR = χ. The source code can be referred to as the demonstration in the Tracer repository 9. The polynomial calibration equation from Tonatiuh was implemented in Solstice, and recently added in SolTrace and SolarPILOT, and that from Tracer has since been implemented in Heliosim. The slight differences shown in the energy bar chart (Figure  8 (a)) are caused by this issue. The developers are collaborating and preparing another thorough study to reveal this issue.
SolTrace SolTrace predates Tonatiuh and is widely used for CSP simulations by researchers. Several changes and bug fixes were identified and implemented as a result of this study. Firstly, it was determined that the Buie sunshape equation was not accurately predicting power in the circumsolar region in most cases. The Buie sunshape correction equation that is used in Tonatiuh was adopted in generating the results for this paper. Secondly, it was observed that SolTrace consistently slightly underestimated the variance in normal distribution population samples. In effect, this led to increased peak flux density near the centre of the image and decrease predicted spillage losses near the periphery of the image on the order of 1-2%. The cause of this error was found to be an approximation in the original Gaussian distribution model, which is shown in the pseudocode in Fig.
Including small values of non-zero intensity above this angle resulted in the excessive weighting of the circumsolar region by the Hermite polynomial fitting algorithm, so this empirical conclusion has improved the ability of SolarPILOT to model Buie sunshapes in most real-world cases, though the issues with zero-error heliostats remain. Thirdly, several improvements were made to the SolarPILOT interface, to the scripting language, and to the parametric simulation capabilities as a result of bugs and lacking features were noted during the exercise.
Tracer Tracer, as an open source optical modelling tool in CSP, also benefited from this study. Tracer implementations of slope errors and sunshapes were validated by comparison with the state-of-art research tools. The highly readable Python language of Tracer provides a manageable platform for implementations of new algorithms for testing. While Tracer is accurate, its longer computational times and limitations in dealing with large heliostat fields were also noted. Efforts are being made to improve this ability.
Following the implementation of the Monte-Carlo ray casting model, slight discrepancies remained for the round B cases. This was found to be due to Heliosim automatically applying physically realistic geometric offsets between the heliostat actuation axes and the mirror surface, whereas the test case assumed that the origin points of the actuation axes and mirror surface coincide. An option was therefore added to the Heliosim software that allowed the offset distances to be specified by the user as some fraction of the heliostat characteristic length (i. e. mirror surface diagonal). Despite good agreement then being found between Heliosim and Tonatiuh for rounds A and B, slight disagreement remained for round C. A critical difference between round B and C is the inclusion of shading and blocking effects, and therefore the possibility of error due to the treatment of shading and blocking in Heliosim was investigated.
Previously Heliosim implemented approximations when simulating shading and blocking, where ideal sunshape (i. e. collimated) and perfect mirror (i. e. no slope error) models were assumed and the energy of each reflected ray was reduced by a heliostat-averaged shading and blocking factor. To check if these approximations were the source of error for round C, an option was added to the software to allow shading and blocking to be simulated without these approximations (i. e. sunshape and slope error models are considered, and each reflected ray has its own binary shading and blocking factors). The maximum error in overall efficiency due to the shading and blocking approximations was found to be less than 0. 2% for round C, and the flux map discrepancies with Tonatiuh were not resolved. This discrepancy is to be investigated as future work by the Heliosim developers.
Acknowledgements This work is a collaboration between the  Australian National University (ANU) ,  CSIRO ,  NREL ,  PROMES-CNRS, Méso-Star Company  and the  Cyprus Institute. The authors gratefully acknowledge the support of (1) the  European Union 's  Horizon 2020 research and innovation programme  within the context of the  Cyprus Institute's CySTEM ERA Chair project , under grant agreement No. 667942 , (2) the  French ''Investments for the future" program  managed by the  National Agency for Research (ANR)  No. ANR-10-LABX-22-01-SOLSTICE  and (3) the  Australian Renewable Energy Agency ,  2014/RND010.
3. kMC model (Figure  1 ). Initially, a cubic box containing randomly distributed spherical carbon particles representing the porous carbon mesostructure was created using a commercial software called Geodict. The sensitivity to the variation in the random distribution of spherical carbon particles is discussed in the subsection S4. 1 of the supporting information. The side length of this cubic box and the diameter of the carbon particles were set to 50 and 25 nm respectively. The porosity of the entire mesostructure was set to 67%.
Creation of initial C/S mesostructure The cubic box was then meshed along each side into 100 cubic volumetric elements called voxels. The side length of each voxel was set to 5 Å which is close to the S-S bond length (4. 1 Å) in an isothermally stabilized graphene/S microstructure  [24] , and therefore it was set as the resolution between S atoms. The resulting structure was exported as a stack of images create the simulation box with voxels containing carbon atoms. Locations of the carbon atoms in the simulation box were exported to a trajectory file (*. xyz) along with those of the solid sulfur ( ( ) ) particles (Figure  1 ). The visualizations in this work were done using the open source software Ovito  [29]. The locations of each carbon ( ) and sulfur ( ) atoms in ( ) were identified using the integer numbers 1 and 2.
The ( ) particles were randomly distributed next to the atoms at the carbon particle surface since the impregnated ( ) sticks to the surface of the carbon particles  [6]. Furthermore, the mass ratio between and atoms was set to 1:0. 27. We have used this low sulfur loading in our simulations to reduce the computational cost. Finally, the resulting trajectory file is read by our in-house developed kMC python code, which reconstructs the simulation box and utilizes it as the initial C/S mesostructure. It should be noted that our in-silico C/S mesostructure creation method and kMC code are not specific to the aforementioned dimensions, structural and geometric parameters. In fact, we can customize the initial C/S mesostructure by changing the parameters such as of the shape M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT 6 and size of the carbon particles, mesostructure porosity, sulfur loading, etc.
To identify nucleic variants from metagenomic data, an alternative to the alignment-based approach has been recently proposed through reference-free variant calling based on the DiscoSNP++ tool  (Uricaru et al. , 2015). This software detects the variants by identifying bubbles in a de Bruijn graph built directly from the raw metagenomic reads. Then, the variants can be relocated on genomes of interest if available. Comparing to alignment-based variant calling applied on metagenomic data, DiscoSNP++ was presented as less sensitive but more specific in term of recall, and more accurate in term of allele frequency, especially in noncoding regions  (Arif et al. , 2018). As population genomic analysis is very sensitive to the accuracy of the allele frequencies, we can consider that the use of DiscoSNP++ could be preferable to alignment-based approach for population genomics based on metagenomic data.
In this study, we introduce the notion of metavariants, i. e variants detected directly from raw metagenomic reads without reference genome. We propose an effective method to cluster the metavariants by species and propose these clusters as a new species representation named metavariant species or MVS. We establish a formal definition of the metavariant and MVS. The relevance of the MVSs was tested on simulated and real metagenomic data. The clustering method we developed to build the MVSs was implemented in a R package called metaVaR and compared to state-of-the-art clustering algorithms.
Implementation of the mDBSCAN-WMIN algorithm in metaVaR The metavariants preprocessing step is performed by running metaVarFilter. pl, that produces the depth of coverage and frequency matrices from a reference-free vcf file. The MetaVaR package was written in R and provides three main functions for MVS construction: 1. tryParam creates metavariant clusters using several e, p values. We used the R package fitdistrplus to obtain the log-likelihood of the coverage distribution. 2. getMWIS identify the maximum weighted independent sets. 3. mvc2mvs applies filters described in (5) to select the MVS and performs population genomic analysis. metaVaR is available at https://github. com/madoui/metaVaR.
Metavariants set from simulated metagenomic data We downloaded six bacterial genomes from NCBI (Escherichia coli NC_000913. 3, Pseudomonas aeruginosa NC_002516. 2, Yersinia pestis NC_003143. 1, Rhizobium tropici NC_020059. 1, Rhizobium phaseoli NZ_CP013532. 1, Rhodobacter capsulatus NC_014034. 1). For each genome we created a derived genome that contains 1% of randomly distributed SNPs for E. coli and 2% for the others bacteria. We used meta-Sim  (Richter et al. , 2008)  to simulate Illumina paired-end 100 bp reads from 300bp genomic fragments on seven populations that contained various abundance (Figure  2. A) and various proportion of original and derived genomes (Figure  2. B). To generate the metavariants, DiscoSNP++ was ran on the total read set with parameter -b 1. As a control, the metavariants were relocated on the six original genomes using the -G option.
C). Then, the clusters are scored statistically based on the expected depth of coverage of the loci in each sample (Figure  1. D). The best clusters are selected by a maximum weighted independent set (WMIN) algorithm (Figure  1. E) and variable loci with a certain minimal coverage are selected to obtain the final MVSs (Figure  1. F). The method was implemented in a R package called metaVaR that allows users to build and manipulate MVSs for population genomic analyses (Figure  1. G).
Metavariant species on simulated metagenomic data To test the relevance of MVSs for population genomic analyses, we simulated seven metagenomic data set composed of illumina short reads from an admixture of six bacteria in various abundances (Figure  2. A). Each bacterial species was composed of two strains in various abundance (Figure  2. B). Metavariants were detected by DiscoSNP++ and filtered resulting in 90,593 metavariants from which the depths of coverage of the variable loci and metavariants frequency matrices were computed. The metavariants were clustered into MVS candidates using the mDBSCAN-WMIN algorithm and the clustering performances were compared to three state-of-the-art algorithms  (Rau and Maugis-Rabusseau, 2018 ): (i) centered log-ratio and kmeans (CLR-kmeans), (ii) arcsin transform + Gaussian mixture model (arcsin-GMM), (iii) logit transform + Gaussian mixture model (logit-GMM).
However, the MVS modelling requires a minimal amount of genomic information that includes the variable loci of single copy region and their variant frequencies in the different samples. The information is sufficient to perform basic population genomic analysis like genomic differentiation and detection of loci under natural selection. The extraction of this information from raw metagenomic data through the use of DiscoSNP++ does not need reference or assembly and generates accurate variant frequencies in a reasonable time and computational resources even for very large dataset  (Arif et al. , 2018). To provide an ecological insight out of the MVSs, we recommend to perform a taxonomical assignation of the MVSs. This is feasible using the variable loci sequences generated by DiscoSNP++ and to align them to public sequence databases.