Stochastic Tools System Requirements Specification

System Purpose

The purpose of the MOOSE Stochastic Tools module includes, but is not limited to:

• Providing a MOOSE-like interface for performing stochastic analysis on MOOSE-based models.

• Sampling model parameters, running applications, and gathering data of interest that is both efficient (memory and runtime) and scalable.

• Performing uncertainty quantification and sensitivity analysis with distributed data.

• Training meta-models to develop fast-evaluation surrogates of the high-fidelity multiphysics model.

• Providing a pluggable interface for these surrogates.

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, but to provide data creation and processing capabilities in stochastic analysis.

System Scope

The MOOSE Stochastic Tools module builds on the existing framework MultiApps system and provides several additional systems to address its purpose. To address the efficient evaluation of multiphysics models, the MultiApps system is extended to include a "batch" mode of execution. This mode provides a memory efficient way of building MooseApp instances and reusing them for different perturbations of input parameters. This is useful for stochastic simulations with many, many samples to be run without holding them in memory or re-initializing potentially costly data allocation. The additional systems that the Stochastic Tools module provides include: Distributions, Samplers, Trainers, and Surrogates. Distributions are functions defining the uncertainty of input parameters and provides an interface for computing probability density, cumulative probability, and quantiles. Samplers define the sampling scheme of the stochastic analysis, whether it be random or deterministic. Trainers are objects that build meta-models meant to be used as surrogates or reduced-order models of the multiphysics model. The resulting reduced model is able to be saved in a meta-data file and reloaded for future use. Surrogates take the data created from a Trainer and provide functionality to evaluate the model. The module also provides capabilities for computing quantities related to basic uncertainty quantification and sensitivity analysis using the framework's Reporters system.

System Context

The Stochastic Tools module 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. The Stochastic Tools module 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 the Stochastic Tools module and other MOOSE-based applications.

System Functions

Since the Stochastic Tools module 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. The Stochastic Tools module is completely extendable so individual design pages should be consulted for specific behaviors of each user-defined object.

User Characteristics

Like MOOSE, there are three kinds of users working on the Stochastic Tools module:

• Stochastic Tools module Developers: These are the core developers of the Stochastic Tools module. They are responsible for following and enforcing the software development standards of the module, as well as designing, implementing, and maintaining the software.

• Developers: A scientist or engineer that uses the Stochastic Tools module alongside MOOSE to build their own application. This user will typically have a background in modeling or simulation techniques (and perhaps numerical analysis) but may only have a limited skillset when it comes to code development using the C++ language. This is the primary focus group of the module. In many cases, these developers will be encouraged to contribute module-appropriate code back to the Stochastic Tools module, or to MOOSE itself.

• Analysts: These are users that will run the code and perform analysis on the simulations they perform. These users may interact with developers of the system requesting new features and reporting bugs found and will typically make heavy use of the input file format.

Assumptions and Dependencies

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

The Stochastic Tools module is designed with the fewest possible constraints on hardware and software. For more context on this point, the Stochastic Tools module SRS defers to the framework Assumptions and Dependencies. Any physics-based or mathematics-based assumptions in code simulations and code objects are highlighted in their respective documentation pages.

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

Functional Requirements

• stochastic_tools: Actions
• 19.1.1The system shall be able to setup a simple parameter study with the following sampling schemes
  1. Monte Carlo;
  2. latin hypercube;
  3. cartesian product;
  4. CSV;
  5. CSV when specifiying column indices;
  6. CSV when specifiying column names;
  7. input matrix;
• 19.1.2The system shall throw an error if the following sampler parameters are missing or unused when doing a simple parameter study
  1. 'num_samples' parameter for Monte Carlo sampling;
  2. 'distributions' parameter for Monte Carlo sampling;
  3. 'linear_space_items' parameter with Monte Carlo sampling;
  4. 'num_samples' parameter for latin hypercube sampling;
  5. 'distributions' parameter for latin hypercube sampling;
  6. 'linear_space_items' parameter for cartesian product sampling;
  7. 'samples_file' parameter for CSV sampling;
  8. both 'csv_column_indices' and 'csv_column_names' parameters are specified for CSV sampling;
  9. 'matrix' parameter for input matrix sampling;
