MOOSE Tools Requirements Traceability Matrix

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

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

MOOSE Tools is a set of Python utilities designed to support the MOOSE framework. MOOSE Tools contains two main utilities – MOOSE Documentation System (MooseDocs) and TestHarness – that facilitate MOOSE documentation (e.g., website and presentation building) and code testing. While tied to the framework most directly (and housed within the MOOSE code repository), MOOSE Tools can be used in a more general sense to support other codes. More specific information on the design and structure of MOOSE Tools utilities can be found on the main documentation page.

The design goal of MOOSE Tools is to give code developers access to common tools and resources to help them verify, test, and document their code and simulations, as well as make best use of the input and output data obtained in the process of performing research. To this end, many of the Tools utilities are extensible and flexible, like MOOSE itself, and therefore are designed to be expanded and reconfigured to meet the needs of the end-user.

System Scope

The scope of MOOSE Tools is to provide a set of utilities to support MOOSE development. Namely, verification, testing, documentation, and data analysis and manipulation of MOOSE code and I/O. Tools code is written in a general way, so that it can be extended and tuned to the needs of the user/developer. The major two systems of the Tools utilities are described in the following sections, but more information on the support utiltities also contained within MOOSE tools can be found on the main documentation page.

MooseDocs

The MOOSE Documentation System (MooseDocs) facilitates documentation of the MOOSE and MOOSE Tools code bases, as well as supports the MOOSE SQA practices. It contains many extensions for website rendering, navigation, linking, bibliographic references, and support for integration of code and input file snippets (among many more features), as well as capabilities for development of training and presentation slides and reports.

TestHarness

The TestHarness system is responsible for finding tests and running them. The extended philosophy behind MOOSE testing can be found in the MOOSE Test System documentation page, and this philsophy has driven the creation and design choices of the TestHarness system.

Within MOOSE there are three different testing ideas:

  1. The "tests": which are typically "Regression Tests" consisting of input files and known good outputs ("gold" files).

  2. Unit tests that test the funcationality of small seperable pieces

  3. The TestHarness: a piece of software that was written to _run_ tests and aggregate the results.

The TestHarness integrates with the MOOSE continuous integration (CI) and continuous deployment (CD) workflows to facilitate testing across multiple operating systems and hardware architectures.

Assumptions and Dependencies

The software should be designed with the fewest possible constraints. Ideally the software should run on a wide variety of evolving hardware so it should follow well-adopted standards and guidelines. The software should run on any POSIX compliant system containing the Python language and interpreter. The main interface for the software will be command line based with no assumptions requiring advanced terminal capabilities such as coloring and line control.

Pre-test Instructions/Environment/Setup

