Search NASA⌕ Search

SEARCH · Search NASA

Results for “Debugging”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 235 records · Page 13
All sourcesNASA NTRSDOE OSTI
DOE OSTI2019

Production Operations Management System

The Production Operations Management System (POMS) is a set of software tools which allows production teams and analysis groups across multiple Fermilab experiments to launch, modify and monitor large scale campaigns of related Monte Carlo or data processing jobs. POMS provides a web service interface that enables automated jobs submission on distributed resources according to customers’ requests and subsequent monitoring and recovery of failed submissions, debugging and record keeping. POMS interfaces with existing HEP data access, processing, movement and monitoring tools at Fermilab, including Jobsub, dCache, SAM, and FIFEmon, and in combination with them handles the creation and tracking of unique filenames for multistage campaigns. A flexible, interactive GUI interface exists as part of the system to visualize campaign stages, parallelization tracks and data flow. An important feature of POMS is a one-to-one connection between the GUI campaign visualizer and a text based representation of the complete campaign configuration. An extensible library of template campaign configurations is available. The templates are user modifiable and map cleanly to and from the GUI description of the campaign. Future releases of POMS will interface with Rucio for file movement.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2020

The Kokkos Ecosystem [Brief]

In 2016/2017, the field of High-Performance Computing (HPC) entered a new era driven by fundamental physics challenges to produce ever more energy and cost-efficient processors. Since the convergence on the Message-Passing Interface (MPI) standard in the mid-1990s, application developers enjoyed a seemingly static view of the underlying machine — that of a distributed collection of homogeneous nodes executing in collaboration. However, after almost two decades of dominance, the sole use of MPI to derive parallelism acted as a limiter to improved future performance. While MPI is widely expected to continue to function as the basic mechanism for communication between compute nodes for the immediate future, additional parallelism is required on the computing node itself if high performance and efficiency goals are to be realized. When reviewing the architectures of the top HPC systems today, the change in paradigm is clear: the compute nodes of the leading machines in the world are either powered by many-core chips with a few dozen cores each, or use heterogeneous designs, where traditional CPUs marshal work to massively parallel compute accelerators which has as many as 200,000 processing threads in flight simultaneously. Complicating matters further for application developers, each processor vendor has its own preferred way of writing code for their architecture.The Kokkos EcoSystem was released by Sandia in 2017 to address this new era in HPC system design by providing a vendor independent performance portable programming system for scientific, engineering, and mathematical software applications written in the C++ programming language. Using Kokkos, application developers can be more productive because they will not have to create and maintain separate versions of their software for each architecture, nor will they have to be experts in each architecture's peculiar requirements. Instead, they will have a single method of programming for the diverse set of modern HPC architectures. While Kokkos started in 2011 as a programming model only, it soon became clear that complex applications needed more. It is also critical to have a portable mathematical functions and developers need tools to debug their applications, gain insight into the performance characteristics of their codes and tune algorithm performance parameters through automated processes. The Kokkos EcoSystem addresses those needs through its three main components: the Kokkos Core programming model, the Kokkos Kernels math library, and the Kokkos Tools project.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2020

Sandia GNU Radio Utilities

The Sandia Utilities form an RF toolkit extending the GNU Radio framework for straightforward interaction with bursty RF systems which can be cumbersome using built in capabilities of the framework or other open source extensions. Motivated by the abstract exercise of responding to a modulated burst of information with a unique modulated burst of information, the Sandia Utilities provide several dozen additional debug and signal processing blocks through four software modules. These blocks manifest their utility through a new general concept of operation for GNU Radio applications and extend many existing streaming capabilities to the PDU-based message passing API. Using these concepts and tools, it is straightforward to develop software capabilities to interact with existing and new bursty RF devices.

47 OTHER INSTRUMENTATION↗
DOE OSTI2019

Multigroup Neutron Cross Section Generation for the SCEPTRE Code

