SALAMANDER Requirements Traceability Matrix

This template follows Idaho National Laboratory (INL) template TEM-214, "IT System Requirements Traceability Matrix."

Introduction

Minimum System Requirements

In general, the following is required for MOOSE-based development:

A Portable Operating System Interface (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.

HardwareInformation
CPU Architecturex86_64, ARM (Apple Silicon)
Memory8 GB (16 GBs for debug compilation)
Disk Space30GB

LibrariesVersion / Information
GCC9.0.0 - 12.2.1
LLVM/Clang10.0.1 - 19
Intel (ICC/ICX)Not supported at this time
Python3.10 - 3.13
Python Packagespackaging pyaml jinja2

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 Multiphysics Object Oriented Simulation Environment (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.

Assumptions and Dependencies

The SALAMANDER application is developed using MOOSE and is based on various modules, as such the RTM for SALAMANDER is dependent upon the files listed at the beginning of this document.

Pre-test Instructions/Environment/Setup

Ideally all testing should be performed on a clean test machine following one of the supported configurations setup by the test system engineer. Testing may be performed on local workstations and cluster systems containing supported operating systems.

The repository should be clean prior to building and testing. When using "git" this can be done by doing a force clean in the main repository and each one of the submodules:


git clean -xfd
git submodule foreach 'git clean -xfd'

All tests must pass in accordance with the type of test being performed. This list can be found in the Software Test Plan.

Changelog Issue Revisions

Errors in changelog references can sometimes occur as a result of typos or conversion errors. If any need to be noted by the development team, they will be noted here.

Currently, no errors in issue references related to the changelog have been discovered.

System Requirements Traceability

Functional Requirements

  • salamander: Auxkernels
  • 1.1.1The system shall be able compute a component of the negative gradient of a variable.

    Specification(s): test

    Design: NegativeVariableGradientComponent

    Issue(s): #62

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • salamander: Kernels
  • 1.3.1The system shall be able to solve a simple diffusion problem.

    Specification(s): test

    Design: Diffusion

    Issue(s): #108

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • salamander: Raybcs
  • 1.4.1The system shall be capable of reflecting computational particles off of boundaries and maintain consistent velocity data
    1. in a 1D domain
    2. in a 2D domain
    3. in a 3D domain

    Specification(s): reflection/1d, reflection/2d, reflection/3d

    Design: ReflectParticleBC

    Issue(s): #39

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • salamander: Utils
  • 1.6.1The system shall support the accumulation of point values as if they were point sources into an auxiliary field

    Specification(s): test

    Design: AuxAccumulator

    Issue(s): #9

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.6.2The system shall report a reasonable error when accumulating point values into an auxiliary field when the system is not properly finalized

    Specification(s): error

    Design: AuxAccumulator

    Issue(s): #9

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 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

    Specification(s): charge_mapping

    Design: AuxAccumulator

    Issue(s): #9

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 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

    Specification(s): charge_mapping2D

    Design: AuxAccumulator

    Issue(s): #9

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 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

    Specification(s): simple_potential_solve_aux

    Design: AuxAccumulator

    Issue(s): #9

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.6.6The system shall support the accumulation of point values as if they were point sources into a nonlinear field

    Specification(s): test

    Design: ResidualAccumulator

    Issue(s): #16

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 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

    Specification(s): variable_sampling

    Design: VariableSampler

    Issue(s): #12

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

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 Interface Requirements

No requirements of this type exist for this application, beyond those of its dependencies.

References

No citations exist within this document.