Optimization Requirements Traceability Matrix

This template follows INL template TEM-214, "IT System Requirements Traceability Matrix."

commentnote

This document serves as an addendum to Framework Requirements Traceability Matrix and captures information for RTM specific to the Optimization module.

Introduction

Minimum 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.

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

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

System Purpose

The purpose of the MOOSE Optimization module is to control model parameters such that they minimize a defined objective. An example would be to search for material property values so that the solution matches experimental results. As such, the purpose of this module is not to provide physical model capabilities, which is typically the responsibility of other MOOSE modules and dependent applications.

System Scope

The MOOSE Optimization module utilizes several MOOSE systems to perform optimization on physics models. The design relies on a customized Executioner to drive the optimization algorithm. This Executioner calls a specific type of Reporter in the OptimizationReporter system, which defines the parameter space, objective, gradient, and Hessian functions necessary for the optimization methods. Along with calling this Reporter, the Executioner calls MultiApps and Transfers that are responsible for passing parameters to the physics model, running the model, and gathering the necessary data to compute the objective, gradient, and Hessian. Typically, one sub-application defines the underlying physics for the objective computation, another defines an adjoint version of the model for the gradient computation, and another defines a homogeneous version of the model for the matrix-free Hessian computation. All data from these applications is gathered in the optimization reporter, which is then sent to the optimization Executioner. The resulting output is the value of the optimized parameters and the solution of physics model with these parameters. The scope of the Optimization module includes, but is not limited to:

  • Inverse optimization

  • Shape optimization

  • Topology optimization

Assumptions and Dependencies

The Optimization module is developed using MOOSE and can itself be based on various MOOSE modules, as such the RTM for the Optimization module 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.

The changelog for all code residing in the MOOSE repository is located in the MOOSE RTM.

System Requirements Traceability

Functional Requirements

  • optimization: Controls
  • 11.1.1The system shall solve a scalar inverse coupling problem by using a Control to adjust a parameter with the secant method, driven by fixed-point iteration, so that a sub-app output matches a target function at each time step.

    Specification(s): secant

    Design: SecantInversionControl

    Issue(s): #33205

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 11.1.2The system shall, when the fixed-point iteration cannot converge within the maximum number of iterations and the time step cannot be reduced further, cut the time step and error out.

    Specification(s): secant_error_on_max_iteration

    Design: SecantInversionControl

    Issue(s): #33205

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 11.1.3The system shall, when the fixed-point iteration reaches the maximum number of iterations and accept-on-max is enabled, accept the best estimate and continue.

    Specification(s): secant_accept_on_max_iteration

    Design: SecantInversionControl

    Issue(s): #33205

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 11.1.4The system shall demonstrate that the secant-based inversion Control fails to converge within a fixed iteration budget on a nonlinear problem that the finite-difference Newton Control solves.

    Specification(s): secant_fails_on_nonlinear

    Design: SecantInversionControlNewtonInversionControl

    Issue(s): #33205

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 11.1.5The system shall solve a scalar inverse coupling problem using a finite-difference Newton Control driven by fixed-point iteration.

    Specification(s): newton_linear

    Design: NewtonInversionControl

    Issue(s): #33205

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 11.1.6The system shall solve a nonlinear scalar inverse problem, where the sub-app output depends nonlinearly on the parameter, using a finite-difference Newton Control.

    Specification(s): newton_nonlinear

    Design: NewtonInversionControl

    Issue(s): #33205

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 11.1.7The system shall generate a complete secant inverse-solve workflow (forward sub-app, transfers, postprocessors, convergence, and control) from a single SingleParameterInverseSolve block.

    Specification(s): action_secant

    Design: SingleParameterInverseSolveAction

    Issue(s): #33205

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 11.1.8The system shall generate a complete finite-difference Newton inverse-solve workflow from a single SingleParameterInverseSolve block with the method set to newton.

    Specification(s): action_newton

    Design: SingleParameterInverseSolveAction

    Issue(s): #33205

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 11.1.9The system shall, when the single-parameter inverse-solve block reaches the maximum number of fixed-point iterations and accept-on-max is enabled, accept the best estimate and continue without error.

    Specification(s): action_accept_on_max

    Design: SingleParameterInverseSolveAction

    Issue(s): #33205

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 11.1.10The system shall converge a single-parameter inverse solve using the absolute tolerance criterion when the relative tolerance is negligible.

    Specification(s): action_absolute_tolerance

    Design: SingleParameterInverseSolveAction

    Issue(s): #33205

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 11.1.11The system shall, when the Newton single-parameter inverse-solve block reaches the maximum number of fixed-point iterations on a perturbed iteration and accept-on-max is enabled, accept the last base estimate and continue without error.

    Specification(s): action_newton_accept_on_max

    Design: SingleParameterInverseSolveAction

    Issue(s): #33205

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 11.1.12The system shall report a helpful error, naming the convergence the user actually assigned, when the single-parameter inverse-solve block's generated convergence is not assigned to the executioner's multiapp_fixed_point_convergence.

    Specification(s): action_wrong_convergence

    Design: SingleParameterInverseSolveAction

    Issue(s): #33205

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 11.1.13The system shall report a helpful error, distinguishing MOOSE's own default convergence from a user-assigned one, when the single-parameter inverse-solve block's generated convergence is not assigned to the executioner's multiapp_fixed_point_convergence.

    Specification(s): action_missing_convergence

    Design: SingleParameterInverseSolveAction

    Issue(s): #33205

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • optimization: Outputs
  • 11.7.1The system shall be able to perform gradient based material parameter inversion for a single material property and output the iteration-wise exodus output for the adjoint problem.

    Specification(s): adjoint_grad_iteration_output

    Design: ExodusOptimizationSteady

    Issue(s): #25009

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 11.7.2The system shall be able to invert for point loads using gradient-based optimization with an automatically computed adjoint and output the exodus output per iteration for the combined forward and adjoint problem variables.

    Specification(s): auto_adjoint_iteration_output

    Design: ExodusOptimizationSteady

    Issue(s): #25009

    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.