Multigroup neutron cross sections were generated for the deterministic radiation transport code SCEPTRE. ENDF/B-VII.1 nuclear data files were downloaded from Los Alamos National Laboratory (LANL), processed with the LANL cross-section preparation code NJOY-2012, and post-processed to produce a SCEPTRE-formatted cross section file. A simple radiation transport problem was used to compare results calculated with MCNP, a continuous-energy radiation transport code from LANL, to results calculated with SCEPTRE using the NJOY-2012-produced multigroup cross sections. This problem was used to debug the python scripts used to post-process the NJOY-2012 output and to assess the accuracy of the multigroup cross sections. These comparisons demonstrate that the multigroup cross sections generated in this work are accurate for most elements but yielded inaccurate results for several common transition metals. This discrepancy appears to result from poor treatment of the resolved resonance region of the continuous-energy cross sections. Further work is recommended to investigate alternative methods to treat these resonances with NJOY-2012.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
DOE OSTI2021

Institutional Computing: Annual Progress Report, Precision early universe simulations to constrain nuclear reactions and beyond standard model physics

The current one-year allocation (w20 qburst) is the first year in a two year allocation of the same name. The project has supported two publications in peer-review journals, another manuscript in preparation for publication, a white paper for the Astro2020 Decadal Survey, and a number of talks (see below). Code development continues on implementing a neutrino quantum kinetic equation solver into BURST, now called QBURST. While implementing coherent and forward-scattering processes into the dynamical neutrino evolution equations, multiple numerical issues have appeared. We have remedied a number of these issues through extensive debugging and testing, which include streamlining interpolation and implementing new ODE integration techniques. Further testing is required to solve the problem at a precision of better than one part in 10 6 . We expect that we will understand the numerical difficulties and implement solutions by end of year 2021.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
DOE OSTI2021

BOPTEST: Initial FRP Test Case Development

To support an emulator model development of Building Optimization Testing (BOPTEST) framework, a team at the US Department of Energy’s Oak Ridge National Laboratory developed a medium-sized office building written in Modelica to serve as a reference test case. The reference test case was modeled based on an actual research platform that represents a typical medium-sized office building. This test case would encourage model-based design and testing of new controllers in which a developer first prototypes and debugs on a model before implementing in the real world. The developed preliminary model and control parameters will be further calibrated and tuned with actual measured data from experiments

42 ENGINEERING↗
DOE OSTI2022

OASIS: Open-Source AI Software Infrastructure for Science-SBIR Phase I

OASIS: Open source AI Software Infrastructure for Science is developed for researchers in the scientific domain. OASIS provides a data API to ingest and serve scientific data formats and annotations within AI workflows. It delivers a unique integration of features such as coupling of data to AI models, scalable training, cloud deployment into a cohesive web and command-line interface, and state-of-the-art techniques to debug and enhance AI models.

Chaudhary, Aashish↗
DOE OSTI2021

Code Development Supporting a Non-Thermal Source of High Fluence Warm X-Ray

A six-month research effort has advanced the hybrid kinetic-fluid modeling capability required for developing non-thermal warm x-ray sources on Z. The three particle treatments of quasi-neutral, multi-fluid, and kinetic are demonstrated in 1D simulations of an Ar gas puff. The simulations determine required resolutions for the advanced implicit solution techniques and debug hybrid particle treatments with equation-of-state and radiation transport. The kinetic treatment is used in preliminary analysis of the non-Maxwellian nature of a gas target. It is also demonstrates the sensitivity of the cyclotron and collision frequencies in determining the transition from thermal to non-thermal particle populations. Finally, a 2D Ar gas puff simulation of a Z shot demonstrates the readiness to proceed with realistic target configurations. The results put us on a very firm footing to proceed to a full LDRD which includes continued development transition criteria and x-ray yield calculation.

36 MATERIALS SCIENCE↗
DOE OSTI2021

Quantitative Performance Assessment of Proxy Apps and Parents (Report for ECP Proxy App Project Milestone ADCD-504-11)

