Fluid Properties 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 Software Design Description (SDD) specific to the Fluid Properties module.

Introduction

The MOOSE Fluid Properties module is based on the MOOSE framework and thus inherits the unique features and base characteristics of the framework, as outlined in the Framework System Design Description. Specific details unique to the module are outlined in this document.

System Purpose

The Software Design Description provided here is description of each object in the system. The pluggable architecture of the underlying framework of the Fluid Properties module 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 the Fluid Properties module. More information about the design documentation for MOOSE-based applications and like the Fluid Properties module can be found in Documenting MOOSE.

System Scope

The purpose of this software is to provide physical properties of fluids to MOOSE-based applications, suitable for a variety of fluid formulations. Specifically, the following objectives are sought:

  • Provide uniform interfaces for accessing single-phase and two-phase fluid properties

  • Provide a library of fluid properties

Dependencies and Limitations

The Fluid Properties module inherits the software dependencies of the MOOSE framework, with no additional dependencies. The design of this module is already relatively stable; the majority of additional contributions aim to extend the list of fluid properties available and make various feature improvements. The design is not expected to be impacted significantly by factors such as budget, schedule, and staffing.

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
DOE-NEDepartment of Energy, Nuclear Energy
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

Stakeholders for MOOSE include several of the funding sources including Department of Energy, Nuclear Energy (DOE-NE) and the INL. However, Since MOOSE is an open-source project, several universities, companies, and foreign governments have an interest in the development and maintenance of the MOOSE project.

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, Fluid Properties module 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, the Fluid Properties module (located within the MOOSE repository) 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

The Fluid Properties module inherits the wide range of pluggable systems from MOOSE. More information regarding MOOSE system design can be found in the framework System Design section. The Fluid Properties module does not provide any physical models for fluid dynamics, only models for computing various physical properties of fluids. Documentation for each object, data structure, and process specific to the module are kept up-to-date alongside the MOOSE documentation. Expected failure modes and error conditions are accounted for via regression testing, and error conditions are noted in object documentation where applicable.

System Structure

The architecture of the Fluid Properties module consists of a core and several pluggable systems (both inherited from the MOOSE framework). The core of MOOSE consists of a number of key objects responsible for setting up and managing the user-defined objects of a finite element simulation. This core set of objects has limited extendability and exists for every simulation configuration that the module is capable of running.

AuxKernels

AuxVariables

FluidProperties

FluidPropertiesInterrogator

Functions

ICs

Materials

Modules

Modules/FluidProperties

UserObjects

Variables

The MooseApp is the top-level object used to hold all of the other objects in a simulation. In a normal simulation a single MooseApp object is created and "run()". This object uses its Factory objects to build user defined objects which are stored in a series of Warehouse objects and executed. The Finite Element data is stored in the Systems and Assembly object while the domain information (the Mesh) is stored in the Mesh object. A series of threaded loops are used to run parallel calculations on the objects created and stored within the warehouses.

MOOSE's pluggable systems are documented on MOOSE website, and those for the Fluid Properties module are on this webpage, accessible through the high-level system links above. Each of these systems has a set of defined polymorphic interfaces and are designed to accomplish a specific task within the simulation. The design of these systems is fluid and is managed through agile methods and ticket request system either on GitHub (for MOOSE) or on the defined software repository for this application.

Data Design and Control