• 19.1.3The system shall be able to setup a Monte Carlo parameter study with uniform, normal, Weibull, lognormal, and truncated normal distributions.
• 19.1.4The system shall throw an error when doing a simple parameter study if distribution parameters are
  1. missing;
  2. inconsitent size;
  3. unused;
• 19.1.5The system shall be able to setup a simple parameter study with ability to
  1. compute statistics;
  2. not compute statistics;
  3. error if there are unused statistics parameters;
• 19.1.6The system shall be able to output the results of a simple parameter study with
  1. no output;
  2. CSV output;
  3. JSON output;
• 19.1.7The system shall be able to run a simple parameter study in the following modes
  1. one sub-app per sample;
  2. batches with one sub-app per processor while re-initializing;
  3. batches one sub-app per processor while restoring;
  4. batches one sub-app per processor while restoring and keeping solution;
  5. batches one sub-app per processor without restoring;
• 19.1.8The system shall be able to build a simple parameter study with an optimized execution mode by determining that
  1. parameters are parsed;
  2. parameters are not controllable;
  3. parameters are controllable in a transient problem;
  4. parameters are controllable in a pseudo-transient problem;
  5. parameters are controllable in a steady-state problem;
  6. parameters are controllable in a eigenvalue problem;

• stochastic_tools: Auxkernels
• 19.2.1The system shall be able to create a surrogate that can be read in by file and use in aux kernels.
• 19.2.2The system shall be able to assign the values of an auxiliary variable with the evaluation of a surrogate model for
  1. standard field variables and
  2. array field variables.
• 19.2.3The system shall throw an error when evaluating a surrogate for auxiliary variable assignment if
  1. a parameter is undefined,
  2. a scalar parameter is not found, or
  3. a coupled array variable does not match the number of components.
• 19.2.4The system shall be able to evaluate a surrogate at given scalar variable values and insert the result into a scalar variable
• 19.2.5The system shall be able to evaluate a surrogate at given postprocessor values and insert the result into a scalar variable

• stochastic_tools: Controls
• 19.3.1The system shall be able to read a neural network from a parameter file and use it to control a transient process.
• 19.3.2The system shall be able to run with a DRL controller without having a neural net initialized in it.

• stochastic_tools: Distributions
• 19.4.1The system shall provide distribution function including
  1. uniform,
  2. Weibull (3 parameter),
  3. Kernel Density 1D with a Gaussian kernel and data file as input,
  4. Kernel Density 1D with a Uniform kernel and data file as input,
  5. Kernel Density 1D with a Gaussian kernel and data vector as input,
  6. Kernel Density 1D with a Gaussian kernel and user defined bandwidth,
  7. Kernel Density 1D with a Gaussian kernel and standard deviation as bandwidth,
  8. normal,
  9. truncated normal,
  10. lognormal,
  11. gamma,
  12. beta,
  13. F,
  14. student t,
  15. Johnson Special Bounded (SB), and
  16. logistic distributions.
• 19.4.2The system shall provide a normal distribution with the ability to directly call methods with distribution inputs.
• 19.4.3The system shall produce an error if a distribution is retrieved with the differing type than supplied.

• stochastic_tools: Functions
• 19.5.1The system shall be able to evaluate a linear DRL reward function with a given, time-dependent target.

• stochastic_tools: Ics
• 19.6.1The system shall generate parallel agnostic random initial conditions using a distribution function.
• 19.6.2The system shall generate an error the random initial condition is used with both a distribution and min or max value defined.

• stochastic_tools: Likelihoods
• 19.7.1The system shall be be able to calculate the likelihood values when
  1. using a Gaussian type with log-likelihoods requested and model/experiment values are scalars;
  2. using a Gaussian type with likelihoods requested and model/experiment values are scalars;
  3. using a truncated Gaussian type with likelihoods requested and model/experiment values are scalars.
  4. using a Extreme Value type with likelihoods requested and model/experiment values are scalars.