The ECP Proxy Application Project has an annual milestone to assess the state of ECP proxy applications. Our FY21 milestone (ADCD-504-11) proposed to: "Assess the performance and fidelity of proxy applications, including those in the ECP Proxy App Suite, relative to the ECP Application workload on heterogeneous platforms. Use proxy applications and selected ECP applications to assess the utility of critical elements of the Exascale toolchain, especially tools used to collect performance data. Identify gaps in coverage and/or common situations in which proxies may fail to adequately represent ECP applications." To satisfy this milestone, the following specific tasks were completed: Study ability of MACSio to represent I/O workloads of adaptive mesh codes; Prepare report on assessed performance and debugging tools; Perform cosine similarity study on Intel and P9 and submit paper; Complete LDMS/GPU subcontract, complete and receive report; Complete validation of LDMS data collection for GPUs and submit paper; and Perform cosine similarity study on GPUs.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2021

Impacts of Substrate Thinning on FPGA Performance and Reliability [Slides]

Substrate thinning is necessary in devices with flip-chip BGA packages to enable both radiation testing and component qualification and high-spatial resolution beam-based failure analysis methods. We investigated three factors affecting device performance: subsurface damage from the thinning process, reduced heat spreading in thin substrates, and changes in device switching speed. We conclude subsurface damage to crystalline Si caused by the thinning process is removable with sufficient SiO 2 slurry polishing. Local temperature differences increase minimally in devices thinned to 3 μm. Compressive stress in the Si increases globally after device thinning and leads to slowing of ring oscillator frequency by about 0.5% compared to full-thickness devices. Future work will include extending the results to submicron Si thickness values, which also has important benefits for failure analysis, debug, and security assessments. We also plan to extend this type of work to other FPGAs and other devices like memory and processors.

36 MATERIALS SCIENCE↗
DOE OSTI2020

Evaluation of a streaming readout solution for Jefferson Lab experiments

Jefferson Lab (JLab) operates the CEBAF accelerator that provides a high energy (up to 12 GeV) and high current (up to 150 µA) polarized electron beam for fixed target experiments. JLab's mission is to provide substantial progress in understanding the Quantum Chromo Dynamics (QCD), the current theory of the spectrum and the dynamics of hadronic matter. Given the broad scientific program a general-purpose detector, CLAS12, has been designed and constructed. Such a detector requires a sophisticated trigger and current experiments use an on-line FPGA-based system that relies upon custom firmware and electronics both of which are difficult reconfigure from one experiment to the next. To overcome these challenges transitioning to a streaming readout has been proposed since it would allow a more flexible, easier to debug, software trigger to be developed. To facilitate this JLab is gaining experience with streaming readout systems and is actively working to design and test a streaming data acquisition architecture. Significant work has already been done to make existing front-end electronics compatible with operation in streaming mode. Software-wise, much work remains to be done but an existing framework, TriDAS, which was developed for underwater neutrino telescopes can, in principle, be used with the existing JLab hardware. A test stand is already in place in the INDRA DAQ development lab at JLab. This paper will present the development of this TriDAS based test system and it?s operation in-beam using parts of the CLAS12 detector to evaluate streaming readout for a large general purpose detector.

Battaglieri, Marco↗
DOE OSTI2023

