dataesr/scientific-paragraphs-categorization huggingface dataset:
Introduction Currently, two internationally accepted nuclear data storage formats are in use. The traditional and most widely used is the ENDF-6 format  [1]. All major data libraries are distributed in this format, and its use is ubiquitous in nuclear engineering, nuclear physics, and reactor physics communities  [2] [3] [4]. The ENDF-6 format does not store nuclear data in a representation which is conducive to use in a continuous-energy Monte Carlo transport code. Secondary energy and angle distributions are often stored in representations which cannot be easily sampled to obtain the outgoing energy and scattering angle after a collision. Important data such as the Cumulative Distribution Function (CDF) are not provided, and the provided tabulations for a Probability Density Function (PDF) may not be linearly interpolable.
The cross sections for reactions in the ENDF files distributed with major data libraries are generally kept as resonance parameters, and not as a linearly interpolable set of points  [1]. Due to these reasons, ENDF-6 formatted files are generally not read directly for nuclear data in Monte Carlo transport codes. A new format for nuclear data files has recently been developed, called the Generalised Nuclear Data Structure (GNDS)  [5]. The GNDS format makes many improvements on the ENDF-6 format, such as allowing the storage of energy and angle distributions in a format which is more compatible with continuous-energy Monte Carlo codes (although this is not required by the standard). Some nuclear data libraries are now also distributed in the GNDS format (such as ENDF/B-VIII. 0 and TENDL-2021)  [3, 6] , but these distributions are generally translations of the ENDF-6 formatted files, and therefore do not contain data which is Monte Carlo ready.
As GNDS is so young, there is currently very little support for the format in most software. While the FUDGE nuclear data processing code does have support for GNDS  [7, 8] , other major codes such as NJOY and FRENDY do not yet support the format  [9, 10]. Because not all necessary data for continuous-energy Monte Carlo transport codes is provided in ENDF-6 files (and in practice, is not available in the current GDNS files either), most Monte Carlo codes use an alternative format which contains cross sections that are linearly interpolable and represent PDFs and CDFs in a format that lends itself well to Monte Carlo sampling (typically piecewise linear functions). The Monte Carlo code MCNP developed its own file format for this purpose, which is referred to as ACE (ACE being an acronym for A Compact ENDF)  [11].
Such a code-to-code comparison can be simplified if both codes are using the same nuclear data files, as any statistically significant differences in results would therefore be due to different approximations made in the physics at hand. As the use of the ACE format has expanded, it has become a "de facto" standard in the community, and a publicly accessible document has now been produced outlining the format  [17]. Currently, two open-source nuclear data processing codes are available to produce ACE files from ENDF-6 evaluations. NJOY is the more traditional choice and can produce ACE files for incident neutrons, photons, thermal scattering laws, and several different charged particles  [9, 18]  1. A newer option is the FRENDY processing code, which can produce ACE files for incident neutrons and thermal scattering laws  [10].
This paper presents version 0. 3. 1 of the Papillon Nuclear Data Library (PapillonNDL)  [19]. PapillonNDL is a free and open-source library which allows users to read and sample ACE files for incident neutron data, and thermal scattering laws. Being written in C++, PapillonNDL can be used to write high-performance computing applications. Additionally, a Python API is provided, which grants users access to all of the same functionality as in the C++ API. Continuous-energy nuclear data is invaluable in the field of nuclear engineering and is used for nuclear reactor calculations, radiation protection, and nuclear medicine. Due to their importance, many aspects of nuclear data are discussed and taught in nuclear engineering programs, at the undergraduate and graduate levels. Most of these discussions are focused on continuous-energy cross-sections, but may also include secondary energy and angle distributions as well.
Most classroom usage of nuclear data (if any) is generally quite minimal and surface-level. A large reason for this is limited access to continuous-energy data. The Python interface of PapillonNDL gives students a way to read ACE files in an easy and accessible programming language, so that they can easily examine, plot, and use continuous-energy neutron data. Three alternatives exist to reading ACE files in Python: PyNE  [20] , OpenMC  [21] , and ACEtk  [22]. While it is possible to make plots of cross-sections and scattering distributions with these three implementations, none of them supports the sampling of secondary energy or angle distributions. It is therefore impractical to use these libraries when a user needs to sample scattering energies and angles, as the user would need to implement all of the sampling algorithms themselves.
Outside of the Python language, JANIS is a popular tool for plotting different pieces of nuclear data (written in Java), but it is not designed to be used as a library in other applications, cannot read ACE files, and cannot sample scattering dis-1 NJOY is the only official processing code for producing ACE files to be used with MCNP. tributions  [23]. While it is also possible to plot data in ACE files using NJOY, users have very little control over the final appearance of such plots  [9]. PapillonNDL provides a simple interface to users, making it easy to sample scattering distributions (even elastic scattering) and plot nuclear data. To the best of the author's knowledge, it is the only such stand-alone library which exists, for both C++ and Python. Most graduate students who study computational methods in nuclear engineering will be required at one point in time to write a small toy Monte Carlo code.
Typically, these exercises are left to simple one-group problems (or at most, a few groups), with isotropic scattering. Being able to easily sample scattering distributions with Papil-lonNDL using the Python API, students can easily write toy Monte Carlo codes in continuous energy. A continuousenergy code written in pure Python, however, would be most probably too slow for high-performance computing applications. PapillonNDL's Python API being made available via pybind11 means all computations are actually performed in compiled and optimized C++, allowing for reasonable computation times. Graduate students are not the only ones however who find themselves writing small toy Monte Carlo codes; senior researchers often write "disposable" Monte Carlo codes, as this is where the development of new algorithms and ideas typically takes place.
Comparison with OpenMC There is a small set of unit tests which are run automatically during the development of the library, which makes sure that underlying library functionality is properly functioning. These tests ensure that performing table interpolations and sampling angular distributions are done properly, and yield the expected results. Ensuring the proper implementation of joint angle-energy distributions is more difficult, however. Currently, instead of using unit tests, two supplementary programs are provided with PapillonNDL, allowing the user to directly sample a specified scattering distribution at a specified energy, using  either PapillonNDL or OpenMC. Both programs write all of the sampled energy and cosine pairs to a binary NumPy file. These files are then read by a provided Python script which then performs a Kolmogorov-Smirnov test on the two data sets, verifying that PapillonNDL yields statistically equivalent results to OpenMC.
This slight difference in a discrete distribution will often cause the Kolmogorov-Smirnov test to fail, despite the distributions being equivalent. For this case, it is just ensured that the two distributions appear to be equivalent upon a visual examination of the two plotted distributions. When testing PapillonNDL, different nuclides and reactions were independently examined. For a given nuclide/reaction combination, several incident energies were calculated, based on the threshold energy of the reaction, and the maximum tabulated energy for the nuclide. Each nuclide/reaction/incident energy combination was used to sample a set of outgoing energy and cosine pairs from PapillonNDL and OpenMC. These datasets were then compared to ensure they were statistically equivalent. It is impossible to present the results of all the tests here, but a few different examples of such comparisons are provided in this paper.
Development and distribution PapillonNDL is written in C++, using the recent C++20 standard. Features such as std::span, std::ranges, and std::source location provide a rich set of features and abstractions which facilitate development. Modules were also introduced in C++20, but the library does not currently make use of this feature, due to the lack of uniform compiler support. The choice of C++20 helps ensure the longevity of the project, as compiler support for this standard will only increase with time. Currently, however, it means that the choice of available compilers is rather limited. On GNU/Linux and BSD systems, PapillonNDL has been successfully compiled with GCC 11, GCC 12, and Clang 15 when using libstdc++ (libc++ does not yet  support all required C++20 features). It is also possible to build PapillonNDL on Windows systems using MSVC version 19.
29 or higher. In addition to a sufficient C++20 compiler, CMake is also required, as it is the build system used for the project. No other dependencies are required to build PapillonNDL if one only intends to use the C++ API. The Python API is generated using the pybind11 library. This dependency is automatically downloaded by CMake if the Python bindings option is enabled. Additionally, Python must also be installed on the system, with the required development header files. Each class in the library has bindings which make it possible to use the exact same C++ interface from within Python, resulting in one uniform API for the two languages. Documentation is generated from the C++ source using Doxygen, and currently also serves as the documentation for the Python API. PapillonNDL is currently developed publicly on GitHub, at https://github.
Conclusions and future developments The Papillon Nuclear Data Library (PapillonNDL) is a stand-alone C++ and Python library, which can be used to read and interact with continuous-energy nuclear data stored in ACE files. Currently, both free-gas data for neutrons, and thermal scattering law ACE files can be read by the library, giving users access to all continuous-energy neutron physics. It has been written with the express goal of facilitating fundamental research and nuclear engineering education. Experienced researchers will find utility in the library, as the C++ interface makes it easy to implement small continuous-energy Monte Carlo codes to test new simulation methods and algorithms, as part of the research process. The Python interface makes it easy for students to gain access to continuous-energy nuclear data.
PapillonNDL is distributed as free and open-source software, and can be used on all major operating systems, making it a valuable tool in the classroom. The implementation of the sampling routines in the library has been tested by sampling sets of scattering energy-angle pairs from both PapillonNDL and OpenMC. Kolmogorov-Smirnov tests were used to check that the two sampled sets were statistically equivalent. This verification was performed using Lib80x, and for all distributions which have been examined, an excellent statistical agreement has been observed. In the future, it is hoped that the development of the library will continue. Short-term goals are focused on improving the representation of thermal scattering laws. Both incoherent elastic and incoherent inelastic scattering use discrete distributions for scattering angles  [9].
The R-Matrix code SAMMY  [1]  is a widely used nuclear data evaluation code focused on the resolved range, which includes corrections for experimental effects. The code is still mostly written in FORTRAN 77 and uses a memory management system suitable for the time of its initial writing in 1984. A modernization effort is underway to update the code to modern software development practices. A continuous-integration testing framework was added to automate the large existing set of test cases. Improvements in memory management were implemented to make the code easier to maintain and enable enhancements. The resonance parameters and covariance information are now stored in C++ objects shared by SAMMY and AMPX [2], which is the processing code that generates nuclear data libraries for SCALE  [3].
Further plans include switching to the Evaluated Nuclear Data File (ENDF) reading and writing routines in AMPX because these routines are more robust, easier to maintain, and support more features. Support for the new Generalized Nuclear Database Structure (GNDS) format [4] is also of interest. GNDS will share not only the resonance parameters but also the parameters associated with experimental correction in GNDS. The data are currently available in a binary SAMMY format, and the ability to export them to GNDS would make them more widely available and shareable. The next step will be to use the same resonance processing code at 0K in AMPX and SAMMY as an available formalism. Then, any improvements in the formalism can immediately be tested in SCALE because the reconstruction in AMPX will use the same cross section model.
Introduction The R-Matrix code SAMMY  [1]  is widely used to analyze experimental data in the resolved resonance range (RR). Although mostly focused on evaluation in the RR, some capabilities for the unresolved resonance range (URR) are also available. The RR has a extensive set of corrections for experimental effects that aids in the analysis. At the beginning of the modernization cycle, SAMMY still mostly consisted of fixed length Fortran 77 code and used a memory management system suitable for the time of its initial writing in 1984. A modernization effort is underway to update the code to modern software development practices and allow the use of modern tools for better code error detection. However, because SAMMY is * e-mail: wiardadam@ornl. gov This manuscript has been authored by UT-Battelle, LLC, under contract DE-AC05-00OR22725 with the US Department of Energy (DOE).
The US government retains and the publisher, by accepting the article for publication, acknowledges that the US government retains a nonexclusive, paid-up, irrevocable, worldwide license to publish or reproduce the published form of this manuscript, or allow others to do so, for US government purposes. DOE will provide public access to these results of federally sponsored research in accordance with the DOE Public Access Plan (http://energy. gov/downloads/doe-public-access-plan). used in production environments, functionality cannot be lost during the modernization effort. Also, because of the complexity of the experimental corrections and intricacies of the fitting algorithm, SAMMY cannot be rewritten from scratch to modern software specifications. Nevertheless, modernization is needed to enable the addition of new features (e.
Modern memory management and modular design At the time of SAMMY's initial writing, FORTRAN did not support dynamically allocated arrays, and memory was limited. Although the design choices were excellent for that time, faster computers and the availability of more memory allow to update the code easier to make it easier read and maintain. The two main components in SAMMY that are attributable to the initial design choice are (1) the container array and (2) writing various scratch files. The scratch files are eliminated as new parts of the SAMMY code base are modernized. In the original design, a large chunk of memory was created at compile time, and pieces are allotted to arrays as needed during calculations. Drawbacks include the need to determine at compile time the size of the problems that SAMMY can handle and the need for SAMMY to handle memory allocation-a task the operating system is better equipped to handle.
Additionally, modern tools such as Vagrind  [6]  cannot be used to detect overstepped array bounds. Researchers decided to take two different approaches: (1) use FORTRAN dynamically allocated arrays where appropriate and (2) use internal C++ storage options where code is converted. Although both methods might be less efficient than using the allocation from a large existing array, they provide better error detection and more granularity on the memory used. They will also allow performance bottlenecks to be pinpointed, which will addressed as needed without affecting the internal working in SAMMY. This is especially true for the internal C++ classes because SAMMY only accesses the information via well-defined interfaces. The use of the container array in SAMMY was completely eliminated, and the use of tools such as Valgrind aided greatly in finding and fixing many memory errors in SAMMY.
Modular design Because of the computing power limitations at the initial writing of SAMMY, various parts of the code needed to be very interdependent and share many global parameters. This made the code more difficult to understand and update with new features. In addition it was not possible to reuse parts of SAMMY in other projects (e. g. , resonance reconstruction, experimental correction), or to implement other fitting routines into SAMMY. The ability to share resonance reconstruction and derivatives of the resonance parameters with respect to cross section with AMPX  [2]  would be very useful. Because AMPX uses many of the same developers as SAMMY, it is advantageous to share as much code as possible. Sharing code would make SAMMY more efficient and allow any new features in the resonance algorithm to be available in AMPX and thus in SCALE  [3]  transport libraries.
Thus, the desired outcome is an application program interface (API) for major components in SAMMY. These components (e. g. , reconstruction of cross section and angular distributions from resonance parameters, Doppler broadening, resolution broadening, and parameter adjustment) should not use any global parameters. AMPX has an in-memory C++ class that collects all RR and URR parameters, and this class is now used throughout SAMMY, thus enabling the easy exchange of resonance parameters between SAMMY and other programs. This feature has already been used to explore different adjustment methods  [7]. Additionally, the resonance processing for the RR in SAMMY can now be called via an API. Unfortunately, because of how the fitting and covariance information are set up in SAMMY, the resonance processing at 0K still uses a few global parameters, not the resonance parameters.
The user input determines which algorithm to use for the cross section calculation and sets up the correct module so that the API for each of the modules is independent of the algorithm. The same is true for the Doppler broadening modules. Modularization of the resolution broadening routines is currently in progress. A new C++ in-memory class was added to SAMMY to address the storage of cross section, angular distributions, and derivatives. This class offers easy access methods to the underlying information. The calling routines are thus shielded from internal storage information, which might change in future updates to speed up access. This class allowed much duplicate code to be removed from the existing code base that repeatedly had complicated access patterns to this information and made it much easier to separate data storage from the algorithm.
These updates also uncovered and fixed previous errors in which the cross section or derivatives were not placed in the correct position on the FORTRAN arrays. One integral part of the adjustment procedure is the covariance matrix with respect to the varied parameters. There are two aspects to the covariance matrix as it pertains to SAMMY: the covariance matrix itself and the index into the matrix for a given varied parameter. For the covariance matrix, the storage was switched to a C++ matrix class from AMPX. The class offers convenience functions to set and retrieve matrix elements while shielding SAMMY code from the underlying storage information, enabling a matrix object to be used that internally suppresses zeros without needing the client code to have any knowledge of the suppression.
Previously, the covariance matrix was stored and retrieved many times in scratch files. The change to the AMPX covariance matrix class enabled the elimination of scratch files connected to this information. Additionally, a new class was added to track the indices of the varied parameters in the covariance matrix. SAMMY enables unvaried parameters with uncertainties incorporated into the data covariance matrix. In the context of SAMMY, these parameters are called pup'ed parameters. The new class is especially helpful in managing these two types of parameters because the parameter type was previously determined by the order in the covariance matrix. A new function was also added to determine the parameter type, so client code does not need to be concerned with the order of the covariance matrix.
Future updates SAMMY currently uses its own routines to write Evaluated Nuclear Data File (ENDF)-formatted files  [8]. Because of the computing power limitations at the time of writing SAMMY and the constraints this puts on the code, these routines are becoming more difficult to maintain, especially because the resonance parameters and covariance information were moved to C++ storage. However, AMPX has extensive support for reading ENDF-formatted files and some support for writing. SAMMY will be changed to use these routines, and the writing capablity in AMPX will be updated as needed. The ENDF community is switching to a new ENDF format called Generalized Nuclear Database Structure (GNDS)  [4]. AMPX already has support to handle this new format, thus enabling SAMMY to gain the capability to natively support the new format.
This will become especially important as updates to the resonance formalism are proposed and added to the GNDS format. Additional planned updates include introducing an imaginary component to the R-matrix channel radii to parameterize eliminated direct capture channels in Reich-Moore approximation. Improvements in the URR are also needed, especially to enable the simultaneous fitting of the RR and the URR. Ultimately, the modularization of the code and the elimination of global parameters will enable the use of multiple targets and compound systems.
Conclusion A significant modernization effort for the R-Matrix code SAMMY is underway. Thus far, the work has focused on making the code easier to maintain while not breaking any functionality. To make this process more efficient, some functionality already available in AMPX was used in SAMMY. These changes will enable the sharing of resonance structure and formalism, as well as make it easier to test advancements in resonance formalism in the SCALE transport code. Additionally, the code base was made more modular, enabling a cleaner interface to reconstruct cross sections, Doppler broadening, and resolution broadening. This enabled researchers to build a prototypical API to SAMMY that can be used in external programs to use any of these parts separately. Although further work is needed to improve this API, it already has already been used in a current project  [7].
Observational Data In this section, we first discuss the JCMT SCUBA-2/POL-2  (Bastien et al. 2011; Holland et al. 2013; Friberg et al. 2016)  polarimetric observations of NGC 6334 at 850 μm, taken as part of the B-fields In STar-forming Region Observations (BISTRO) survey (Ward-  Thompson et al. 2017). We then present the HII regions of NGC 6334 as obtained from a variety of previously published catalogs.