IAPWS95 System Design Description
This template follows INL template TEM-140, "IT System Design Description."
This document serves as an addendum to Framework System Design Description and captures information for SDD specific to the IAPWS95 application.
Introduction
IAPWS95 is a module to compute the fluid properties of water using Spline-Based Table lookups (SBTL) for MOOSE applications. SBTL is a fast method of computing properties from pre-generated tables of fluid properties. The IAPWS95 can compute properties such as density, specific heat, or viscosity over the range of validity in pressure and temperature that the input data was defined on. Water fluid properties are useful to perform thermal hydraulic simulations of Light Water Reactors (LWRs) and certain coolant loops in advanced nuclear reactors. LWRs are currently the only type of civilian commercial nuclear reactors in the United States.
System Purpose
The Software Design Description provided here is description of each object in the system. The pluggable architecture of the underlying framework of IAPWS95 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 IAPWS95. More information about the design documentation for MOOSE-based applications like IAPWS95 can be found in Documenting MOOSE.
System Scope
IAPWS95's scope is somewhat open-ended, as fluid properties are an important but generally not central part of a given simulation.
Dependencies and Limitations
IAPWS95 inherits the software dependencies of the MOOSE framework, as well as those of its other underlying software library, libSBTL_vu_95 (Kunick, 2018). Information on dependencies and limitations inherent in these dependencies are covered in the associated references linked here.
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
| Acronym | Description |
|---|---|
| API | Application Programming Interface |
| DOE | Department of Energy |
| FE | finite element |
| HIT | Hierarchical Input Text |
| HPC | High Performance Computing |
| I/O | Input/Output |
| INL | Idaho National Laboratory |
| MOOSE | Multiphysics Object Oriented Simulation Environment |
| MPI | Message Passing Interface |
| SDD | Software Design Description |
Design Stakeholders and Concerns
Design Stakeholders
Stakeholders for IAPWS95 include its funding sources, the Department of Energy (DOE) and INL.
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, IAPWS95 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, IAPWS95 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
IAPWS95 relies on MOOSE to calculate fluid properties for water and steam. The design of MOOSE is based on the concept of modular code objects that define all of the aspects of the physics model. IAPWS95 follows this design, providing code objects that define specific aspects of the solutions for its physics that derive from the base classes defined by the MOOSE framework and the modules that it depends on.
In IAPWS95, water properties are computed within a fluid property user object. Fluid properties user objects derive from base classes defined in the MOOSE fluid properties module. These base classes define interfaces that other objects, such as Materials, can leverage to make the fluid property user object retrieve the desired fluid properties, e.g. density or specific heat.
Liquid water properties do not include phase changes, so the derived class naturally derives from the SinglePhaseFluidProperties base class in the Fluid Properties module. As such most interfaces that are defined have a similar signature to the one below. Alternative signatures are available for using automatic differentiation or using the specific volume and specific enthalpy variables (also referred to as the conservative variables set).
rho_from_p_T(Real pressure, Real temperature)
Vapor water properties share the same SinglePhaseFluidProperties base class as they also do not model phase changes. There are several options for the two-phase fluid properties. They can either be modeled using a Homogeneous Equilibrium Model, a non-condensable gas approximation, or following the IAPWS95 formulation. Each choice uses a different base class in the Fluid Properties module. For all, an additional variable, the phase fraction, is added to compute fluid properties such as density or specific heat.
As with any fluid property, the ranges of validity of these fluid properties used are finite. They are documented in the class documentation for the fluid property user object for SBTL Water fluid properties. IAPWS95 may error if these properties are queried outside of their range of validity, depending on the user-selected out-of-bounds behavior.
System Structure
IAPWS95 relies on the MOOSE framework to provide the core functionality of solving multiphysics problems using the finite element method. It also relies on the MOOSE modules for much of its core functionality. A summary listing of the current modules required for complete IAPWS95 operation are shown below:
The structure of IAPWS95 is based on defining C++ classes that derive from classes in the MOOSE framework or modules that provide functionality that is specifically tailored to the calculation of fluid properties. By using the interfaces defined in MOOSE base classes for these classes, IAPWS95 is able to rely on MOOSE to execute these models at the appropriate times during the simulation and use their results in the desired ways.
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 IAPWS95 application is a command-line driven program. All interaction with IAPWS95 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 IAPWS95, 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 IAPWS95 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
References
- ISO/IEC/IEEE 24765:2010(E).
Systems and software engineering—Vocabulary.
first edition, December 15 2010.[BibTeX]
- Matthias Kunick.
Fast Calculation of Thermophysical Properties in Extensive Process Simulations with the Spline-Based Table Look-Up Method (SBTL).
Volume 618 of Energietechnik.
VDI Verlag, Düsseldorf, 1st edition, 2018.[BibTeX]
- 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]