• 19.7.2The system shall throw an error when
  1. the specified lower bound is greater than the upper bound;

• stochastic_tools: Multiapps
• 19.8.1The system shall be able to set command line parameter(s) for sub-application that executes completely from a sample distribution for
  1. for a single parameter,
  2. for a single parameter for a batch of sub-applications,
  3. for multiple parameters, and
  4. for vector parameters for a batch of sub-applications,
  5. for multiple parameters for a batch of sub-applications.
  6. for multiple parameters using their global column indexes for a batch of sub-applications.
• 19.8.2The system shall report an error when the supplied sampler object operates in a mode that does not allow for command line arguments to be modified.
• 19.8.3The system shall report an error when the supplied sampler does not use the correct execution flags.
• 19.8.4The system shall report an error when '[]' syntax is not used for all parameters.
• 19.8.5The system shall report an error when provided global column index is out of bound.
• 19.8.6The system shall support pulling postprocessor data from a sub-application for each row of sampled data.
• 19.8.7The system shall support running sub-applications in batches.
• 19.8.8The stochastic tools module shall support pulling postprocessor data from a single sub-application running a batch of sampled data
  1. on a single processor,
  2. on multiple processors, and
  3. on multiple processors using in-memory backup.
• 19.8.9The system shall support running sub-applications with input parameters varying at each time step
  1. with individual sub-applications,
  2. with sub-applications batches using in-memory restore functionality.
• 19.8.10The SamplerTransientMultiApp object shall error if the 'batch-reset' mode is supplied.
• 19.8.11The system shall support outputting results from sub-applications with input parameters varying at each time step using
  1. individual sub-applications;
  2. sub-application batches;
• 19.8.12The system shall be able to set a sub-application command line parameters from a sample distribution
  1. for a single parameter and
  2. for a multiple parameters.
• 19.8.13The system shall report an error when sub-apps are constructed too early thus unable to be changed by samplers.
• 19.8.14The system shall report an error when the number of samples differs from the number of command line parameters.
• 19.8.15The system shall be able to control whether a sub-app is run for a certain sample
  1. with a parsed function dependent on time and sampler values;
  2. error if running in normal mode.
• 19.8.16The system shall support the modification of the number of complete sub-application simulations performed with
  1. normal execution,
  2. batch execution with memory-based restoring, and
  3. batch execution with reset-based restoring.
• 19.8.17The system shall report an error when the size of a sampler is altered an sub-applications are progressing with time with the main application.
• 19.8.18The system shall be able to apply command line parameter(s) to nested sub-applications in
  1. normal multiapp mode;
  2. batch multiapp mode;
• 19.8.19The system shall be able to transfer parameter(s) to nested sub-applications in
  1. normal multiapp mode;
  2. batch-reset multiapp mode;
  3. batch-restore multiapp mode;
• 19.8.20The system shall be able to output results from nested sub-applications in stochastic simulations using
  1. normal multiapp mode;
  2. batch-reset multiapp mode;
  3. batch-restore multiapp mode;
• 19.8.21The system shall have consistent partitioning between multiapps and sampler for full solves
  1. with less processors than rows in normal mode;
  2. with more processors than rows in normal mode;
  3. with specified minimum processors per app in normal mode;
  4. with less processors than rows in batch-reset mode;
  5. with more processors than rows in batch-reset mode;
  6. with specified minimum processors per app in batch-reset mode;
  7. with less processors than rows in batch-restore mode;
  8. with more processors than rows in batch-restore mode;
  9. with specified minimum processors per app in batch-restore mode;
  10. error when partitionings do not match;
