Fluid Structure Interaction System Design Description

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 Structure Interaction 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 Structure Interaction module. More information about the design documentation for MOOSE-based applications and like the Fluid Structure Interaction module can be found in Documenting MOOSE.

System Scope

The MOOSE Fluid Structure Interaction module provides interface kernels for simulating the interactions between neighboring fluid and solid subdomains. It can be used as a standalone application or can be included in downstream applications interested in modeling fluid structure interactions.

Dependencies and Limitations

The Fluid Structure Interaction module inherits the software dependencies and limitations of the MOOSE framework, as well as the dependencies and limitations of the Navier-Stokes and solid mechanics modules. The Fluid Structure Interaction module is in its relative infancy, so it may not have all the features desired by potential users. Currently there is relatively little programmatic funding at Idaho National Laboratory to support development of the Fluid Structure Interaction module, so this may limit they growth in capability.

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

Design Stakeholders

Stakeholders for MOOSE include several of the funding sources including 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 Structure Interaction 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 Structure Interaction 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 Structure

The architecture of the Fluid Structure Interaction 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 or finite volume simulation. This core set of objects has limited extendability and exists for every simulation configuration that the module is capable of running.

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 Fluid Structure Interaction module is a command-line driven program. All interaction with the Fluid Structure Interaction 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 I/O or through local API calls. Neither the Fluid Structure Interaction 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 Structure Interaction 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.