SALAMANDER System Requirements Specification
This template follows INL template TEM-135, "IT System Requirements Specification".
This document serves as an addendum to Framework System Requirements Specification and captures information for SRS specific to the SALAMANDER application.
- Framework System Requirements Specification
- Electromagnetics System Requirements Specification
- Fluid Properties System Requirements Specification
- Heat Transfer System Requirements Specification
- Misc System Requirements Specification
- Navier Stokes System Requirements Specification
- Phase Field System Requirements Specification
- Reactor System Requirements Specification
- Reconstructed Discontinuous Galerkin System Requirements Specification
- Ray Tracing System Requirements Specification
- Scalar Transport System Requirements Specification
- Solid Mechanics System Requirements Specification
- Solid Properties System Requirements Specification
- Stochastic Tools System Requirements Specification
- SubChannel System Requirements Specification
- Thermal Hydraulics System Requirements Specification
- TMAP8 System Requirements Specification
Introduction
System Purpose
The purpose of SALAMANDER is to perform fully integrated, high-fidelity, multiphysics simulations of fusion energy systems and devices at different length scales with a variety of materials, system configurations, and component designs in order to better understand component degradation and operational impacts on system performance. SALAMANDER's main goal is to bring together the combined multiphysics capabilities of the MOOSE ecosystem to provide an open platform for future research, safety assessment, engineering, and design studies of magnetic confinement fusion energy systems.
System Scope
SALAMANDER is an application for performing system-level, engineering scale (i.e., at the scale of centimeters and meters), and microstructure-scale (i.e., at the scale of microns) multiphysics calculations related to magnetic confinement fusion energy systems. These models often include highly coupled systems of equations related to plasma physics, electromagnetics, heat conduction, scalar transport, thermal hydraulics, computational fluid dynamics (CFD), and thermomechanics, amongst others. Interfaces to other MOOSE-based codes, including tritium transport (TMAP8) and neutronics (Cardinal) are also included to support SALAMANDER simulations. SALAMANDER will enable high-fidelity modeling of irradiation levels and plasma exposure conditions of plasma facing components and their impact on heat and tritium distributions, as well as the resulting mechanical constraints experienced by the plasma facing components. The MultiApp System is leveraged to allow for the multiscale, multiphysics coupling. Further, other MOOSE capabilities (such as the stochastic tools module) will eventually enable engineering studies, allowing for extended uncertainty quantification and risk analysis studies for particular system designs. Interfaces for computer-aided design (CAD) meshing workflows to model complex geometries are also included. SALAMANDER therefore supports design, safety, engineering, and research projects.
System Overview
System Context
The SALAMANDER application is command-line driven. Like MOOSE, this is typical for a high-performance software that is designed to run across several nodes of a cluster system. As such, all usage of the software is through any standard terminal program generally available on all supported operating systems. Similarly, for the purpose of interacting through the software, there is only a single user, "the user", which interacts with the software through the command-line. SALAMANDER does not maintain any back-end database or interact with any system daemons. It is an executable, which may be launched from the command line and writes out various result files as it runs.
Figure 1: Usage of SALAMANDER and other MOOSE-based applications.
System Functions
Since SALAMANDER is a command-line driven application, all functionality provided in the software is operated through the use of standard UNIX command line flags and the extendable MOOSE input file. SALAMANDER is completely extendable so individual design pages should be consulted for specific behaviors of each user-defined object.
User Characteristics
Software for Advanced Large-scale Analysis of MAgnetic confinement for Numerical Design, Engineering & Research (SALAMANDER) has three main classes of users:
SALAMANDER Developers: These are the core developers of SALAMANDER. They are responsible for designing, implementing, and maintaining the software, while following and enforcing its software development standards.
Developers: These are scientists or engineers that modify or add capabilities to SALAMANDER for their own purposes, which may include research or extending its capabilities. They will typically have a background in fusion energy sciences, plasma physics, tritium migration, radiation transport, heat conduction, and/or material science as well as in modeling and simulation techniques, but may have more limited background in code development using the C++ language. In many cases, these developers will be encouraged to contribute code back to SALAMANDER.
Analysts: These are users that run SALAMANDER to run simulations, but do not develop code. The primary interface of these users with SALAMANDER is the input files that define their simulations. These users may interact with developers of the system requesting new features and reporting bugs found.
Assumptions and Dependencies
The SALAMANDER application is developed using MOOSE and is based on various modules, as such the SRS for SALAMANDER is dependent upon the files listed at the beginning of this document. Any further assumptions or dependencies are outlined in the remainder of this section.
SALAMANDER has no constraints on hardware and software beyond those of the MOOSE framework and modules listed in their respective SRS documents, which are accessible through the links at the beginning of this document.
SALAMANDER provides access to a number of code objects that perform computations, such as particle transport, material behavior, and boundary conditions. These objects each make their own physics-based assumptions, such as the units of the inputs and outputs. Those assumptions are described in the documentation for those individual objects.
References
Definitions and Acronyms
This section defines, or provides the definition of, all terms and acronyms required to properly understand this specification.
Definitions
Verification: (1) The process of: evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. (2) Formal proof of program correctness (e.g., requirements, design, implementation reviews, system tests) (24765:2010(E), 2010).
Acronyms
Acronym | Description |
---|---|
CAD | computer-aided design |
CFD | computational fluid dynamics |
INL | Idaho National Laboratory |
MOOSE | Multiphysics Object Oriented Simulation Environment |
NQA-1 | Nuclear Quality Assurance Level 1 |
POSIX | Portable Operating System Interface |
SALAMANDER | Software for Advanced Large-scale Analysis of MAgnetic confinement for Numerical Design, Engineering & Research |
SRS | Software Requirement Specification |
System Requirements
In general, the following is required for MOOSE-based development:
A POSIX compliant Unix-like operating system. This includes any modern Linux-based operating system (e.g., Ubuntu, Fedora, Rocky, etc.), or a Macintosh machine running either of the last two MacOS releases.
Hardware | Information |
---|---|
CPU Architecture | x86_64, ARM (Apple Silicon) |
Memory | 8 GB (16 GBs for debug compilation) |
Disk Space | 30GB |
Libraries | Version / Information |
---|---|
GCC | 9.0.0 - 12.2.1 |
LLVM/Clang | 10.0.1 - 19 |
Intel (ICC/ICX) | Not supported at this time |
Python | 3.10 - 3.13 |
Python Packages | packaging pyaml jinja2 |
Functional Requirements
- salamander: Auxkernels
- 1.1.1The system shall be able compute a component of the negative gradient of a variable.
- salamander: Benchmarking
- 1.2.1The system shall be capable of solving an ion wall loss problem, as described in chapter 1, pages 26-27 of Principles of Plasma Discharge and Material Processing (ISBN 0-471-72001-1), and reproduce the same
- field variable results, and
- kinetic particle results.
- salamander: Kernels
- 1.3.1The system shall be able to solve a simple diffusion problem.
- salamander: Raybcs
- 1.4.1The system shall be capable of reflecting computational particles off of boundaries and maintain consistent velocity data
- in a 1D domain
- in a 2D domain
- in a 3D domain
- salamander: Userobjects
- 1.5.1The system shall support placing particles within a bounding box uniformly in a parallel consistent manner in the element type
- EDGE2
- TRI3
- QUAD4
- HEX8
- TET4
- PYRAMID5
- PRISM6
- 1.5.2The system return a useful error when the user
- requests an element type that initialization has not been verified for
- tries to setup a bounding box where a component of bottom_left is greater than top_right
- 1.5.3The system return a useful warning to remind the user that the
- 2 extra components of the
bottom_left
andtop_right
inputs are ignored in 1D simulations - 1 extra component of the
bottom_left
andtop_right
inputs are ignored in 2D simulations
- 2 extra components of the
- 1.5.4The system shall be capable of placing particles inside of EDGE2 elements uniformly
- and solve an electrostatic potential based on the particle positions
- in a parallel consistent manner
- and compute the error between an exact electrostatic potential and the finite element solution
- 1.5.5The system shall be capable of placing particles inside of QUAD4 elements uniformly
- and solve an electrostatic potential based on the particle positions
- in a parallel consistent manner
- and compute the error between an exact electrostatic potential and the finite element solution
- 1.5.6The system shall be capable of placing particles inside of TRI3 elements uniformly
- and solve an electrostatic potential based on the particle positions
- in a parallel consistent manner
- and compute the error between an exact electrostatic potential and the finite element solution
- 1.5.7The system shall be capable of placing particles inside of HEX8 elements uniformly
- and solve an electrostatic potential based on the particle positions
- in a parallel consistent manner
- and compute the error between an exact electrostatic potential and the finite element solution
- 1.5.8The system shall be capable of placing particles inside of PRISM6 elements uniformly
- and solve an electrostatic potential based on the particle positions
- in a parallel consistent manner
- and compute the error between an exact electrostatic potential and the finite element solution
- 1.5.9The system shall be capable of placing particles inside of PYRAMID5 elements uniformly
- and solve an electrostatic potential based on the particle positions
- in a parallel consistent manner
- and compute the error between an exact electrostatic potential and the finite element solution
- 1.5.10The system shall be capable of placing particles inside of TET4 elements uniformly
- and solve an electrostatic potential based on the particle positions
- in a parallel consistent manner
- and compute the error between an exact electrostatic potential and the finite element solution
- 1.5.11The system return a useful error when the user
- requests an element type that initialization has not been verified for
- tries to give particles zero mass
- tries to give particles a negative mass
- does not provide enough distributions to sample for velocity initialization.
- tries to put 0 particles in each element.
- tries to request that a particle type be initialized with zero number density
- tries to request that a particle type be initialized with a negative number density
- 1.5.12The system shall be capable of placing particles on a uniform grid on the mesh
- in one dimension.
- 1.5.13The system shall return a useful error when the user tries to use the UniformGridParticleInitializer in
- a two-dimensional simulation, and
- a three-dimensional simulation.
- 1.5.14The system shall be capable of contributing to the residual of a variable based on the computational particles'
- charge density, and
- number density.
- 1.5.15The system shall be capable of accurately capturing the path of charged particles in both an electric and a magnetic field
- 1.5.16The system shall be capable of accurately capturing the path of charged particles in a perpendicular magnetic field
- 1.5.17The system shall be capable of applying a linear impluse from a force field perpendicular to a particles initial velocity using the boris stepper when there is 0 magnetic field
- 1.5.18The system shall be capable of applying a linear impluse from a force field parallel to a particles velocity using the boris stepper when there is 0 magnetic field
- 1.5.19The system shall report a reasonable error from the particle stepper when
- the user does not provide 3 components of the electric field
- the user does not provide 3 components of the magnetic field
- 1.5.20The system shall be capable of applying a linear impulse from a force field perpendicular to a particle\'s initial velocity
- 1.5.21The system shall be capable of applying a linear impulse from a force field parallel to a particle's velocity
- 1.5.22The system shall report a reasonable error from the particle stepper when
- the user does not provide 3 components of the force field
- 1.5.23The system shall be capable of tracking 3 velocity components within the PIC capability while propagating rays in lower dimensions
- salamander: Utils
- 1.6.1The system shall support the accumulation of point values as if they were point sources into an auxiliary field
- 1.6.2The system shall report a reasonable error when accumulating point values into an auxiliary field when the system is not properly finalized
- 1.6.3The system shall support mapping data from rays to an aux variable and reset the aux variable to 0 on each time step
- 1.6.4The system shall support mapping data from rays to an aux variable and reset the aux variable to 0 on each time step on a 2 dimensional mesh
- 1.6.5The system shall support mapping data from rays to an aux variable and then solve differential equations based on the data mapped from rays
- 1.6.6The system shall support the accumulation of point values as if they were point sources into a nonlinear field
- 1.6.7The system shall allow a ray to sample the value of field variable at any point in space as it moves through space
Usability Requirements
No requirements of this type exist for this application, beyond those of its dependencies.Performance Requirements
No requirements of this type exist for this application, beyond those of its dependencies.System Interfaces
No requirements of this type exist for this application, beyond those of its dependencies.System Operations
Human System Integration Requirements
The SALAMANDER application is command line driven and conforms to all standard terminal behaviors. Specific human system interaction accommodations shall be a function of the end-user's terminal. MOOSE (and therefore SALAMANDER) does support optional coloring within the terminal's ability to display color, which may be disabled.
Maintainability
The latest working version (defined as the version that passes all tests in the current regression test suite) shall be publicly available at all times through the repository host provider.
Flaws identified in the system shall be reported and tracked in a ticket or issue based system. The technical lead will determine the severity and priority of all reported issues and assign resources at their discretion to resolve identified issues.
The software maintainers will entertain all proposed changes to the system in a timely manner (within two business days).
The core software in its entirety will be made available under the terms of a designated software license. These license terms are outlined in the LICENSE file alongside the SALAMANDER application source code.
Reliability
The regression test suite will cover at least 90% of all lines of code at all times. Known regressions will be recorded and tracked (see Maintainability) to an independent and satisfactory resolution.
System Modes and States
MOOSE applications normally run in normal execution mode when an input file is supplied. However, there are a few other modes that can be triggered with various command line flags as indicated here:
Command Line Flag | Description of mode |
---|---|
-i <input_file> | Normal execution mode |
--split-mesh <splits> | Read the mesh block splitting the mesh into two or more pieces for use in a subsequent run |
--use-split | (implies -i flag) Execute the simulation but use pre-split mesh files instead of the mesh from the input file |
--yaml | Output all object descriptions and available parameters in YAML format |
--json | Output all object descriptions and available parameters in JSON format |
--syntax | Output all registered syntax |
--registry | Output all known objects and actions |
--registry-hit | Output all known objects and actions in HIT format |
--mesh-only (implies -i flag) | Run only the mesh related tasks and output the final mesh that would be used for the simulation |
--start-in-debugger <debugger> | Start the simulation attached to the supplied debugger |
The list of system-modes may not be extensive as the system is designed to be extendable to end-user applications. The complete list of command line options for applications can be obtained by running the executable with zero arguments. See the command line usage.
Physical Characteristics
The SALAMANDER application is software only with no associated physical media. See System Requirements for a description of the minimum required hardware necessary for running the SALAMANDER application.
Environmental Conditions
Not Applicable
System Security
MOOSE-based applications such as SALAMANDER have no requirements or special needs related to system-security. The software is designed to run completely in user-space with no elevated privileges required nor recommended.
Information Management
SALAMANDER as well as the core MOOSE framework in its entirety will be made publicly available on an appropriate repository hosting site. Day-to-day backups and security services will be provided by the hosting service. More information about backups of the public repository on INL-hosted services can be found on the following page: GitHub Backups
Polices and Regulations
MOOSE-based applications must comply with all export control restrictions.
System Life Cycle Sustainment
MOOSE-based development follows various agile methods. The system is continuously built and deployed in a piecemeal fashion since objects within the system are more or less independent. Every new object requires a test, which in turn requires an associated requirement and design description. The SALAMANDER development team follows the NQA-1 standards.
Packaging, Handling, Shipping and Transportation
No special requirements are needed for packaging or shipping any media containing the MOOSE and SALAMANDER source code. However, some MOOSE-based applications that use the SALAMANDER code may be export-controlled, in which case all export control restrictions must be adhered to when packaging and shipping media.
Verification
The regression test suite will employ several verification tests using comparison against known analytical solutions, the method of manufactured solutions, and convergence rate analysis.