• 19.8.22The system shall have consistent partitioning between multiapps and sampler for transient solves
  1. with less processors than rows in normal mode;
  2. with more processors than rows in normal mode;
  3. with specified minimum processors per app in normal mode;
  4. with less processors than rows in batch-restore mode;
  5. with more processors than rows in batch-restore mode;
  6. with specified minimum processors per app in batch-restore mode;
  7. error when partitionings do not match;
• 19.8.23The system shall provide the ability to create a full-solve type sub-application from sampled data from distributions.
• 19.8.24The system shall provide the ability to create a transient sub-application from the sample data generated from distributions.
• 19.8.25The system shall provide the ability to set a transient sub-application command line parameters from a sample distribution.
• 19.8.26The system shall support performing complete solves within a sub-application that include perturbed inputs that yield repeatable results
  1. using normal operation;
  2. using in memory backup operation;
  3. using reset operation.
• 19.8.27The system shall support performing complete solves within a sub-application that include perturbed inputs that yield changing results
  1. using normal operation;
  2. using in memory backup operation;
  3. using reset operation.
• 19.8.28The system shall be able to perform stochastic simulations of steady-state models while obeying unperturbed command line arguements with:
  1. command line control in normal mode;
  2. command line control in batch mode;
  3. parameter transfer in normal mode;
  4. parameter transfer in batch-reset mode;
  5. parameter transfer in batch-restore mode;
• 19.8.29The system shall be able to perform stochastic simulations of transient models while obeying unperturbed command line arguements with:
  1. command line control;
  2. parameter transfer in normal mode;
  3. parameter transfer in batch mode;

• stochastic_tools: Reporters
• 19.9.1The system shall be able to perform importance sampling with active learning while
  1. using the U learning function.
• 19.9.2The system shall be able to perform Monte Carlo sampling with active learning with
  1. a single row in the sampler using the U learning function;
  2. multiple rows in the sampler using the U learning function and automatically increase the number of steps when re-training is needed;
  3. a single row in the sampler using the U learning function and automatically increase the number of steps when re-training is needed;
  4. a single row in the sampler using the COV learning function and automatically increase the number of steps when re-training is needed;
  5. TAO optimization and automatically increase the number of steps when re-training is needed;
• 19.9.3The system shall throw an error when performing active learning when
  1. mini-batching is requested with the TAO optimization library;
• 19.9.4The system shall be able to perform Monte Carlo sampling with bi-fidelity active learning with
  1. a single row in the sampler using the U learning function;
  2. multiple rows in the sampler using the U learning function;
• 19.9.5The system shall support the calculation of statistics using
  1. vectors of data from the postprocessing system and include
  2. confidence level intervals for statistics calculations.
• 19.9.6The system shall support the calculation of statistics using
  1. vector of data from the reporting system; including
  2. confidence level intervals for statistics calculations
  3. and error if the supplied type is not supported.
• 19.9.7The system shall support computing bias corrected and accelerated confidence level intervals of statistics
  1. of a vector of data
  2. of a vector of vector data
  3. using data that is replicated and
  4. using data that is distributed.
• 19.9.8The system shall report an error when computing confidence level intervals when
  1. the confidence level intervals are omitted;
  2. the confidence level intervals are less than or equal to zero;
  3. the confidence level intervals are greater than or equal to one;
  4. input is not provided.
• 19.9.9The system shall support computing percentile confidence level intervals of statistics
  1. of a vector of data
  2. of a vector of vector data
  3. using data that is replicated or
  4. distributed across processors.
• 19.9.10The system should be able to map the solutions in a snapshot container into a latent space.
• 19.9.11The system should be able to extract and map variables in nonlinear system into a latent (low-dimensional) space.
• 19.9.12The system shall support the ability to compute Morris sensitivity values with
  1. distributed data;
  2. replicated data;
• 19.9.13The system shall support the ability to compute Morris sensitivity values for vector-type data that is
  1. distributed;
  2. on root processor;