Ideally all testing should be performed on a clean test machine following one of the supported configurations set up 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

  • python: Tests
  • 2.2.1The system shall include a utility for building tree structures using a scripting language that includes
    1. a node object,
    2. a tree iteration function, and
    3. search algorithms.

    Specification(s): tree/Node, tree/iterator, tree/search

    Design: moosetree package

    Issue(s): #13657

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.2The system shall contain python utilities that include a messaging interface.

    Specification(s): mooseMessage

    Design: MOOSE Tools

    Issue(s): #11189

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.3The system shall contain python utilities that include a messaging interface capable of creating a dialog window.

    Specification(s): mooseMessageDialog

    Design: MOOSE Tools

    Issue(s): #11189

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.4The system shall contain python utilities for reading CSV data via pandas.DataFrame.

    Specification(s): moose_data_frame

    Design: MOOSE Tools

    Issue(s): #11189

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.5The system shall contain python utilities for reading postprocessor data.

    Specification(s): postprocessors

    Design: MOOSE Tools

    Issue(s): #11189

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.6The system shall contain python utilities for reading vector postprocessor data.

    Specification(s): vector_postprocessors

    Design: MOOSE Tools

    Issue(s): #11189

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.7The system shall contain python utilities for reading reporter data.

    Specification(s): reporters

    Design: MOOSE Tools

    Issue(s): #17391

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.8The system shall contain python utilities for converting camel case text to underscore separated text.

    Specification(s): camel

    Design: MOOSE Tools

    Issue(s): #11189

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.9The system shall contain python utilities for reading YAML files.

    Specification(s): yaml_load

    Design: MOOSE Tools

    Issue(s): #11189

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.10The system shall contain python utilities for breaking a list of items into a specified number of chunks.

    Specification(s): make_chunks

    Design: MOOSE Tools

    Issue(s): #11189

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.11The system shall include a utility for locating a MOOSE-based application executable.

    Specification(s): find_moose_executable

    Design: MOOSE Tools

    Issue(s): #15017

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.12The system shall include utilities for executing version control system commands.

    Specification(s): gitutils

    Design: MOOSE Tools

    Issue(s): #11189

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.13The system shall include a utility running an executable.

    Specification(s): run_executable

    Design: MOOSE Tools

    Issue(s): #15996

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.14The system shall include a tool for accessing CIVET testing results.

    Specification(s): civet_results

    Design: MOOSE Tools

    Issue(s): #11189

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.15The system shall contain python utilities for reading PerfGraphReporter data.

    Specification(s): perfgraph

    Design: MOOSE Tools

    Issue(s): #16256

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.16The system shall contain python utilities for reading compared csv files.

    Specification(s): csvdiff

    Design: MOOSE Tools

    Issue(s): #20032

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.17The system shall contain a python postprocessor class to combine CSV files together.

    Specification(s): combine_csv

    Design: MOOSE Tools

    Issue(s): #13988

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.18The system shall contain a python utility for parsing hierarchical input text (HIT) files.

    Specification(s): parser

    Design: MOOSE Tools

    Issue(s): #11189

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.19The system shall contain a python utility for tokenizing hierarchical input text (HIT) files.

    Specification(s): tokenize

    Design: MOOSE Tools

    Issue(s): #15889

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.20The system shall include examples for reading, writing, and manipulating input file syntax using python.

    Specification(s): examples

    Design: MOOSE Tools

    Issue(s): #16622

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.21The system shall report a non-failing status after a predetermined time of no activity

    Specification(s): long_running

    Design: TestHarness

    Issue(s): #9280

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.22The system shall support the output of the longest running jobs

    Specification(s): longest_jobs

    Design: TestHarness

    Issue(s): #16752

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.26The system shall restrict tests based on the available dual number derivative vector size

    Specification(s): min_ad_size

    Design: TestHarness

    Issue(s): #427

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.28The system shall not perform a test if said test has a skipped dependency

    Specification(s): dependency_skip

    Design: TestHarness

    Issue(s): #427

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.32The system shall report deleted tests as failures when specified with additional –extra-info optionsIn all other cases, deleted tests will be treated as skipped tests

    Specification(s): deleted

    Design: TestHarness

    Issue(s): #427

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.33The system shall perform all operations required of the TestHarness except executing a test

    Specification(s): dry_run

    Design: TestHarness

    Issue(s): #8637

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.34The system shall run only tests designated with display_required.

    Specification(s): dislpay_required

    Design: TestHarness

    Issue(s): #8700#8701

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.35The system shall allow users to ignore and override specified prerequisites

    Specification(s): ignore

    Design: TestHarness

    Issue(s): #427

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.40The system shall skip a test if required application is unavailable

    Specification(s): required_apps

    Design: TestHarness

    Issue(s): #11095

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.41The system shall only perform the validation of test results without executing the test itself

    Specification(s): should_execute

    Design: TestHarness

    Issue(s): #9932

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.42The system shall skip syntax only tests if instructed to do so

    Specification(s): report_skipped

    Design: TestHarness

    Issue(s): #9359

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.43The system shall properly run tests using distributed mesh options

    Specification(s): distributed_mesh

    Design: TestHarness

    Issue(s): #9181

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.44The system shall supply the necessary resources a test requires, and report when these resources are insufficient to run said test

    Specification(s): allocations

    Design: TestHarness

    Issue(s): #10272

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.45The system shall print all caveats pertaining to the test involved

    Specification(s): extra_info

    Design: TestHarness

    Issue(s): #10272

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.47The system shall allow the test scheduler to gracefully skip tests having the same name contained within the same tests file for further checks against the test file parser.

    Specification(s): duplicate_test_names

    Design: TestHarness

    Issue(s): #10424

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.48The system shall perform normal operating procedures on a single provided test spec file

    Specification(s): arbitrary_tests

    Design: TestHarness

    Issue(s): #11076

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.49The system shall write the output (stdout|stderr) that an executed test generated to a file as designated by user supplied arguments

    Specification(s): write_results

    Design: TestHarness

    Issue(s): #11116

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

    Prerequisite(s): 2.2.24

  • 2.2.50The system shall be able to perform recovery of a test

    Specification(s): recover_tests

    Design: TestHarness

    Issue(s): #11492

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.51The system shall be able to submit jobs to a PBS third party scheduler

    Specification(s): pbs_tests

    Design: TestHarness

    Issue(s): #12138

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.52The system shall trim output once threshold has exceeded

    Specification(s): trim_output

    Design: TestHarness

    Issue(s): #12167

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.53The system shall detect and report race conditions that exist in the supplied tests

    Specification(s): race_conditions

    Design: TestHarness

    Issue(s): #13186

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.54The system shall detect and report unreadable output in executed commands

    Specification(s): unreadable_output

    Design: TestHarness

    Issue(s): #14370

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.55The system shall run only tests which previously have failed

    Specification(s): failed_tests

    Design: TestHarness

    Issue(s): #14512

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.56The system shall support restrictions based on the python version available.

    Specification(s): python_version

    Design: TestHarness

    Issue(s): #13903

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.57The system shall be able to compare computed values against measured data using mean value and standard deviation

    Specification(s): csvvalidationtester

    Design: TestHarness

    Issue(s): #14511

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.58The system shall be able to run tests in relative path directories supplied by the spec file

    Specification(s): working_directory

    Design: TestHarness

    Issue(s): #14962

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.60The system shall perform a test after all other tests have passed if specified to do so

    Specification(s): do_last

    Design: TestHarness

    Issue(s): #15230

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.62The system shall be able to replay last results

    Specification(s): test_show_last_results

    Design: TestHarness

    Issue(s): #22545

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.63The system shall be able to evaluate a given test with a user-supplied evaluation function.

    Specification(s): custom_eval

    Design: TestHarness

    Issue(s): #22946

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.64The system shall test for a valid json output dump

    Specification(s): test_failed_json

    Design: TestHarness

    Issue(s): #21967

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

  • 2.2.65The system shall skip tests not capable of being run depending on binary installation type

    Specification(s): test_install_type

    Design: TestHarness

    Issue(s): #24195

    Collection(s): FUNCTIONAL

    Type(s): PythonUnitTest

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.