Code Coverage Status of ARC Code-DIF3D

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. DIF3D plays a pivotal role in the ARC system as the primary homogenized assembly neutronic calculation methodology for fast reactor problems. Over its 40 years history, ARC software usage with DIF3D has been applied to numerous fast and thermal spectrum reactor analysis projects with good to excellent comparison against experiments. With continued improvement of computation resources, many of the geometry modeling capabilities in DIF3D that were primarily used in low order schemes are not really needed anymore. Today, the diffusion and transport capabilities of DIF3D-VARIANT are primarily used in the reactor design process with some scattered usage of DIF3D-FD and DIF3D-Nodal. In recent work, the DIF3D software verification was completed for DIF3D-FD and DIF3D-VARIANT on the geometry options used in the Versatile Test Reactor project. While we can be confident that these capabilities of DIF3D are well used and thus trusted, it does not demonstrate that all possible input options of DIF3D are actually working, but just those that were tested as part of VTR are and that they are correct. Thus, the purpose of the present work is to identify a set of test problems for DIF3D and assess the code coverage of DIF3D for those test problems. The goal is to document what parts of the existing DIF3D code are touched by the set of test problems and which are not. Because the verification work done on DIF3D-VARIANT and DIF3D-FD was focused on the most common uses of DIF3D for fast reactor analysis, the code coverage assessment of those capabilities is the highest priority. This will ensure that nothing is being missed by the existing verification test problems that DIF3D relies upon. The DIF3D-Nodal capability will also be inspected for code coverage as part of this work to further ensure that regular regression testing of DIF3D will trap any likely errors the end user might experience with the DIF3D software. The code coverage analysis of DIF3D was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of DIF3D. The detailed coverage tables are given for each submodule of DIF3D separately, and for the submodules which are primarily developed for DIF3D, most of the source files could be at least partially touched. Most of the uncovered parts/files could be easily ignored, because they are either for error message and debugging output or obviously not needed by DIF3D. Out of the entire source codes of DIF3D, only a few uncovered modules deserve further investigation.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2024

Enhancements and Deployment of the TDAQ System for the Mu2e Experiment

The Real Time Processing Systems Division at Fermilab has deployed new features to the Off-The-Shelf Data Acquisition framework (otsdaq) for the Mu2e experiment. The Mu2e experiment will search for the coherent neutrino-less conversion of a muon into an electron in the field of an aluminum nucleus with a sensitivity improvement of 10,000 times over existing limits. Such a charged lepton flavor-violating reaction probes new physics at a scale unavailable at present or planned high-energy colliders. The Mu2e Trigger and Data Acquisition (TDAQ) system uses otsdaq as its online Data Acquisition System (DAQ) framework. otsdaq integrates the artdaq and art frameworks for event transfer, filtering, and processing. otsdaq is a web-based DAQ software suite focusing on flexibility and scalability and provides a multi-user interface accessible through a web browser. artdaq handles the entire data stream, which is read over the peripheral component interconnect express (PCIe) bus to a software filter algorithm that selects events combined with the data flux coming from a cosmic-ray veto (CRV) system. Detector front-ends are configured through the PCIe bus by customized otsdaq plugins. The otsdaq slow controls infrastructure has been further developed using the experimental physics and industrial control system (EPICS) open-source platform for monitoring, controlling, alarming, and archiving. The detector control system (DCS) for Mu2e has been integrated into otsdaq. The production TDAQ and DCS system has been deployed at the experimental hall and is being debugged and optimized for experiment operations. We report on the feature enhancements and deployment of otsdaq for Mu2e.

72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗
DOE OSTI2024

Using Parameter Sweep in WaterTAP to Analyze New Water Treatment Technologies

We describe a powerful and generalized parameter sweep tool in this report that was originally developed to analyze the performance of existing and novel water treatment models being developed in WaterTAP. Since WaterTAP is built upon IDAES and Pyomo, the parameter sweep tool can be used to systematically explore and debug the behavior of most Pyomo and IDAES numerical models. In order to enable meaningful analyses, the parameter sweep tool has been designed with the following features: 1) Model flexibility: The parameter sweep tool does not enforce any restrictions on the types of models that can be used with it. As long as a Pyomo model can be solved and the parameter is active and mutable, the tool only needs functions that describe how to run the model, the sweep parameters, and the output quantities of interest. 2) Flexible sampling: The parameter sweep tool has inbuilt functions to generate samples from a random distribution or a multidimensional Euclidean space. Furthermore, the users have to ability to supply samples generated from a tool of their choice. 3) Multiple sweep types: A user can choose from one of 3 types of parameter sweeps depending on their needs. 4) Detailed outputs: Outputs generated by the parameter sweep tool can be stored in detailed H5 file or user-friendly CSV files for post processing. 5) Parallel computing: The parameter sweep supports shared and distributed memory parallel computing to enable the use of high performance computers (HPC) for large-scale analyses. 6) Modular: The parameter sweep tool is self-contained and can easily be integrated within an outer-loop analysis or as desired by the user. 7) Ease of use: The tool is well documented and a simple sweep can be easily executed by following the online documentation in a few lines of code. We demonstrate the use of the parameter sweep tool on a simple water treatment system from the WaterTAP repository and show its parallel scaling performance on an Apple laptop and NREL's Eagle HPC. The parameter sweep tool is actively being used with models currently being developed within WaterTAP and we expect its use to grow beyond it to other IDAES and Pyomo models.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2024