• 19.9.14The system should be able to print serialized snapshots in a distributed fashion in a json format.
• 19.9.15The system shall support the ability to compute first, second, and total-effect Sobol sensitivity indices with a reporter.
• 19.9.16The system shall support the ability to compute Sobol sensitivity indices for vector-type data.
• 19.9.17The system shall be capable of computing the statistics of a data vector that
  1. is replicated and
  2. distributed.
• 19.9.18The system shall be capable of computing the statistics from vector reporter values.
• 19.9.19The system shall be able to ouptut samples from a sampler with
  1. serialized output;
  2. distributed output;
  3. specified column names;
• 19.9.20The system shall be able to output samples from a sampler along side stochastic simulation results.
• 19.9.21The system shall throw an error when attempting to output samples from a sampler when
  1. inputting the wrong number of column names;
  2. using a different sampler than the transfer's;
• 19.9.22The system shall support the ability to use transferred reporter data to
  1. compute statistics.

• stochastic_tools: Samplers
• 19.10.1The system shall include an Adaptive Importance Sampling method for sampling distribution data.
• 19.10.2The system shall throw an error when
  1. the selected sampler type is not of an adaptive type when performing adaptive decision;
• 19.10.3The system shall include an Parallel Subset Simulation method for sampling distribution data.
• 19.10.4The system shall throw an error when
  1. the selected sampler type is not of an adaptive type.
• 19.10.5The system shall include the ability to create a 1D Cartesian sampling scheme.
• 19.10.6The system shall throw an error when performing 1D Cartesian sampling if
  1. the specified grid does not form a triplet,
  2. the number of nominal values specified does not match the number of sample columns,
  3. the number of grid points is not an integer, or
  4. the number of grid points is negative.
• 19.10.7The system shall include the ability to create a Cartesian product sampling scheme.
• 19.10.8The CSV Sampler shall read samples from a CSV file while the sample data is
  1. distributed across processors,
  2. replicated across processors, and
  3. distributed across processors with the output also distributed.
• 19.10.9The CSV Sampler shall sample from a CSV file when column indices are provided.
• 19.10.10The CSV Sampler shall sample from a CSV file when column names are provided.
• 19.10.11The system shall support generating random samples of data
  1. that remain constant in size and
  2. that are dynamic in size.
• 19.10.12The system shall support the creation of data sampled from distribution during the initial setup of a simulation.
• 19.10.13The system shall be able to sample an input-defined matrix.
• 19.10.14The system shall support the ability to sample data using the Latin Hypercube method that can operate
  1. using global matrix,
  2. a local matrix,
  3. or row-by-row.
• 19.10.15The system shall support the ability to sample data using the Latin Hypercube method with more processors than rows that can operate
  1. using global matrix,
  2. a local matrix,
  3. or row-by-row.
• 19.10.16The system shall include a utility that visually displays results of plotting Latin Hypercube test.
• 19.10.17The system shall be be able to perform MCMC sampling when
  1. using the base MCMC class;
  2. using the base MCMC class with bounds specified;
  3. using the independent Metropolis-Hastings class;
  4. using the differential evolution sampler class;
  5. using the stretch sampler class;
  6. using the differential evolution sampler class with variance inferred;
• 19.10.18The system shall throw an error when
  1. only the lower bounds specified;
  2. the specified bounds are not of the same size;
  3. the priors, bounds, and initial values are not of the same size;
  4. the proposal stds, initial values, and priors are not of the same size;
  5. the number of scales provided do not match the number of tunable params;
• 19.10.19The system shall include a Monte Carlo method for sampling distribution data including
  1. a uniform distribution distributed across processors,
  2. a uniform distribution replicated across processors,
  3. a uniform distribution distributed across processors (output is also distributed),
  4. a Wiebull distribution distributed across processors, and
  5. a Weibull distribution replicated across processors.
• 19.10.20The system shall include a Morris trajectory method for sampling distribution data:
  1. with replicated output;
  2. with parallel output;
  3. with more processors than trajectories;
• 19.10.21The system shall include a nested Monte Carlo sampling scheme where sets of distributions are sampled as nested loops of rows
  1. in serial;
  2. in parallel;