At a high level, the system is designed to process Hierarchical Input Text (HIT) input files to construct several objects that will constitute an finite element (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 Fluid Properties module is a command-line driven program. All interaction with the Fluid Properties module 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 Input/Output (I/O) or through local Application Programming Interface (API) calls. Neither the Fluid Properties module, nor the MOOSE framework, nor the other 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 Fluid Properties module 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

  • fluid_properties: CO2FluidProperties
  • 5.4.1The system shall be able to compute fluid properties for carbon dioxide in a gaseous phase.

    Specification(s): co2

    Design: CO2FluidProperties

    Issue(s): #6972

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

    36
  • fluid_properties: FluidPropertiesInterrogator
  • 5.5.1The fluid properties interrogator shall output static-state fluid properties for (p, T) input.

    Specification(s): 1ph.p_T

    Design: FluidPropertiesInterrogator

    Issue(s): #12995

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • 5.5.2The fluid properties interrogator shall output static-state fluid properties for (p, T) input in JSON format.

    Specification(s): 1ph.p_T.json

    Design: FluidPropertiesInterrogator

    Issue(s): #13741

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • 5.5.3The fluid properties interrogator shall output static-state fluid properties for (rho, e) input.

    Specification(s): 1ph.rho_e

    Design: FluidPropertiesInterrogator

    Issue(s): #12995

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • 5.5.4The fluid properties interrogator shall output static-state fluid properties for (rho, e) input in JSON format.

    Specification(s): 1ph.rho_e.json

    Design: FluidPropertiesInterrogator

    Issue(s): #13741

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • 5.5.5The fluid properties interrogator shall output static-state fluid properties for (rho, p) input.

    Specification(s): 1ph.rho_p

    Design: FluidPropertiesInterrogator

    Issue(s): #12995

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • 5.5.6The fluid properties interrogator shall output static-state fluid properties for (rho, p) input in JSON format.

    Specification(s): 1ph.rho_p.json

    Design: FluidPropertiesInterrogator

    Issue(s): #13741

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • 5.5.7The fluid properties interrogator shall output static-state and stagnation-state fluid properties for (rho, rhou, rhoE) input with a single-phase fluid properties object.

    Specification(s): 1ph.rho_rhou_rhoE

    Design: FluidPropertiesInterrogator

    Issue(s): #12995

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • 5.5.8The fluid properties interrogator shall output static-state and stagnation-state fluid properties for (rho, rhou, rhoE) input with a single-phase fluid properties object in JSON format.

    Specification(s): 1ph.rho_rhou_rhoE.json

    Design: FluidPropertiesInterrogator

    Issue(s): #13741

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • 5.5.9The fluid properties interrogator shall output two-phase and static-state, single-phase fluid properties for (p, T) input with a two-phase fluid properties object.

    Specification(s): 2ph.p_T

    Design: FluidPropertiesInterrogator

    Issue(s): #12995

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • 5.5.10The fluid properties interrogator shall output two-phase and static-state, single-phase fluid properties for (p, T) input with a two-phase fluid properties object in JSON format.

    Specification(s): 2ph.p_T.json

    Design: FluidPropertiesInterrogator

    Issue(s): #13741

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • 5.5.11The fluid properties interrogator shall output two-phase and static-state, single-phase fluid properties for (p, T) input with a two-phase NCG fluid properties object.

    Specification(s): 2ph_ncg_p_T

    Design: FluidPropertiesInterrogator

    Issue(s): #12995

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • 5.5.12The fluid properties interrogator shall output two-phase and static-state, single-phase fluid properties for (p, T) input with a two-phase NCG fluid properties object in JSON format.

    Specification(s): 2ph_ncg_p_T.json

    Design: FluidPropertiesInterrogator

    Issue(s): #13741

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • 5.5.13The fluid properties interrogator shall output static-state, single-phase fluid properties for (rho, e) input with a vapor mixture fluid properties object.

    Specification(s): vapor_mixture_rho_e

    Design: FluidPropertiesInterrogator

    Issue(s): #12995

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • 5.5.14The fluid properties interrogator shall output static-state, single-phase fluid properties for (rho, e) input with a vapor mixture fluid properties object in JSON format.

    Specification(s): vapor_mixture_rho_e.json

    Design: FluidPropertiesInterrogator

    Issue(s): #13741

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • 5.5.15The fluid properties interrogator shall output two-phase fluid properties for (p) input with a two-phase fluid properties object.

    Specification(s): 2ph_p

    Design: FluidPropertiesInterrogator

    Issue(s): #12995

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • 5.5.16The fluid properties interrogator shall output two-phase fluid properties for (p) input with a two-phase fluid properties object in JSON format.

    Specification(s): 2ph_p.json

    Design: FluidPropertiesInterrogator

    Issue(s): #13741

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • 5.5.17The fluid properties interrogator shall output two-phase fluid properties for (T) input with a two-phase fluid properties object.

    Specification(s): 2ph_T

    Design: FluidPropertiesInterrogator

    Issue(s): #12995

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • 5.5.18The fluid properties interrogator shall output two-phase fluid properties for (T) input with a two-phase fluid properties object in JSON format.

    Specification(s): 2ph_T.json

    Design: FluidPropertiesInterrogator

    Issue(s): #13741

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • 5.5.19The fluid properties interrogator shall throw an error if an incompatible fluid properties object is supplied.

    Specification(s): err.wrong_fp_type

    Design: FluidPropertiesInterrogator

    Issue(s): #12995

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

    27
  • 5.5.20The fluid properties interrogator shall throw an error if an extraneous parameter(s) are supplied.

    Specification(s): err.extraneous_parameter

    Design: FluidPropertiesInterrogator

    Issue(s): #12995

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

    27
  • 5.5.21The fluid properties interrogator shall throw an error if an no valid input sets were supplied.

    Specification(s): err.no_params

    Design: FluidPropertiesInterrogator

    Issue(s): #12995

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

    27
  • fluid_properties: NaNInterface
  • 5.9.1The system should produce a warning when a scalar NaN is produced and user required that the execution would not terminate

    Specification(s): quiet_nan_scalar

    Design: NaNInterface

    Issue(s): #12234#12350

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

    5
  • 5.9.2The system should produce a warning when a vector NaN is produced and user required that the execution would not terminate

    Specification(s): quiet_nan_vector

    Design: NaNInterface

    Issue(s): #12234#12350

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

    5
  • 5.9.3The system should report an error when a NaN is produced by a computation in DEBUG mode, by default

    Specification(s): signaling_nan_dbg

    Design: NaNInterface

    Issue(s): #12234#12350

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

    5
  • 5.9.4The system should not report an error when a NaN is produced by a computation in OPT mode, by default

    Specification(s): signaling_nan_opt

    Design: NaNInterface

    Issue(s): #12234#12350

    Collection(s): FUNCTIONAL

    Type(s): RunApp

    27
  • fluid_properties: SaturationPressureMaterial
  • The system shall provide a material that computes saturation pressure using automatic differentiation material properties.

    Specification(s): ad

    Design: SaturationPressureMaterial

    Issue(s): #15860

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

    33
  • 5.10.5The system shall provide a material that computes saturation pressure using non-automatic differentiation material properties.

    Specification(s): nonad

    Design: SaturationPressureMaterial

    Issue(s): #15860

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

    33

References

  1. ISO/IEC/IEEE 24765:2010(E). Systems and software engineering—Vocabulary. first edition, December 15 2010.[BibTeX]
  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.[BibTeX]