Optimization Requirements Traceability Matrix
This template follows INL template TEM-214, "IT System Requirements Traceability Matrix."
This document serves as an addendum to Framework Requirements Traceability Matrix and captures information for Requirement Traceability Matrix (RTM) specific to the Optimization module.
Introduction
Minimum System Requirements
In general, the following is required for MOOSE-based development:
GCC/Clang C++17 compliant compiler (GCC @ 7.5.0, Clang @ 10.0.1 or greater)
Note: Intel compilers are not supported.
Memory: 8 GBs of RAM for optimized compilation (16 GBs for debug compilation), 2 GB per core execution
Processor: 64-bit x86 or ARM64 (specifically, Apple Silicon)
Disk: 30GB
A Portable Operating System Interface (POSIX) compliant Unix-like operating system, including the two most recent versions of MacOS and most current versions of Linux.
Git version control system
Python @ 3.7 or greater
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 known as a OptimizationReporter, 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 OptimizationReporter, 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.
System Requirements Traceability
Functional Requirements
- optimization: Dirackernels
- 11.1.1The system shall support point sources with locations, times, and values given by a vector values with
- forward time stepping;
- reverse time stepping;
Specification(s): vector_point_source/forward, vector_point_source/reverse
Design: ReporterTimePointSource
Issue(s): #22215
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- optimization: Executioners
- 11.2.1The system shall be able to debug a optimization solve by
- using finite-difference to compute the gradient;
- testing hand-coded gradient;
- indicating a failed line search;
- indicating maximum iteration reached;
Specification(s): debug/fd, debug/grad_check, debug/failed_ls, debug/failed_it
Design: Optimize
Issue(s): #21885
Collection(s): FUNCTIONAL
Type(s): RunApp
- 11.2.2The system shall by able to solve the adjoint version of steady-state problems that
- are self-adjoint,
- have non-homogeneous boundary conditions,
- have multiple coupled variables,
- use array variables, and
- have non-linear material properties.
Specification(s): steady_and_adjoint/self_adjoint, steady_and_adjoint/nonhomogeneous_bc, steady_and_adjoint/multi_variable, steady_and_adjoint/array_variable, steady_and_adjoint/nonlinear
Design: SteadyAndAdjoint
Issue(s): #23888
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 11.2.3The system shall be able to solve the adjoint version of transient problems that
- are self-adjoint,
- have multiple coupled variables,
- have non-linear steady-state material properties, and
- have non-uniform time stepping.
Specification(s): transient_and_adjoint/self_adjoint, transient_and_adjoint/multi_variable, transient_and_adjoint/nonlinear, transient_and_adjoint/nonuniform_tstep
Design: TransientAndAdjoint
Issue(s): #23888
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- optimization: Functions
- 11.3.1The system shall be able to compute an auxiliary variable based on data from reporter values with
- x-coordinate data;
- x- and y-coordinate data;
- x-, y-, and z-coordinate data;
- time, x-, y-, and z-coordinate data;
Specification(s): nearest_point/x, nearest_point/xy, nearest_point/xyz, nearest_point/xyzt
Design: NearestReporterCoordinatesFunction
Issue(s): #22215
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 11.3.2The system shall error if
- the size of value vector is wrong;
- x-coordinate data is wrong size;
- y-coordinate data is wrong size;
- z-coordinate data is wrong size;
- time data is wrong size;
Specification(s): error/v, error/x, error/y, error/z, error/t
Design: NearestReporterCoordinatesFunction
Issue(s): #22215
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 11.3.3The system shall be able to evaluate a mesh-based interpolation function by
- creating first-order mesh and
- evaluating the first-order parameter values;
- creating second-order mesh and
- evaluating the second-order parameter values;
- creating piece-wise constant mesh and
- evaluating the piece-wise constant parameter values;
- evaluating transient parameter values;
Specification(s): parameter_mesh/create, parameter_mesh/evaluate, parameter_mesh/create_second, parameter_mesh/evaluate_second, parameter_mesh/create_dg, parameter_mesh/evaluate_dg, parameter_mesh/evaluate_transient
Design: ParameterMeshFunction
Issue(s): #22995
Collection(s): FUNCTIONAL
Type(s): CheckFilesExodiff
- 11.3.4The system shall support parsed function expressions with parameter values by
- computing parameter gradient;
- erroring if vector is incorrect size;
Specification(s): parsed_function/compute_gradient, parsed_function/wrong_vector_size
Design: ParsedOptimizationFunction
Issue(s): #21885
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunExceptionCSVDiff
- optimization: Optimizationreporter
- 11.4.1The system shall be able to scale linear and constant functions involved in two separate Neumann boundary conditions both applied to the same sideset using two parsed functions and the scale of the linear and constant functions are both being parameterized using
- a matrix-free Hessian approach or
- automatic adjoint evaluation.
Specification(s): bc_linear_load/iterOutput, bc_linear_load/auto_adjoint
Design: OptimizeParsedOptimizationFunctionSideOptimizationNeumannFunctionInnerProduct
Issue(s): #21885
Collection(s): FUNCTIONAL
Type(s): CSVDiffExodiff
- 11.4.2The system shall be able to invert for the value of a material property in two separate regions using
- a gradient evaluated in a separate multiapp or
- a gradient evaluated with an automatically computed adjoint.
Specification(s): bimaterial/taoblmvm, bimaterial/auto_adjoint
Design: OptimizeNearestReporterCoordinatesFunctionElementOptimizationDiffusionCoefFunctionInnerProduct
Issue(s): #21885
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 11.4.3The system shall be able to optimize the magnitude of a source for a
- linear diffusion problem;
- diffusion problem with nonlinear coefficient;
Specification(s): constant_heat_source/linear, constant_heat_source/nonlinear
Design: OptimizeElementOptimizationSourceFunctionInnerProduct
Issue(s): #21885
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 11.4.4The system shall be able to perform gradient based material parameter inversion for a single material property.
Specification(s): adjoint_grad
Design: ElementOptimizationDiffusionCoefFunctionInnerProduct
Issue(s): #21885
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 11.4.5The system shall be able to perform inverse optimization on a source that is represented by a mesh by
- creating the source mesh;
- performing the inverse optimization with a piece-wise source;
- performing the inverse optimization with a linearly varying source;
- performing the inverse optimization with a quadratically varying source;
- performing the inverse optimization with bounds;
- performing the inverse optimization with an automatically computed adjoint;
- creating a mesh with initial conditions;
- performing the inverse optimization with exact solution initial conditions that will make it converge in a single step;
Specification(s): mesh_source/mesh, mesh_source/constant, mesh_source/linear, mesh_source/second, mesh_source/bounded, mesh_source/auto_adjoint, mesh_source/restartMesh, mesh_source/linearRestart
Design: ParameterMeshOptimizationParameterMeshFunction
Issue(s): #22995
Collection(s): FUNCTIONAL
Type(s): ExodiffCheckFilesCSVDiff
- 11.4.6The system shall throw an error when performing inverse optimization on mesh-based parameters if there is a mismatch between the number of parameters and the number of
- meshes;
- finite-element families;
- finite-element orders;
- initial conditions;
- lower bounds;
- upper bounds;
Specification(s): mismatch_errors/meshes, mismatch_errors/family, mismatch_errors/order, mismatch_errors/initial_condition, mismatch_errors/lower_bound, mismatch_errors/upper_bound
Design: ParameterMeshOptimizationParameterMeshFunction
Issue(s): #22995
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 11.4.7The system shall throw an error when performing inverse optimization on mesh-based parameters if the parameter function spaces do not match the space defined in the
- forward problem;
- adjoint problem;
Specification(s): interpolation_errors/forward, interpolation_errors/adjoint
Design: ParameterMeshOptimizationParameterMeshFunction
Issue(s): #22995
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
Prerequisite(s): 11.4.5
- 11.4.8The system shall be able perform inverse source optimization on a problem with nonlinear material properties using automatically computed adjoint.
Specification(s): nonlinear_material
Design: OptimizeOptimizationReporter
Issue(s): #23888
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 11.4.9The system shall correctly read in parameter data defined in the input file
- measurement data from the input file;
- with lower bounds, upper bounds and initial conditions provided for every parameter and measurement data from a CSV file;
- with lower bounds, upper bounds and initial conditions constant for each group and measurement data from a CSV file;
- with lower bounds, upper bounds and initial conditions are a mix of constant per group and every parameter in a group and measurement data from a CSV file;
- and error if parameters are provided but do not include a parameter for every group;
- and error if an incorrect number of parameters are provided for a group;
Specification(s): optimizationReporter/input, optimizationReporter/csv_paramBounds, optimizationReporter/csv_groupBounds, optimizationReporter/csv_mixBounds, optimizationReporter/missing_group_params, optimizationReporter/too_many_params
Design: OptimizationReporter
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): JSONDiffRunException
- 11.4.10The system shall be able to read variable weights and use them to scale the misfit.
Specification(s): readData
Design: OptimizationData
Issue(s): #24333
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 11.4.11The system shall correctly read in one parameter group defined on the mesh
- by first creating the parameter mesh containing the data;
- with initial conditions, upper and lower bounds defined on the mesh for all timesteps;
- with initial conditions, upper and lower bounds defined in input file;
- with initial conditions and lower bound read from input file and upper bound read from the last timestep in the mesh.
Specification(s): oneParameterGroup/mesh, oneParameterGroup/allMeshParams, oneParameterGroup/allInputParams, oneParameterGroup/mixedParams
Design: ParameterMeshOptimization
Issue(s): #24034
Collection(s): FUNCTIONAL
Type(s): RunAppJSONDiffCheckFiles
- 11.4.12The system shall correctly read in two groups of parameter data defined on the mesh
- for initial conditions, upper and lower bounds defined on the mesh for all timesteps;
- for initial conditions, upper and lower bounds defined in input file;
- for initial conditions and lower bound read from input file and upper bound read from the last timestep in the mesh;
- for the first group being first order Lagrange and second group being second order Lagrange nodal variables.
Specification(s): twoParameterGroup/allMeshTwoParams, twoParameterGroup/allInputTwoParams, twoParameterGroup/mixedTwoParams, twoParameterGroup/twoParamsHO
Design: ParameterMeshOptimization
Issue(s): #24034
Collection(s): FUNCTIONAL
Type(s): RunAppJSONDiff
Prerequisite(s): 11.4.11
- 11.4.13The system shall throw an error when parameter data is incorrectly defined
- by having input and mesh parameters for the same bound;
- by having a parameter not on the exodus mesh;
- by using nodal and elemental exodus variables to define parameter data in the same parameter group;
- by not having the same number of optimization timesteps and timesteps for reading parameter data from the mesh;
- by specifying a timestep for reading parameter data from the exodus file but not parameter data is being read from the mesh because it is all specified in the input file;
- by specifying a timestep that is bigger than the timestpes on the exodus the exodus mesh.
Specification(s): errors/errorMixedParams, errors/errorMissingMeshParam, errors/errorMixedParameterTypes, errors/errorMismatchSteps, errors/errorNoSteps, errors/errorBadStep
Design: ParameterMeshOptimization
Issue(s): #24034
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 11.4.14The system shall be able to invert for point loads using
- Hessian-based optimization,
- gradient-based optimization, or
- gradient-based optimization with an automatically computed adjoint.
Specification(s): point_loads/hessian, point_loads/adjoint, point_loads/auto_adjoint
Design: ReporterPointSource
Issue(s): #21885
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- optimization: Userobjects
- 11.5.1The system shall be able to load a time-dependent solution from an exodus file while reversing the timesteps by
- producing the exodus file;
- loading on to the same mesh;
- loading on to a coarser mesh;
- interpolating different time steps;
- erroring if file is not exodus;
Specification(s): adjoint_solution/forward, adjoint_solution/reverse, adjoint_solution/reverse_space_interp, adjoint_solution/reverse_time_interp, adjoint_solution/error_file_format
Design: AdjointSolutionUserObject
Issue(s): #22215
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunAppRunExceptionCheckFiles
- optimization: Vectorpostprocessors
- 11.6.1The system shall be able to compute the inner product of a variable and a nearest node optimization volumetric source function.
Specification(s): vector_nearest_point
Design: ElementOptimizationSourceFunctionInnerProduct
Issue(s): #22215
Collection(s): FUNCTIONAL
Type(s): CSVDiff