• 19.10.22The system shall report an error when the number of nested Monte Carlo loops does not match the number of sets of distributions.
• 19.10.23The system shall include a SOBOL method for sampling distribution data:
  1. with the re-sampling matrix and
  2. without the re-sampling matrix.
• 19.10.24The system shall report an error if the SOBOL sampling method is setup with input sampling matrices
  1. with differing number of rows;
  2. with differing number of columns; and
  3. if the matrices are the same.
• 19.10.25The system shall be able to perform stochastic sampling based on global vector data.

• stochastic_tools: Surrogates
• 19.11.1The system shall demonstrate cross validation
  1. for a 1-dimensional polynomial regression surrogate with Real
  2. and std::vector<Real> response types.
  3. and throw an error if a SurrogateModel is not provided.
• 19.11.2The system shall demonstrate a gaussian process surrogate by
  1. training a Gaussian process model and
  2. evaluating the trained Gaussian process model
• 19.11.3The system shall be able to produce a Gaussian process surrogate with
  1. a squared exponential kernel;
  2. an exponential kernel;
  3. Matern half integer kernel;
• 19.11.4The system shall be be able to tune hyperparameters of a Gaussian process surrogate with
  1. a squared exponential kernel using TAO;
  2. an exponential kernel using TAO;
  3. a Matern half integer kernel using TAO;
  4. a squared exponential kernel using Adam;
  5. an exponential kernel using Adam;
  6. a Matern half integer kernel using Adam;
  7. a Matern half integer kernel using Adam with mini-batch sampling;
• 19.11.5The system shall throw an error when
  1. the no optimization is selected while parameter tuning is required.
  2. mini-batching is requested with the TAO optimization library.
  3. the batch size is greater than the training data set size for Adam optimization.
• 19.11.6The system shall be able to train and evaluate a libtorch-based neural network in the same input file.
• 19.11.7The system shall be able to train a libtorch-based neural network.
• 19.11.8The system shall be able to evaluate a previously trained, libtorch-based neural network.
• 19.11.9The system shall be able to retrain a pretrained and saved libtorch-based neural network.
• 19.11.10The system shall be able to train a libtorch-based neural network using a relative tolerance instead of fixed epoch number.
• 19.11.11The system shall be able to train a libtorch-based neural network with standardized input and output parameters.
• 19.11.12The system shall be able to evaluate a previously trained, libtorch-based neural network with standardized input and output parameters.
• 19.11.13The system shall support the creation of surrogate models that can be
  1. trained with replicated stochastic data and
  2. evaluated separately (with replicated data);
  3. trained with distributed stochastic data and
  4. evaluated separately (with distributed data);
  5. trained with distributed stochastic data;
  6. evaluated separately with a different number of processors;
  7. and be trained and evaluated in memory with a single input file.
• 19.11.14The system shall create a surrogate that evaluates the closes point from training data by
  1. training then
  2. evaluating,
  3. training and loading, and
  4. using explictly specified predictors.
• 19.11.15The system shall be able to create nearest point surrogates with vector-type response.
• 19.11.16The system shall demonstrate a POD-RB surrogate (with Dirichlet BC) by
  1. training using known 4D data
  2. and then evaluating new samples separately for new data.
• 19.11.17PODFullSolveMultiapp shall throw an error when
  1. the trainer object cannot be found.
  2. the trainer is run with more than one processors per subapp.
  3. the number of samples is lower than the number of processors.
• 19.11.18PODSamplerSolutionTransfer shall throw an error when
  1. the trainer object cannot be found.
• 19.11.19PODReducedBasisTrainer shall throw an error when
  1. the variable names cannot be found on sub-applications,
  2. the number of energy limits and variable names do not match,
  3. the number of tag names and tag types do not match,
  4. the Dirichlet tag types do not exist,
  5. and the residual generation is called before having the basis vectors.
• 19.11.20PODReducedBasisSurrogate shall throw an error when
  1. the number of inputs in 'change_rank' and 'new_ranks' is not the same.
