MOOSE System Design Description

Introduction

Frameworks are a software development construct aiming to simplify the creation of specific classes of applications through abstraction of low-level details. The main object of creating a framework is to provide an interface to application developers that saves time and provides advanced capabilities not attainable otherwise. The Multiphysics Object Oriented Simulation Environment (MOOSE), mission is just that: provide a framework for engineers and scientists to build state-of-the-art, computationally scalable finite element based simulation tools.

MOOSE was conceived with one major objective: to be as easy and straightforward to use by scientists and engineers as possible. MOOSE is meant to be approachable by non-computational scientists who have systems of partial differential equations (PDEs) they need to solve. Every single aspect of MOOSE was driven by this singular principle from the build system to the API to the software development cycle. At every turn, decisions were made to enable this class of users to be successful with the framework. The pursuit of this goal has led to many of the unique features of MOOSE:

  • A streamlined build system

  • An API aimed at extensible

  • Straightforward APIs providing sensible default information

  • Integrated, automatic, and rigorous testing

  • Rapid, continuous integration development cycle

  • Codified, rigorous path for contributing

  • Applications are modular and composable

Each of these characteristics is meant to build trust in the framework by those attempting to use it. For instance, the build system is the first thing potential framework users come into contact with when they download a new software framework. Onerous dependency issues, complicated, hard to follow instructions or build failure can all result in a user passing on the platform. Ultimately, the decision to utilize a framework comes down to whether or not you trust the code in the framework and those developing it to be able to support your desired use-case. No matter the technical capabilities of a framework, without trust users will look elsewhere. This is especially true of those not trained in software development or computational science.

Developing trust in a framework goes beyond utilizing "best practices" for the code developed, it is equally important that the framework itself is built upon tools that are trusted. For this reason, MOOSE relies on a well-established code base of libMesh and PETSc. The libMesh library provides foundational capability for the finite element method and provides interfaces to leading-edge numerical solution packages such as PETSc.

With these principles in mind, an open source, massively parallel, finite element, multiphysics framework has been conceived. MOOSE is an on-going project started in 2008 aimed toward a common platform for creation of new multiphysics tools. This document provides design details pertinent to application developers as well as framework developers.

Use Cases

The MOOSE Framework is targeted at two main groups of actors: Developers and Users. Developers are the main use case. These are typically students and professionals trained in science and engineering fields with some level of experience with coding but typically very little formal software development training. The other user group is Users. Those who intend to use an application built upon the framework without writing any computer code themselves. Instead they may modify or create input files for driving a simulation, run the application, and analyze the results. All interactions through MOOSE are primarily through the command-line interface and through a customizable block-based input file.

System Purpose

error:Missing Template Item "system-purpose"help_outline

Briefly describe the objectives and rationale of the System Design Description (e.g., describing the system design in the user’s terminology, providing a guide for a more technical design document, or ensuring that customers and technical staff have a common understanding of the system design). Explain how this document might evolve throughout the product life cycle.

System Scope

error:Missing Template Item "system-scope"help_outline

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.

note

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

Dependencies and Limitations

error:Missing Template Item "dependencies-and-limitations"help_outline

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.

