Source-linked AI summary
MOOSE: Enabling Massively Parallel Multiphysics Simulation
Cody J. Permann, Derek R. Gaston, David Andrs, Robert W. Carlsen, Fande Kong, Alexander D. Lindsay, Jason M. Miller, John W. Peterson, Andrew E. Slaughter, Roy H. Stogner, Richard C. Martineau
TL;DR
Complex multiphysics simulations are difficult to develop because they combine diverse physics, scales, and parallel computation. MOOSE provides modular interfaces and reusable components that hide solver details while supporting coupled multiscale applications. The framework has demonstrated broad scalability and use across scientific and engineering domains.
Problem
Developing complex multiphysics software is difficult because separate tools, diverse collaborators, and modern parallel computing create time-consuming and error-prone integration challenges.
Method
MOOSE uses extensible interfaces, inheritance, automatic differentiation, hybrid parallelism, and MultiApp data transfers to compose reusable physics and coupled multiscale applications.
Results
MOOSE supports applications solving PDEs with tens of billions of unknowns on tens of thousands of processors and has been used across numerous science and engineering domains.
Takeaways & Limitations
MOOSE provides a common platform for shareable multiphysics applications that can be coupled without modification and extended across research teams.
Takeaways & Limitations
Trust in MOOSE depends partly on its reliance on established external tools such as libMesh and PETSc, alongside peer review and SQA audits.
Abstract
from arXiv · showhide
Harnessing modern parallel computing resources to achieve complex multi-physics simulations is a daunting task. The Multiphysics Object Oriented Simulation Environment (MOOSE) aims to enable such development by providing simplified interfaces for specification of partial differential equations, boundary conditions, material properties, and all aspects of a simulation without the need to consider the parallel, adaptive, nonlinear, finite-element solve that is handled internally. Through the use of interfaces and inheritance, each portion of a simulation becomes reusable and composable in a manner that allows disparate research groups to share code and create an ecosystem of growing capability that lowers the barrier for the creation of multiphysics simulation codes. Included within the framework is a unique capability for building multiscale, multiphysics simulations through simultaneous execution of multiple sub-applications with data transfers between the scales. Other capabilities include automatic differentiation, scaling to a large number of processors, hybrid parallelism, and mesh adaptivity. To date, MOOSE-based applications have been created in areas of science and engineering such as nuclear physics, geothermal science, magneto-hydrodynamics, seismic events, compressible and incompressible fluid flow, microstructure evolution, and advanced manufacturing processes.
1. Motivation and significance
MOOSE addresses the difficulty of building parallel multiphysics software by providing a framework that simplifies physics and material definitions while supporting collaboration across disciplines.
- MOOSE replaces ad hoc connections among separate simulation tools with a plug-in infrastructure for defining physics, material properties, and postprocessing.
2. Software description
MOOSE combines modular software architecture with parallel, automatic-differentiation, multiscale, restart, and platform-support capabilities. Its interfaces and inheritance let developers build reusable physics components and integrate independently developed applications.
- Software architecture: MOOSE organizes simulation functionality into extensible systems connected through interfaces, with application developers inheriting C++ base classes and overriding methods.Approximately 40 systems cover PDE terms, material properties, and in-situ postprocessing.
- Software architecture: Kernel and BoundaryCondition systems define volumetric and surface integral terms arising from the finite-element weak form.
- Software architecture: A single advection Kernel can operate in 1D, 2D, or 3D, use fields from other equations, applications, or experiments, and run from one to 100,000 processors without modification.The object can be reused and tested without recoding it.
- Software architecture: Material properties can be nonlinear, depend on PDE variables, propagate derivatives through automatic differentiation, and be shared through tracked producer/consumer dependencies.
- Parallelism: MOOSE uses hybrid MPI and optional on-node threading, mesh pre-splitting, and scalable parallel I/O preparation to support very large simulations.Pre-splitting has kept per-core memory reasonable for billion-element meshes, and scalability has been demonstrated beyond 30,000 processor cores.
- Automatic differentiation: Forward-mode automatic differentiation lets developers implement residual statements instead of separately generating Jacobians or preconditioners, reducing implementation burden.
- Sub-applications: MultiApp and Transfer systems combine independently developed applications into coupled multiscale simulations without additional linking code.
- Platform capabilities: Restart infrastructure stores simulation state in memory or checkpoint files for recovery, iterative multi-application solves, and multistage initialization.
3. Illustrative Example
MOOSE demonstrates coupled engineering- and microstructure-scale simulation for a thermo-mechanical porous-flow problem. Microstructure degradation changes effective thermal conductivity, which is fed back into the engineering-scale calculation until steady state.
- The illustrative problem couples porous-flow physics at an engineering scale with microstructure calculations resolving degradation of closely packed steel spheres.The engineering-scale model uses Darcy’s equation and a fully coupled Newton-based solve for pressure, temperature, and thermally induced strain.
- Microstructure calculations use engineering-scale temperature to compute steel-sphere degradation and then derive the changed geometry’s effective thermal conductivity.
- The resulting effective thermal conductivity is linearly interpolated into the engineering-scale heat-conduction calculation, with the coupled steps repeated until steady state.
- After 58 seconds of simulation, Figure 2 reports engineering-scale temperature, degraded microstructure geometry, and effective thermal conductivity over time.
4. Impact
MOOSE targets shortcomings in scientific software development by promoting reuse, trusted infrastructure, and shareable multiphysics applications. The framework is used across government, industry, and universities for diverse coupled simulations.
- Scientists and engineers spend approximately 30% of their time writing code, while weak reuse practices can lead to repeated development of opaque software.
- MOOSE builds on libMesh and PETSc and has undergone multiple peer reviews and Software Quality Assurance audits.
- MOOSE provides a common open-source platform for comprehensive multiphysics applications that are shareable and can be coupled without modification.Applications are used by governments, private industry, and universities internationally.
5. Conclusions
MOOSE enables scalable multiphysics application development by hiding parallel, finite-element, and solver implementation details behind a modular framework. Its reusable design supports simulations ranging from serial execution to hundreds of thousands of processes.
- MOOSE lets scientists develop scalable applications without handling parallel, finite-element, or solver implementation details.
- Its modular design makes applications easier to combine, encouraging reuse and simplifying multiscale, multiphysics simulation construction.
- The framework supports PDEs with tens of billions of unknowns on tens of thousands of processors.
- MOOSE development targets robust, high-performance solution algorithms across scales from serial execution to hundreds of thousands of processes.
Current code version
Table 1 is identified as code metadata and marked mandatory.
- Table 1 contains code metadata.
- The code metadata table is labeled Table 1.
- The table's metadata is mandatory.