dataesr/scientific-paragraphs-categorization huggingface dataset:
CAMELS Multifield Dataset The CAMELS Multifield Dataset, CMD, is a collection of hundreds of thousands of 2D maps and 3D grids generated from CAMELS data. CMD contains 15,000 2D maps for 13 different fields at z = 0, and 15,000 3D grids, at three different spatial resolutions and at five different redshifts. The data was generated by assigning particles positions and properties (e. g. mass and temperature for the temperature field) to either 2D maps or 3D grids. There are many possible machine learning applications of this dataset, e. g. : 1) parameter inference  (Villaescusa-Navarro et al. 2021a,b) , 2) summary or field level emulation, 3) mapping N-body to hydrodynamic simulations, 4) superresolution, and 5) time evolution. In total, CDM represents over 70 Terabytes of data. We refer the reader to  Villaescusa-Navarro et al.
Second, CAMELS-SAM stored 100 snapshots while CAMELS only kept 34. Third, galaxies are modelled in very different ways: in CAMELS they arise from the hydrodynamic simulations while in CAMELS-SAM they are modelled through the Santa Cruz semi-analytic model. For all CAMELS-SAM simulations, we release: • The halo and subhalo catalogues from both Subfind and Rockstar. • The merger trees generated from Consistent trees. • The galaxy catalogues from the Santa Cruz SAM. The galaxy catalogues are stored as. dat text files with comma-separated values. These files contain information about the halo and galaxies from all snapshots of a given simulation. The exact available properties, their organization and units, and example code to open these files can be found on the CAMELS-SAM online documentation 9.
Within each of those folders there are numerous folders, containing the data from the different simulations belonging to each suite; i. e. the simulations from the four sets: LH, 1P, CV, and EX. Finally, inside each of those folders the user can find the data products themselves. In this particular case, the power spectra for the different component. provide the url link in the online documentation where it will be always updated. • FlatHUB. FlatHUB is a platform that allows users to explore and compare data from different simulations by browsing and filtering the data, making simple preview plots, and downloading sub-samples of the data. We provide access to the Subfind halo and subhalo catalogues of the IllustrisTNG and SIMBA suites through this platform. We provide a link to FlatHUB in the online documentation.
Data Structure The data is organized in different folders that contain similar type of data: • Sims. This folder contains the raw data from the simulations, such as initial conditions, snapshots, and parameter files. This folder contains 205 terabytes of data. • FOF Subfind. This folder contains the SUB-FIND halo and subhalo catalogues described in Sec. 3. 2. 1. This folder contains 4 terabytes of data. • AHF. This folder contains the AHF halo catalogues described in Sec. 3. 2. 2. This folder contains 6 terabytes of data. • Rockstar. This folder contains the Rockstar halo and subhalo catalogues together with the merger trees from Consistent-trees as described in Sec. 3. 2. 3. This folder contains 1 terabyte of data. • Pk. This folder contains the power spectra described in Sec. 3. 5. 1. This folder contains approximately 10 gigabytes of data.
• Bk. This folder contains the bispectra measurements described in Sec. 3. 5. 2. This folder contains approximately 2. 6 gigabytes of data. • CMD. This folder contains the CAMELS Multifield Dataset. This folder contains 76 terabytes of data. • VIDE Voids. This folder contains the void catalogues described in Sec. 3. 3. This folder contains 200 megabytes of data. • Lya. This folder contains the Lyman-α spectra described in Sec. 3. 4. This folder contains 14 terabytes of data. • PDF. This folder contains the probability distribution function measurements described in Sec. 3. 5. 3. This folder contains more than 1 gigabyte of data. • Profiles. This folder contains the sphericallyaveraged 3D profiles described in Sec. 3. 6. This folder contains 48 gigabytes of data. • X-rays. This folder contains the X-rays photon lists described in Sec.
3. 7. This folder contains over 100 gigabytes of data. • SCSAM. This folder contains all CAMELS-SAM data products described in Sec. 3. 9. This folder contains more than 50 terabytes. • Utils. This folder contains additional files that can be useful to the user, including a file with the value of the scale factors corresponding to simulation snapshots and files indicating the values of the cosmological and astrophysical parameters of each simulation. When possible, we have organized the data in the different folders in a self-similar way. We show the generic data structure scheme in Fig. 3. The data is first organized into folders that contain: 1) the IllustrisTNG hydrodynamic simulations, 2) the SIMBA hydrodynamic simulations, 3) the N-body counterparts of 1), and 4) the N-body counterparts of 2).
Inside each of these folders the user can find many different sub-folders whose name refers to the specific simulation set and realization: e. g. the first simulation of the LH set is denoted as LH 0. Finally, inside each of those folders the user can find the data with the particular characteristics of each data product. We note that these folders may contain data products for a particular CAMELS simulation at all redshifts. For some data products, e. g. CMD and CAMELS-SAM, the data organization is slightly different to the one outlined above. In those cases, we provide further details in the online documentation.
SUMMARY The goal of the CAMELS project is to connect cosmology with astrophysics via thousands of state-of-the-art cosmological hydrodynamic simulations and extract the maximum amount of information from them via machine learning. CAMELS contains 4,233 cosmological simulations, 2,049 N-body simulations and 2,184 stateof-the-art hydrodynamic simulations sampling a vast volume in parameter space using two independent codes that solve hydrodynamic equations and implement subgrid physics in very distinct ways. CAMELS data have already been used for a large variety of tasks, from providing the first constraints on the mass of the Milky Way and Andromeda galaxies using artificial intelligence to showing that neural networks can extract information from vastly different physical fields while marginalizing over astrophysical effects at the field level.
In this paper we have described the characteristics of the CAMELS simulations and a variety of additional data generated from them, including halo, subhalo, galaxy, and void catalogues, power spectra, bispectra, Lyman-α spectra, probability distribution functions, radial profiles, and X-rays photon lists. We have also described CAMELS-SAM, a collection of more than 1,000 galaxy catalogues created by applying the Santa Cruz Semi-Analytic Model to a set of hundreds of Nbody simulations. We have made all this data publicly available, comprising hundreds of terabytes. We provide access to the data through different platforms, including a Binder environment for interactive data manipulation with Jupyter notebooks, a Globus link for efficient transfer of large amounts of data, and the FlatHUB platform for quick exploration of Subfind (sub)halo catalogues.
We emphasize that the information outlined in this paper may become outdated as additional data products become available over time. However, the online documentation located at https://camels. readthedocs. io will always be updated accordingly. It is also important to be aware of the limitations associated to the CAMELS simulations. First, the volume sampled by each individual simulation is relatively small, (25 h -1 Mpc) 3 , inhibiting the formation of the most extreme objects in the Universe such as galaxy clusters and large voids. Second, while CAMELS covers a large volume in parameter space, it would be desirable to make it even larger by including other cosmological and astrophysical parameters. Third, CAMELS only contains two distinct suites of hydrodynamic simulations: IllustrisTNG and SIMBA.
ACKNOWLEDGEMENTS We are indebted to the high-performance computing system administrators at the  Flatiron Institute and Princeton University  for their invaluable help and work accommodating the CAMELS storage needs. The authors are pleased to acknowledge that the work reported in this paper was partially performed using the Research Computing resources at Princeton University which is a consortium of groups led by the  Princeton Institute for Computational Science and Engineering (PICSciE)  and the  Office of Information Technology's Research Computing Division. Further technical details on the CAMELS simulations and instructions to download the data can be found in https://camels. readthedocs. ioand https://www. camel-simulations. org. The work of FVN, SG, DAA, SH, OP, AP, KW, WC, ME, US, DS, BB, BW, RS, and GB was supported by the  Simons Foundation.
They have introduced guidelines for authors around the years 2000s. According to Frow (2012), three general factors are correlated with this "crisis of trust" in scientific images, especially in the biosciences: the increasing availability of (more-or less-validated) image-processing software (e. g. Photoshop), the increasing reports of misconducts related to image manipulation, and the switch by most journal publishers to electronic workflows. This moment of crisis is thus situated in time: the 2000s. Beyond this narrative of affairs and crisis about images manipulations, we argue that profound transformations of gel electrophoresis as a family of techniques have been occurring in a larger timespan and these transformations do have implications on the way images have been produced, and on the way they are received.
Image capture technologies had shown great progress thanks to CCD cameras  (Miura, 2001). Software has been redesigned as an affordable and user-friendlier image analysis system for personal computers. Thus, modern gel docs have been incorporating powerful and cost-effective hardware, new generation software, and high-performance devices for image acquisition. New features in second-generation gel analysis software packages have made accurate comparison of two-dimensional gel images possible  (Olson & Miller, 1988). In the late 1990s, a new twodimensional approach called DIGE was introduced by  Ünlü et al. (1997)  by combining superimposing of gel images  (Horgan et al. , 1992)  with detection of (newly patented) cyanine based fluorescent protein labels. One of the main purposes for development of DIGE was to overcome the poor repeatability of 2D PAGE, namely the inherent technical and systematic variability that affect the generated patterns and spots intensities on gels.
In contrast to more "qualitative" gel electrophoresis users, 2D PAGE and DIGE experts were aiming for increasing standardization, through more and more sensitive dyes, high-resolution CCD chips, controlled image acquisition, powerful data analysis and extensive file storage. The third-generation of two-dimensional gel image analysis software is therefore characterized by the introduction of algorithms derived from the development of artificial intelligence and machine learning  (Appel et al. , 1997). At this stage, image production was incorporated within gel electrophoresis data processing. Preparation of an internal standard and gel imaging (namely, image production, analysis, modification and comparison) were included within the DIGE protocol  (Beckett, 2012). In this case, the end-product is neither a dried gel nor a digital image of a gel: it actually is a set of various densitometric pieces of data, in a shareable format, generally communicated through histograms, exemplifying averages and standard deviations.
Yet, the main distinction between these two tiers consists in the system used in order to perform imaging and the subsequent status of gel electrophoresis images. Regarding instrumentation, 1D PAGE commonly involves a digital camera or a document scanner system for office use whereas DIGE requires a gel doc apparatus. Regarding images, the outcome of 1D PAGE experiments remains a representation of a gel. Unlike DIGE, imaging is not incorporated within the instrumental device. Imaging often involves non-specialized optical devices coupled with more or less specialized image processing software, such as the opensource ImageJ, designed by scientists, or the mainstream, proprietary, and multi-purpose Photoshop. A kind of "expert tinkering" is then the main way to perform "qualitative" gel electrophoresis, resulting in digital images that are handcrafted on the fly.
According to them, publication guidelines regarding image production turned from leniency to stringency 10. Gel drying or photography pinning in a lab-book were once the storage of choice for eventual "virtual witness" use. Once digital image storage had taken over, image digitization has become the pivotal issue in both tiers. A digital image of a gel may come from a variety of processes. It might be a digital image produced by a gel doc comprising image production and processing thanks to a dedicated patented piece of software. Or, it might be shot by a high end CCD camera, or a plain digital camera, and then processed by a piece of scientific software, or processed by Photoshop, including preliminary gel drying or not. The two tiers we have defined as ideal types simplify an array of diverse practices.
Beautification, as for example in the removal of ugly stains that hamper the visualization of what is at stake, is thus part of these practices, that remain largely tacit. These "analog" practices are actually the ones mentioned by Frow as the ones that pose no problem to journal editors while their digital counterparts are frowned upon. Digitization of such practices thus entails distrust in the sense that beautification practices that were once routine but invisible are now exposed as suspicious. Actually, technical expertise in the second tier suffers from a bad perception of lay tools. Photoshop, in particular, is very easily demonized. For this routine kind of electrophoresis, standardization and accountability are more difficult to achieve because of the high diversity of lab (bench) and software (desktop) practices.
In contrast with the first tier, there has never been formal training on image analysis for young researchers and students performing second tier gel electrophoresis. Also, the tools of numerical post-production in gel electrophoresis are very far from a trusted scientific device; instead, it is quite the opposite: Photoshop is not scientific software, its user-base activity is typically about altering (or "beautifying") images. It has a very bad reputation in terms of data integrity (photoshopping as a verb is hardly perceived as a legit activity). Its very user interface is even appropriate to bricolage: its menus are full of tinkering analogies like cropping, pincels, scissoring, blurring. These are the typical vocabulary of retouching  (Manovich, 2011). This is also remarkable that the same vocabulary is used in the analog practices of gel alterations we described just above.
Finally, its friendly user interface makes Photoshop easy to use to nonexperts. This undervalued expertise in this kind of post-production inspires general distrust, as opposed to the situation in tier 2 before digitization. It is of course also opposed to specifically designed scientific software used by well trained, computational savvy scientists in the first tier. As  Porter (1995)  has devised, this kind of distrust arises when there is no uniform acceptance of what technical skills and training are needed. In other words, scientists did not manage to reach consensus on a definition of numerical image post-production sound practices and literacy, in contrast to the collective disciplining within the first tier. Thus, reproducibility doesn't have the same status in the two tiers. Unlike collective practices negotiated at the bench described by Amann and Knorr Cetina, beautification in the Photoshop era (mostly solitary, not formally trained, and using lay tools) does not benefit from the same relationship to perception of careful practices.
The Solar MAgnetic Connection HAUS 1 tool (Solar-MACH) is an opensource tool completely written in Python that derives and visualizes the spatial configuration and solar magnetic connection of different observers (i. e. , spacecraft or planets) in the heliosphere at different times. For doing this, the magnetic connection in the interplanetary space is obtained by the classic Parker Heliospheric Magnetic Field (HMF). In close vicinity of the Sun, a Potential Field Source Surface (PFSS) model can be applied to connect the HMF to the solar photosphere. Solar-MACH is especially aimed at providing publication-ready figures for the analyses of Solar Energetic Particle events (SEPs) or solar transients such as Coronal Mass Ejections (CMEs). It is provided as an installable Python package (listed on PyPI and condaforge), but also as a web tool at solar-mach.
github. io that completely runs in any web browser and requires neither Python knowledge nor installation. The development of Solar-MACH is open to everyone and takes place on GitHub, where the source code is publicly available under the BSD 3-Clause License. Established Python libraries like sunpy and pfsspy are utilized to obtain functionalities when possible. In this article, the Python code of Solar-MACH is explained, and its functionality is demonstrated using real science examples. In addition, we introduce the overarching SERPENTINE project, the umbrella under which the recent development took place.
Furthermore, the tools may also be useful for the broader heliospheric community looking at different aspects of solar activity or solar wind phenomena. Part of this platform will be a JupyterHub server that provides free access to the tools developed by the SERPENTINE project as Jupyter Notebooks, without requiring any installations beyond a web browser. This manuscript and the accompanying papers  (Kouloumvakos et al. , 2022; Palmroos et al. , 2022; Trotta et al. , 2022)  will present the first batch of these tools to the heliophysics community. Because SEPs are measured in situ as enhancements of the energetic particle fluxes, the presence of multiple, wellseparated observers is indispensable to study widespread SEP events (e. g. ,  Dresing et al. , 2014; Richardson et al. , 2014). The new space missions in combination with established spacecraft form a fleet that is ideal for this purpose, as it covers varying heliocentric distances and large longitudinal ranges around the Sun.
Method The main functionality of Solar-MACH is to provide the user with a polar plot showing a Sun-centered top view of the heliographic equatorial plane with the constellation of different observers for a given time, as shown in Figure  1. Additional information can be added, such as indicating the magnetic connection of each observer to the Sun as given by an idealized classic Parker heliospheric magnetic field line, whose curvature is dependent on the radial solar wind speed. This and other options are described in Section 2. 1. All software operations are performed within Python 3 (e. g. ,  Van Rossum and Drake, 2009) ; the corresponding package solarmach is described in Section 2. 2. In addition, a web tool is provided that requires neither Python knowledge nor installation. This web tool and its technical background are presented in Section 2.
Ephemeris After the user provides a specific date and time, the spatial coordinates of all requested observers are obtained dynamically from JPL Horizons, an online Solar System data and ephemeris computation service that is maintained by the Solar System Dynamics Group of the Jet Propulsion Laboratory (JPL). In addition to the web interface, JPL Horizons provides an API for programmatic control. This API is utilized through version 4. 0. 5  (Mumford et al. , 2022)  of the sunpy opensource software package  (The SunPy Community et al. , 2020) , which itself uses Astropy's  (Astropy Collaboration et al. , 2013; Astropy Collaboration et al. , 2018; Astropy Collaboration et al. , 2022)  affiliated package astroquery  (Ginsburg et al. , 2021)  for this functionality. The ephemeris information is returned per observer within Python as a SkyCoord object, which inherently provides coordinate system transformations.
Python package solarmach The Solar-MACH Python code is made available as an installable Python package called solarmach  (Gieseler et al. , 2022b)  that is listed on PyPI and conda-forge, i. e. , it can be installed using either the pip or the conda command line tool, which are by far the most widely used means of installing Python packages. Installing the package in this way ensures that all other required packages are also installed. An example of the standard workflow for the package is shown in a Jupyter Notebook in.
Further backmapping with PFSS The magnetic field configuration close to the Sun in the corona differs drastically from the heliospheric magnetic field (HMF) and cannot be described using the simple Parker spiral approach given by Eq. 1. In order to further extend the magnetic connectivity from an observer towards the solar surface, a Potential Field Source Surface (PFSS) model (e. g. ,  Mackay and Yeates, 2012 , and references therein) is applied by using version 1. 1. 2  (Stansby et al. , 2022)  of the pfsspy open-source software package  (Stansby et al. , 2020). The main purpose is to calculate a set of open magnetic field lines in a defined circular area around the point where an idealized HMF line connects an interplanetary observer to the source surface, at which the field lines are forced by the PFSS model to be radial.
Streamlit web tool While all the functionality of Solar-MACH depends fully on Python, a web tool is provided online at solar-mach. github. io that completely runs in the web browser, features a fully graphical user interface (GUI), and requires neither Python knowledge nor installation. It is implemented using the open-source Python package streamlit. This package provides an easy way to set up a GUI to Python functions that is made available through a web server. It is possible to run it locally on a computer (if Python and all other requirements are installed), offering a full GUI to the user instead of running the code in a Jupyter Notebook or terminal. But the main purpose is to deploy the Streamlit application to a web hosting service, because only then it provides all the underlying Python functionalities without the need to install any kind of (Python) software.
This API is not documented yet, but should be self-explanatory using a given example. For further use of the Solar-MACH results, the user can save the plot by clicking with the right mouse button on it and using the web browser functionality, exactly like in the Jupyter Notebook version mentioned in Section 2. 2 and Section 2. 3. In addition, the web tool provides a download button for the plot that might be helpful, especially when using mobile devices like smartphones or tablets. The web tool also automatically displays a table with all ephemeris, magnetic footpoint, and separation information, which can be downloaded as a comma-separated values (CSV) file. The Streamlit application itself consists of a rather small code base that is open source  (Gieseler et al. , 2022a). It collects all necessary parameters from the user through the GUI, hands them over to the solarmach package described in Section 2.