Using containers to speed up development, to run integration tests and to teach about distributed systems

GlideinWMS is a workload manager provisioning resources for many experiments including CMS and DUNE. The software is distributed both as native packages and specialized production containers. Following an approach used in other communities like web development we built our workspaces, system-like containers to ease development and testing. Developers can change the source tree or check out a different branch and quickly reconfigure the services to see the effect of their changes. In this paper, we’ll talk about what differentiates workspaces from other containers. We’ll describe our base system composed of three containers. A one-node cluster including a compute element and a batch system. A GlideinWMS Factory controlling pilot jobs. And a scheduler and Frontend, to submit jobs and provision resources. Additional containers can be used for optional components. This system can easily run on a laptop and we’ll share our evaluation of different container runtimes, with an eye for ease of use and performance. Finally, we’ll talk about our experience as developers and with students. The GlideinWMS workspaces are easily integrated with IDEs like VS Code, simplifying debugging and allowing development and testing of the system also when offline. They simplified the training and onboarding of new team members and Summer interns. And they were useful in workshops where students could have first-hand experience with the mechanisms and components that, in production, run millions of jobs.

Mambelli, Marco↗
DOE OSTI2024

Zero Emission Cargo Transport (ZECT) II Demonstration: South Coast Air Quality Management District (Final Report)

The South Coast Air Quality Management District (South Coast AQMD), California Air Resources Board (CARB) and Southern California Association of Governments (SCAG) — the agencies responsible for preparing the State Implementation Plan required under the federal Clean Air Act — have agreed that attainment of federal air quality standards for the region will require a transition to the broad use of zero and near-zero emission energy sources in cars, trucks and other equipment. Accordingly, the 2012 South Coast AQMD Air Quality Management Plan, the SCAG 2012 Regional Transportation Plan, and the “Vision for Clean Air: A Framework for Air Quality and Climate Control Planning” all identify the need to immediately enact a phasing in of zero and near-zero emission technologies to meet air quality goals. In 2014, South Coast AQMD was awarded grant funding under the US Department of Energy Zero Emission Cargo Transport (ZECT) II Demonstration program to develop and demonstrate zero-emission drayage trucks for goods movement operations between the Port of Los Angeles (POLA) and Port of Long Beach (POLB) near dock rail yards and warehouses: 1) development and demonstration of zero-emission fuel cell range extended electric drayage trucks and 2) development and demonstration of hybrid electric drayage trucks. The purpose of this project was to accelerate deployment of zero emission cargo transport technologies to reduce harmful diesel emissions, petroleum consumption and greenhouse gases in the surrounding communities along the goods movement corridors that are impacted by heavy diesel traffic and the associated air pollution. Between 2014 – 2024, six ZECT II zero-emission fuel cell drayage truck platforms, including fuel cell range extended and CNG hybrid trucks, were successfully designed, developed, integrated, built, tested, and demonstrated with drayage fleet operators in transportation corridors within areas of the South Coast AQMD jurisdiction in Southern California such as in and around POLA and POLB. Portable hydrogen refueling was deployed to support the fuel cell vehicles. The project had real-time improvement with on-going debugging and optimizations while the vehicles were under demonstration. All platforms demonstrated sufficient or excess power, torque, and energy to support 82,000lbs Gross Vehicle Weight Rating and gradeability to perform their daily duty cycles. Collectively, the trucks drove over 23,000 miles during their respective demonstration phases. The ZECT II project was the first of its kind to demonstrate the commercial viability that supported the additional technology breakthroughs for Class 8 zero emission trucks and validations as well as the regulatory basis for all the zero-emission regulation that we know today, such as the Innovative Clean Transit regulation, Advanced Clean Trucks and Clean Fleet regulations.