• 19.11.21The system shall demonstrate a POD-RB surrogate (without Dirichlet BC) by
  1. training using known 3D data,
  2. saving the eigenvalues,
  3. then evaluating new samples separately for new data,
  4. and doing both together in one input file.
• 19.11.22The system shall compute polynomial chaos coefficents using
  1. MonteCarlo sampler with Uniform distribution,
  2. MonteCarlo sampler with Uniform distribution using least-squares regression,
  3. MonteCarlo sampler with Uniform distribution using Ridge regression,
  4. Quadrature sampler with Uniform distribution, and
  5. Quadrature sampler with Normal distribution.
• 19.11.23The system shall compute relevant statistics with polynomial chaos expansion including
  1. statistical moments with Legendre polynomials,
  2. statistical moments with Hermite polynomials,
  3. sampler and user defined local sensitivities with Legendre polynomials,
  4. sampler and user defined local sensitivities with Hermite polynomials, and
  5. Sobol sensitivity indices.
• 19.11.24The system shall include the ability to use sparse grid methods to evaluate polynomial chaos expansion coefficients including
  1. Smolyak and
  2. Clenshaw-Curtis methods.
• 19.11.25The system shall throw an error when
  1. the number of samples does not match the number of results.
• 19.11.26The system shall demonstrate a polnomial regression surrogate by
  1. training using known 3D data
  2. and then evaluating new samples separately for the same data
  3. and then doing both on another 1D case.
• 19.11.27The system shall be able to create polynomial regression surrogate with vector-type response.

• stochastic_tools: Transfers
• 19.12.1The system shall include the ability to modify parameters for sub-applications using values from a distribution
  1. on a single processor,
  2. on multiple processors,
  3. and on more processors than samples.
• 19.12.2The system shall include the ability to modify parameters for sub-applications executed in batches using values from a distribution
  1. on a single processor,
  2. on multiple processors, and
  3. on multiple processors using in-memory sub-application restore.
• 19.12.3The system shall include the ability to transfer stochastic results for two sub apps.
• 19.12.4The 'StochasticToolsTransfer object shall error if the 'execute_on' parameter is defined when the corresponding MultiApp object is running in batch mode.
• 19.12.5The 'StochasticToolsTransfer' object shall error if the 'execute_on' parameter does not match the corresponding MultiApp object is running in normal mode.
• 19.12.6The system shall report a reasonable error if parameters for a trasnfer between multiapps are provided to stochastics transfer, which do not support this currently
• 19.12.7The system shall be able to transfer an artificial neural network between a trainer object and a control object residing on different apps.
• 19.12.8The system shall support the creation of a sub-application for each row of the stochastic data.
• 19.12.9The system shall produce an error if neither a 'SamplerTransientMultiApp' nor SamplerFullSolveMultiApp is provided in SamplerPostprocessorTransfer.
• 19.12.10The system shall produce an error if the 'result' object in 'SamplerPostprocessorTransfer' is not a 'StochasticResults object'.
• 19.12.11The system shall support the ability to transfer a single value from each sub-application for a set of stochastic data.
• 19.12.12The system shall report an error if the supplied name is invalid when attempting to transfer a single value from a sub-application.
• 19.12.13When sub-application solve does not converge, the system shall either
  1. abort run,
  2. transfer last computed postprocessor value,
  3. or transfer NaN.
• 19.12.14The system shall support the ability to transfer reporter data from each sub-application for a set of stochastic data
  1. in normal mode,
  2. in batch mode,
  3. with distributed output,
  4. with more processors than samples,
  5. and error if transferring unsupported type.