References

  1. ISO/IEC/IEEE 24765:2010(E). Systems and software engineering—Vocabulary. first edition, December 15 2010.[BibTeX]
  2. D. F. Griffiths. The `No Boundary Condition' outflow boundary condition. International Journal of Numerical Methods in Fluids, 24(4):393–411, 1997. URL: http://tinyurl.com/y77au2k.[BibTeX]
  3. 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]

Definitions and Acronyms

error:Missing Template Item "definitions-and-acronyms"help_outline

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

Definitions

error:Missing Template Item "definitions"help_outline

Add or revise spcific defintions.

  • 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

error:Missing Template Item "acronyms"help_outline

Define specific acronyms.

AcronymDescription
ASMEAmerican Society of Mechanical Engineers
DOEDepartment of Energy

Design Stakeholders and Concerns

error:Missing Template Item "design-stakeholders-and-concerns"help_outline

Design Stakeholders

error:Missing Template Item "design-stakeholders"help_outline

Identify the stakeholders of the IT system design.

Stakeholder Design Concerns

error:Missing Template Item "stakeholder-design-concerns"help_outline

Identify and address each design concern including measures to mitigate consequences of problems. Reference risk management plan as appropriate.

System Design

The MOOSE framework itself is composed of a wide range of pluggable systems. Each system is generally composed of a single or small set of C++ objects intended to be specialized by a Developer to solve a specific problem. To accomplish this design goal, MOOSE uses several modern object-oriented design patterns. The primary overarching pattern is the "Factory Pattern". Users needing to extend MOOSE may inherit from one of MOOSE's systems to providing an implementation meeting his or her needs. The design of each of these systems is documented on the mooseframework.org wiki in the Tutorial section. Additionally, up-to-date documentation extracted from the source is maintained on the the mooseframework.org documentation site after every successful merge to MOOSE's stable branch. After these objects are created, the can be registered with the framework and used immediately in a MOOSE input file.

System Structure

The MOOSE framework architecture consists of a core and several pluggable systems. 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 exist for every simulation configuration that the framework is capable of running.

under construction

This list is automatically generated by MooseDocs, each system (as determined by the syntax dump from the executable) is known and has a markdown page. It is assumed that each page contains the system design. In the future these pages may require a "design" section, which this list could reference directly.

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 it's 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 the mooseframework.org wiki. Each of these systems has 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 on the Github.org website.

Data Design and Control

error:Missing Template Item "data-design-and-control"help_outline

Using a data modeling technique identify specific data elements and logical data groupings that are stored and processed by the design entities in Section 5.1, “System Structure.” Outline data dependencies, relationships, and integrity rules in a data dictionary. Specify the format and attributes of all data elements or data groupings. Contact the laboratory Enterprise Architect for assistance with data dictionary development and data management standards. See GDE-4, Data Management Guide, for additional guidance.

Develop a logical model of data flow through the system by depicting how design elements transform input data into outputs.

Human-Machine Interface Design

error:Missing Template Item "human-machine-interface-design"help_outline

Describe the user interface and the operating environment, including the menu hierarchy, data entry screens, display screens, online help, and system messages. Specify where in this environment the necessary inputs are made, and list the methods of data outputs (e.g., printer, screen, file). Note any design standards to be applied. If project human-machine interface design standards have been developed, discuss them in this section.

System Design Interface

error:Missing Template Item "system-design-interface"help_outline

Specify how the product will interface with other systems. For each interface, describe the inputs and outputs for the interacting systems. Explain how data is formatted for transmission and validated upon arrival. Note the frequency of data exchange.

Security Structure

error:Missing Template Item "security-structure"help_outline

Describe the software functionality supporting the security architecture of the system design. This would list features such as user privilege restrictions, logging of auditable events, and the encryption technology for securing data in storage or transmission.

Requirements Cross-Reference

  • PenetrationAux
  • F15.1

    The PenetrationAux object shall compute the distance between two overlapping boundaries using a constant monomial auxiliary variable.

    Specification: geomsearch/quadrature_penetration_locator:qpl

    Design: PenetrationAux

  • F15.2

    The PenetrationAux object shall compute the distance between two overlapping boundaries using a constant monomial auxiliary variable in 1D.

    Specification: geomsearch/quadrature_penetration_locator:1d_qpl

    Design: PenetrationAux

  • F15.3

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces of a moving interface in 2D.

    Specification: geomsearch/2d_moving_penetration:pl_test1

    Design: PenetrationAux

  • F15.4

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces of a moving interface in 2D using second order elements.

    Specification: geomsearch/2d_moving_penetration:pl_test1q

    Design: PenetrationAux

  • F15.5

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces of a moving interface in 2D using a tangential tolerance of for the distance.

    Specification: geomsearch/2d_moving_penetration:pl_test1tt

    Design: PenetrationAux

  • F15.6

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces of a moving interface in 2D using a tangential tolerance of for the distance and second order elements.

    Specification: geomsearch/2d_moving_penetration:pl_test1qtt

    Design: PenetrationAux

  • F15.7

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces of a moving interface in 2D.

    Specification: geomsearch/2d_moving_penetration:pl_test2

    Design: PenetrationAux

  • F15.8

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces of a moving interface in 2D with second order elements.

    Specification: geomsearch/2d_moving_penetration:pl_test2q

    Design: PenetrationAux

  • F15.9

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces of a moving interface in 2D using a tangential tolerance for the distance.

    Specification: geomsearch/2d_moving_penetration:pl_test2tt

    Design: PenetrationAux

  • F15.10

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces of a moving interface in 2D using a tangential tolerance for the distance and second order elements.

    Specification: geomsearch/2d_moving_penetration:pl_test2qtt

    Design: PenetrationAux

  • F15.11

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 2D.

    Specification: geomsearch/2d_moving_penetration:pl_test3

    Design: PenetrationAux

  • F15.12

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 2D and second order elements.

    Specification: geomsearch/2d_moving_penetration:pl_test3q

    Design: PenetrationAux

  • F15.13

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 2D using a tangential tolerance of for the distance.

    Specification: geomsearch/2d_moving_penetration:pl_test3tt

    Design: PenetrationAux

  • F15.14

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 2D using a tangential tolerance of for the distance and second order elements.

    Specification: geomsearch/2d_moving_penetration:pl_test3qtt

    Design: PenetrationAux

  • F15.15

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 2D using normal smoothing for the distance.

    Specification: geomsearch/2d_moving_penetration:pl_test3ns

    Design: PenetrationAux

  • F15.16

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 2D using normal smoothing for the distance and second order elements.

    Specification: geomsearch/2d_moving_penetration:pl_test3qns

    Design: PenetrationAux

  • F15.17

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 2D using nodal normal based smoothing for the distance.

    Specification: geomsearch/2d_moving_penetration:pl_test3nns

    Design: PenetrationAux

  • F15.18

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 2D using nodal normal based smoothing for the distance and second order elements.

    Specification: geomsearch/2d_moving_penetration:pl_test3qnns

    Design: PenetrationAux

  • F15.19

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 2D.

    Specification: geomsearch/2d_moving_penetration:pl_test4

    Design: PenetrationAux

  • F15.20

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 2D using second order elements.

    Specification: geomsearch/2d_moving_penetration:pl_test4q

    Design: PenetrationAux

  • F15.21

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 2D using a tangential tolerance of for the distance.

    Specification: geomsearch/2d_moving_penetration:pl_test4tt

    Design: PenetrationAux

  • F15.22

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 2D using a tangential tolerance of for the distance and second order elements.

    Specification: geomsearch/2d_moving_penetration:pl_test4qtt

    Design: PenetrationAux

  • F15.23

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 2D using normal smoothing for the distance.

    Specification: geomsearch/2d_moving_penetration:pl_test4ns

    Design: PenetrationAux

  • F15.24

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 2D using normal smoothing for the distance and second order elements.

    Specification: geomsearch/2d_moving_penetration:pl_test4qns

    Design: PenetrationAux

  • F15.25

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 2D using nodal normal based smoothing.

    Specification: geomsearch/2d_moving_penetration:pl_test4nns

    Design: PenetrationAux

  • F15.26

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 2D using nodal normal based smoothing and second order elements.

    Specification: geomsearch/2d_moving_penetration:pl_test4qnns

    Design: PenetrationAux

  • F15.27

    The 'geomsearch/2d_moving_penetration/restart' shall create the necessary files for testing restart of the PenetrationAux object.

    Specification: geomsearch/2d_moving_penetration:restart

    Design: PenetrationAux

  • F15.28

    The PenetrationAux object shall be capable of restarting from a previous simulation.

    Specification: geomsearch/2d_moving_penetration:restart2

    Design: PenetrationAux

    Prerequisites: F15.27

  • F15.29

    The PenetrationAux object shall compute the distance between two boundaries in 3D that overlap.

    Specification: geomsearch/penetration_locator:test

    Design: PenetrationAux

  • F15.30

    The PenetrationAux object shall compute, in parallel, the distance between two boundaries in 3D that overlap.

    Specification: geomsearch/penetration_locator:parallel_test

    Design: PenetrationAux

    Prerequisites: F15.29 F15.31 F15.38 F15.40 F15.56

  • F15.31

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces in 3D.

    Specification: geomsearch/3d_penetration_locator:test

    Design: PenetrationAux

  • F15.32

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces in 2D with tetrahedron elements.

    Specification: geomsearch/3d_penetration_locator:3d_tet

    Design: PenetrationAux

  • F15.38

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces in 2D.

    Specification: geomsearch/2d_penetration_locator:test

    Design: PenetrationAux

  • F15.39

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces in 2D with triangular elements.

    Specification: geomsearch/2d_penetration_locator:2d_triangle

    Design: PenetrationAux

  • F15.40

    MOOSE shall be capable of computing the distance between two disjoint boundaries on a 1D domain.

    Specification: geomsearch/1d_penetration_locator:test

    Design: PenetrationAux

    Issues: #1693

  • F15.42

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces of a moving interface in 3D.

    Specification: geomsearch/3d_moving_penetration:pl_test1

    Design: PenetrationAux

  • F15.43

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces of a moving interface in 3D using second order elements.

    Specification: geomsearch/3d_moving_penetration:pl_test1q

    Design: PenetrationAux

  • F15.44

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces of a moving interface in 3D using a tangential tolerance of for the distance.

    Specification: geomsearch/3d_moving_penetration:pl_test1tt

    Design: PenetrationAux

  • F15.45

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces of a moving interface in 3D using a tangential tolerance of for the distance and second order elements.

    Specification: geomsearch/3d_moving_penetration:pl_test1qtt

    Design: PenetrationAux

  • F15.46

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces of a moving interface in 3D.

    Specification: geomsearch/3d_moving_penetration:pl_test2

    Design: PenetrationAux

  • F15.47

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces of a moving interface in 3D with second order elements.

    Specification: geomsearch/3d_moving_penetration:pl_test2q

    Design: PenetrationAux

  • F15.48

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces of a moving interface in 3D using a tangential tolerance for the distance.

    Specification: geomsearch/3d_moving_penetration:pl_test2tt

    Design: PenetrationAux

  • F15.49

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces of a moving interface in 3D using a tangential tolerance for the distance and second order elements.

    Specification: geomsearch/3d_moving_penetration:pl_test2qtt

    Design: PenetrationAux

  • F15.50

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 3D.

    Specification: geomsearch/3d_moving_penetration:pl_test3

    Design: PenetrationAux

  • F15.51

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 3D and second order elements.

    Specification: geomsearch/3d_moving_penetration:pl_test3q

    Design: PenetrationAux

  • F15.52

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 3D using a tangential tolerance of for the distance and second order elements.

    Specification: geomsearch/3d_moving_penetration:pl_test3tt

    Design: PenetrationAux

  • F15.53

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 3D.

    Specification: geomsearch/3d_moving_penetration:pl_test4

    Design: PenetrationAux

  • F15.54

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 3D using second order elements.

    Specification: geomsearch/3d_moving_penetration:pl_test4q

    Design: PenetrationAux

  • F15.55

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 3D using a tangential tolerance of for the distance.

    Specification: geomsearch/3d_moving_penetration:pl_test4tt

    Design: PenetrationAux

  • F15.56

    MOOSE shall be capable of computing the distance as well as transfer data between interior boundaries on a 2D domain.

    Specification: geomsearch/2d_interior_boundary_penetration_locator:test

    Design: PenetrationAuxGapValueAux