08 HYDROGEN↗
DOE OSTI2025

Code Coverage Status of the ARC Code DIF3D

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. DIF3D plays a pivotal role in the ARC system as the primary homogenized assembly neutronic calculation methodology for fast reactor problems. Over its 40 years history, ARC software usage with DIF3D has been applied to numerous fast and thermal spectrum reactor analysis projects with good to excellent comparison against experiments. With continued improvement of computation resources, many of the geometry modeling capabilities in DIF3D that were primarily used in low order schemes are not really needed anymore. Today, the diffusion and transport capabilities of DIF3D-VARIANT are primarily used in the reactor design process with some scattered usage of DIF3D-FD and DIF3D-Nodal. In recent work, the DIF3D software verification was completed for DIF3D-FD and DIF3D-VARIANT on the geometry options used in the Versatile Test Reactor project. While we can be confident that these capabilities of DIF3D are well used and thus trusted, it does not demonstrate that all possible input options of DIF3D are actually working, but just those that were tested as part of VTR are and that they are correct. Thus, the purpose of the present work is to identify a set of test problems for DIF3D and assess the code coverage of DIF3D for those test problems. The goal is to document what parts of the existing DIF3D code are touched by the set of test problems and which are not. Because the verification work done on DIF3D-VARIANT and DIF3D-FD was focused on the most common uses of DIF3D for fast reactor analysis, the code coverage assessment of those capabilities is the highest priority. This will ensure that nothing is being missed by the existing verification test problems that DIF3D relies upon. The DIF3D-Nodal capability will also be inspected for code coverage as part of this work to further ensure that regular regression testing of DIF3D will trap any likely errors the end user might experience with the DIF3D software. The code coverage analysis of DIF3D was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of DIF3D. The detailed coverage tables are given for each submodule of DIF3D separately, and for the submodules which are primarily developed for DIF3D, most of the source files could be at least partially touched. Most of the uncovered parts/files could be easily ignored, because they are either for error message and debugging output or obviously not needed by DIF3D. Out of the entire source codes of DIF3D, only a few uncovered modules deserve further investigation.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2025

Code Coverage Status of the ARC Code PERSENT

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. PERSENT fulfills the role of generating reactivity coefficients for a given time point of a REBUS calculation usable in a point kinetics based safety analysis capability. PERSENT also provides a sensitivity coefficient capability on eigenvalue, reactivity worth, and several other key coefficients that are used in the follow-on safety analysis. Given a co-variance matrix, PERSENT can carry out the uncertainty quantification to indicate the amount of error in the reactivity coefficients derived from the errors in the cross section measurements. With continued improvement of computational resources, many of the geometry modeling capabilities in DIF3D that were primarily used in low order schemes are not really needed anymore. Today, the diffusion and transport capabilities of DIF3D-VARIANT are primarily used in the reactor design process with some scattered usage of DIF3D-FD and DIF3D-Nodal. PERSENT is part of the ARC code system and is built around DIF3D-VARIANT and the flux solution it provides. The purpose of the present work is to identify a set of test problems for PERSENT and assess the code coverage of PERSENT for those test problems. PERSENT treats the DIF3D executable as an external executable and thus the code coverage considerations only need to focus on the PERSENT source code and only a fraction of the connected modules in the existing ARC software library. The goal is to document what parts of the existing PERSENT code are touched by the set of test problems and which are not. Because the verification work done on PERSENT was focused on the most common uses of PERSENT for fast reactor analysis, the code coverage assessment of those capabilities is the highest priority. This will ensure that nothing is being missed by the existing verification test problems that users of PERSENT rely upon. The code coverage analysis of PERSENT was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of PERSENT. The detailed coverage tables are given for each submodule of PERSENT. Most of the uncovered parts/files could be easily ignored because they are either for error message and debugging output or not needed by PERSENT today. Only a few uncovered parts of PERSENT deserve extending the verification test suite.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