• 19.12.15The system shall produce an error if neither a 'SamplerTransientMultiApp' nor SamplerFullSolveMultiApp is provided in SamplerParameterTransfer.
• 19.12.16The system shall produce an error if the sampler sub-application does not contain a Control object with the name 'stochastic'.
• 19.12.17The system shall produce an error if supplied vector of real values is not sized correctly within the SamplerParameterTransfer object.
• 19.12.18The system shall produce an error if a vector of values is supplied to a scalar parameter.
• 19.12.19The system shall produce an error if sampling method differs between the sub-application and the associated sub-application data transfer.
• 19.12.20The system shall be capable of transferring scalar data to sub-applications for each row of the stochastic data
  1. using a Monte Carlo and
  2. Sobol sampling scheme.
• 19.12.21The system shall be capable of transferring vector data to sub-applications for each row of the stochastic data.
• 19.12.22The system shall report an error if the transferred vector to a sub-application
  1. if the vector parameter does not exist;
  2. if the sub-application does not consume all of the supplied data;
• 19.12.23The system shall be able to serialize solution samples on the root process of each subapplication and transfer results to a parallel storage in
  1. batch-restore mode,
  2. batch-reset mode, and
  3. normal mode.
• 19.12.24The system shall be able to distribute the solution samples among the processors of each subapplication, serialize and transfer them to a parallel storage on the corresponding ranks in
  1. batch-restore mode,
  2. batch-reset mode, and
  3. normal mode.
• 19.12.25The system shall support the creation of a sub-application for each row sampled data generated from a Sobol scheme.

• stochastic_tools: Userobjects
• 19.13.1The system shall be able to create a surrogate model for the solution coordinates in the latent space.
• 19.13.2The system should be able to reconstruct a full solution field for a given variable based on
  1. coordinates determined by a surrogate model.
  2. manually specified coordinates.
• 19.13.3The system shall be bale to reconstruct linearly parameterized functions exactly with a few spatial modes using
  1. polynomial regression surrogates for the expansion coefficients.

• stochastic_tools: Variablemappings
• 19.14.1The system should be able to build a variable mapping by computing the SVD of a snapshot matrix in serial.
• 19.14.2The system should be able to build a variable mapping by computing the SVD of a snapshot matrix in parallel.
• 19.14.3The system should be able to build a variable mapping by computing the SVD of a snapshot matrix in parallel with having data on only root processors.

• stochastic_tools: Vectorpostprocessors
• 19.15.9The system shall support the collection of stochastic data from multiple sub-applications.
• 19.15.10The system shall be able to ouptut samples from a sampler using the sampling method
  1. get global matrix;
  2. get local matrix;
  3. get next local row;
• 19.15.11The system shall be able to ouptut distributed samples from a sampler using the sampling method
  1. get local matrix;
  2. get next local row;
• 19.15.12The system shall be able to ouptut samples from a sampler with
  1. one column;
  2. multiple columns;
  3. large number of columns;
• 19.15.13The system shall support the ability to compute first, second, and total-effect Sobol sensitivity indices.
• 19.15.14The system shall support the ability to compute confidence intervals on Sobol sensitivity indices.
• 19.15.17The system shall support the collection of stochastic data that is
  1. replicated on all processors and
  2. distributed across many.
• 19.15.18The system shall support the labeling of collection of stochastic data
  1. with custom prefix and
  2. without a prefix.
• 19.15.19The system shall support the collection of stochastic data that
  1. can be appended into a single data set or
  2. or contain a single file per timestep.

Usability Requirements

Performance Requirements

System Interfaces

System Operations

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:

Physical Characteristics

The Stochastic Tools module is software only with no associated physical media. See System Requirements for a description of the minimum required hardware necessary for running the Stochastic Tools module.

Environmental Conditions

Not Applicable

System Security

MOOSE-based applications such as the Stochastic Tools module 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

The core framework and all modules in their 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 MOOSE 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 Stochastic Tools module development team follows the NQA-1 standards.

Packaging, Handling, Shipping and Transportation

No special requirements are needed for packaging or shipping any media containing MOOSE and Stochastic Tools module source code. However, some MOOSE-based applications that use the Stochastic Tools module may be export-controlled, in which case all export control restrictions must be adhered to when packaging and shipping media.