OpenPronghorn System Design Description

This template follows INL template TEM-140, "IT System Design Description."

commentnote

This document serves as an addendum to Framework System Design Description and captures information for SDD specific to the OpenPronghorn application.

Introduction

errorerror:Missing Template Item: "introduction"

The document must include the "introduction" template item, this can be included by adding the following to the markdown file (sqa/open_pronghorn_sdd.md):

!template! item key=introduction
Include text (in MooseDocs format) regarding the "introduction" template item here.
!template-end!

System Purpose

The Software Design Description provided here is description of each object in the system. The pluggable architecture of the underlying framework of OpenPronghorn makes MOOSE and MOOSE-based applications straightforward to develop as each piece of end-user (developer) code that goes into the system follows a well-defined interface for the underlying systems that those object plug into. These descriptions are provided through developer-supplied "markdown" files that are required for all new objects that are developed as part of OpenPronghorn. More information about the design documentation for MOOSE-based applications like OpenPronghorn can be found in Documenting MOOSE.

System Scope

errorerror:Missing Template Item: "system-scope"

Delineate the following:

  1. Identify the product(s) to be produced by name (Network Infrastructure, Host DBMS, Report Generator, HPC Server, etc.)

  2. Explain what the product(s) will, and, if necessary, will not do.

  3. Describe the application of the product being specified, including relevant benefits, objectives, and goals.

commentnote

Be consistent with similar statements in higher level specifications (e.g., business requirements specification).

The document must include the "system-scope" template item, this can be included by adding the following to the markdown file (sqa/open_pronghorn_sdd.md):

!template! item key=system-scope
Include text (in MooseDocs format) regarding the "system-scope" template item here.
!template-end!

Dependencies and Limitations

errorerror:Missing Template Item: "dependencies-and-limitations"

List the dependencies or limitations that may affect the design of the system. Examples include budget and schedule constraints, staffing issues, availability of components, etc. Describe how each factor will affect the functional design.

The document must include the "dependencies-and-limitations" template item, this can be included by adding the following to the markdown file (sqa/open_pronghorn_sdd.md):

!template! item key=dependencies-and-limitations
Include text (in MooseDocs format) regarding the "dependencies-and-limitations" template item here.
!template-end!

Definitions and Acronyms

This section defines, or provides the definition of, all terms and acronyms required to properly understand this specification.

Definitions

  • Pull (Merge) Request: A proposed change to the software (e.g. usually a code change, but may also include documentation, requirements, design, and/or testing).

  • Baseline: A specification or product (e.g., project plan, maintenance and operations (M&O) plan, requirements, or design) that has been formally reviewed and agreed upon, that thereafter serves as the basis for use and further development, and that can be changed only by using an approved change control process (NQA-1, 2009).

  • Validation: Confirmation, through the provision of objective evidence (e.g., acceptance test), that the requirements for a specific intended use or application have been fulfilled (24765:2010(E), 2010).

  • 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

AcronymDescription
APIApplication Programming Interface
FEfinite element
HITHierarchical Input Text
HPCHigh Performance Computing
I/OInput/Output
INLIdaho National Laboratory
MOOSEMultiphysics Object Oriented Simulation Environment
MPIMessage Passing Interface
SDDSoftware Design Description

Design Stakeholders and Concerns

Design Stakeholders

errorerror:Missing Template Item: "design-stakeholders"

Identify the stakeholders of the IT system design.

The document must include the "design-stakeholders" template item, this can be included by adding the following to the markdown file (sqa/open_pronghorn_sdd.md):

!template! item key=design-stakeholders
Include text (in MooseDocs format) regarding the "design-stakeholders" template item here.
!template-end!

Stakeholder Design Concerns

Concerns from many of the stakeholders are similar. These concerns include correctness, stability, and performance. The mitigation plan for each of these can be addressed. For correctness, OpenPronghorn development requires either regression or unit testing for all new code added to the repository. The project contains several comparisons against analytical solutions where possible and also other verification methods such as MMS. For stability, OpenPronghorn maintains multiple branches to incorporate several layers of testing both internally and for dependent applications. Finally, performance tests are also performed as part of the the normal testing suite to monitor code change impacts to performance.

System Design

errorerror:Missing Template Item: "system-design"

For this section, detail should be commensurate with the level of risk and demonstrate the fulfillment of requirements providing guidance for implementation.

For custom developed software (see def. in LWP-13620) activities, the following is required:

The documented design shall include, as applicable:

  • Numerical methods

  • Mathematical models

  • Physical models

  • Control flow

  • Control logic

  • Data flow

  • Process flow

  • Data structures

  • Process structures

  • Applicable relationships between data structures and process structures

In addition, for safety software consider:

Principles of simplicity, decoupling, and isolation to eliminate hazards. Safety features should be separate from nonsafety modules minimizing the impact of failure of one module on another. Techniques, such as failure modes and effects analysis, fault-tree modeling, event-tree modeling, cause-consequence diagrams, hazard and operability analysis, and interface analysis.

The document must include the "system-design" template item, this can be included by adding the following to the markdown file (sqa/open_pronghorn_sdd.md):

!template! item key=system-design
Include text (in MooseDocs format) regarding the "system-design" template item here.
!template-end!

System Structure

errorerror:Missing Template Item: "system-structure"

Decompose the system into design entities or objects that will interact with and transform data to perform the required system objectives. Assign a unique name to each design entity, and group entities by type (e.g., class, object, procedure). Describe how each design entity satisfies system requirements. In user terminology, specify the inputs, outputs, and transformation rules for each design entity. Depict how design entities depend on one another.

The document must include the "system-structure" template item, this can be included by adding the following to the markdown file (sqa/open_pronghorn_sdd.md):

!template! item key=system-structure
Include text (in MooseDocs format) regarding the "system-structure" template item here.
!template-end!

Data Design and Control

At a high level, the system is designed to process HIT input files to construct several objects that will constitute an FE simulation. Some of the objects in the simulation may in turn load other file-based resources to complete the simulation. Examples include meshes or data files. The system will then assemble systems of equations and solve them using the libraries of the Code Platform. The system can then output the solution in one or more supported output formats commonly used for visualization.

Human-Machine Interface Design

The OpenPronghorn application is a command-line driven program. All interaction with OpenPronghorn is ultimately done through the command line. This is typical for HPC applications that use the MPI interface for running on super computing clusters. Optional GUIs may be used to assist in creating input files and launching executables on the command line.

System Design Interface

All external system interaction is performed either through file I/O or through local API calls. Neither OpenPronghorn, nor the MOOSE framework, nor the MOOSE modules are designed to interact with any external system directly through remote procedure calls. Any code to code coupling performed using the framework are done directly through API calls either in a static binary or after loading shared libraries.

Security Structure

The OpenPronghorn application does not require any elevated privileges to operate and does not run any stateful services, daemons or other network programs. Distributed runs rely on the MPI library.

Requirements Cross-Reference

  • open_pronghorn: Diffusion
  • 2.2.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

References

  1. ISO/IEC/IEEE 24765:2010(E). Systems and software engineering—Vocabulary. first edition, December 15 2010.[Export]
  2. ASME NQA-1. ASME NQA-1-2008 with the NQA-1a-2009 addenda: Quality Assurance Requirements for Nuclear Facility Applications. first edition, August 31 2009.[Export]