Over++/BROOMStyx: Multiphysics Simulation Framework

• Over++/BROOMStyx is a declarative framework that formalizes multiphysics simulation by transforming high-level PDE and ODE descriptions into correct-by-construction solvers.
• It employs a layered compilation pipeline with grid templates and pattern-based rewrites to ensure accurate discretization and enforce discrete conservation laws.
• The modular design integrates seamlessly with various backends like OpenFOAM, streamlining solver development for complex coupled physical phenomena.

The Over++/BROOMStyx paradigm for multiphysics simulation centers on formal language and compiler frameworks that elevate the specification, discretization, and implementation of complex coupled physical systems. Recent methodologies, exemplified by the multi-physics compiler of Maxwell III et al., demonstrate an approach where high-level ordinary and partial differential equation (ODE/PDE) descriptions, together with initial and boundary conditions, are transformed into correct-by-construction numerical solvers through an intermediate representation neutral to classical and exterior calculus (III et al., 2023). This layered compilation pipeline addresses the challenges of rapid solver synthesis for emerging multiphysics phenomena, while enforcing immutable physical principles, such as discrete conservation laws, at the implementation level.

1. Intermediate Representation: Grid Templates

The compiler's IR, referred to as "grid templates," facilitates a symbolic and platform-agnostic encoding of PDEs, associated operators, and domain specifications. Geometric elements are explicitly typed:

• $v$: Volumes
• $c$: VolumeCenters (duals of $v$)
• $f$: Faces
• $l$: Lines connecting centers

Operators such as $\nabla$, $\mathrm{div}$, $\mathrm{curl}$, and exterior calculus constructs ($d$, Hodge) are represented as first-class functions within the grid template scheme. Constraint notation, exemplified by

$\partial_t u + \nabla \cdot F(u) = S(u)$

translates directly into grid template syntax, e.g.,

gt.constraint(gt.deriv(u_c) + gt.divergence(F(u_c)), "=", S(u_c))

where $u_c = u(c, t)$ and $c$ is a center-type template variable. This formalism extends to higher-order, user-overridable interpolation templates and supports nested operator expansion.

2. Compilation Pipeline: From Symbolic PDEs to Solvers

The pipeline is characterized by the following sequential stages:

• Specification: Users declare variables, constants, and equation constraints/definitions in DSL form. Discretization heuristics are deferred.
• Template Expansion: Abstract operators are expanded per default or user-modified rules. Operator nesting is resolved by in situ expansion.
• Interpolation/Ambiguity Resolution: Centroid evaluations default to summations over neighboring center variables, with override possibilities for higher-order accuracy or conservation.
• Stencil Generation: Templates are specialized to particular grid geometries (e.g., uniform Cartesian), yielding finite-difference or finite-volume stencils.
• Pattern Matching: Rewrite rules abstract common discrete operations, converting sum-based expressions to high-level operator calls.
• Backend Code Generation: An AST of platform calls (e.g., fvc::div, fvm::laplacian) is translated to solver code, case file declarations, and operator discretization schemes for platforms such as OpenFOAM.

3. Discrete Conservation and Physical Principles

The framework embeds conservation guarantees at the discrete operator level:

• Divergence operators are formulated as flux sums over cell faces, $$\sum_{f \in \partial \mathrm{cell}} \mathrm{flux}(f) / |\mathrm{cell}|$$.
• Orientation terms ensure opposing face contributions cancel, maintaining local and global conservation up to machine precision.
• Exterior calculus is supported through dual pairing of discrete $d$ and Hodge-star operators, systematically preserving integral theorems (Stokes', Gauss') in the discrete topology.
• Templates instantiate these properties directly, obviating the need for ad hoc approximations.

4. Practical Case Study: Two-Phase Flow System

The cited multi-physics compiler demonstrates its philosophy through a two-phase Darcy-flow and phase-transport example:

• Continuous Equations:
  • Pressure Poisson: $\nabla \cdot (\nabla p) = 0$
  • Darcy’s law: $u = -(\kappa/\mu) \nabla p$
  • Phase advection–diffusion:

  $$\partial_t \phi + \nabla \cdot (\phi u) = \nabla \cdot [D \nabla \phi] - \nabla \cdot [\gamma \phi(1-\phi) n],\quad n = \nabla \phi/|\nabla \phi|$$

• Grid Template Specification:

gt.constraint(gt.divergence(gt.gradient(p_c))) gt.definition(u_c, -kappa/mu * gt.gradient(p_c)) gt.constraint(gt.deriv(phi_c) + gt.divergence(u_c*phi_c), "=", gt.divergence(D*gt.gradient(phi_c)) - gt.divergence(gamma*phi_c*(1-phi_c)*n_c))

• Discrete Realization:
  • $\nabla \cdot (\nabla p)$ mapped to fvm::laplacian(p)
  • Advective and diffusive fluxes (fvm::div(flux1, phi), fvm::laplacian(D, phi))
  • Nonlinear sources discretized via fvc::div(var2)

This suggests robust conservation and stability properties are intrinsic to the pipeline, contingent upon central differences (Gauss linear) and explicit/implicit time-stepping schemes that respect Courant–Friedrichs–Lewy (CFL) criteria.

5. Pattern-Based Rewrite and Code Emission

A pattern library enables translation between high-level template expressions and backend-specific operator invocations:

Template Pattern	Backend Call	Example
sum(in(c,∂dual(f)), ?X/2)	interpolation(?X,linear)	Centroid interpolation
sum(in(f,∂dual(c)), (?U⋅normal(f)⋅orientation…))	divergence(?U)	Face-based divergence

Pattern variables bind sub-expressions, generating an abstract syntax tree (AST) of platform-level function calls. The generator outputs solver code and case management files, such as declarations of volScalarField/volVectorField in OpenFOAM, and prescribing discretization schemes (Gauss linear, corrected).

6. Integration and Synergy with Over++/BROOMStyx

Both Over++ and BROOMStyx converge on a declarative, physics-first DSL paradigm for solver synthesis. Key design affinities include:

• Symbolic IR Separation: Physics specification is isolated from discretization and backend choice.
• Template/Pattern Rewrite Engine: Operator expansion and code emission are modular and customizable, supporting platform-agnostic tools.
• Discrete Conservation Emphasis: Flux-based stencils and dual-complex orientations are intrinsic, allowing correct-by-construction guarantees.

Potential integrations involve:

• Adoption of grid templates as front-end IR in Over++ for unified classical/exterior calculus support and overrideable discretization heuristics.
• Sharing of the template-expansion engine as a BROOMStyx plugin, directly inheriting conservation and correctness properties.
• Extension of the pattern library to additional backends (MFEM, PETSc, deal.II) and leveraging auto-generated solver drivers.

A plausible implication is that if incorporated, these compiler techniques would accelerate multiphysics solver development in Over++/BROOMStyx while preserving physical invariants and modular backend targeting. The workflow would synthesize as: Physics DSL → Over++ AST → GridTemplates IR → pattern expansion → platform calls → code generator.

7. Significance and Future Directions

This compiler-based approach to multiphysics simulation, as exemplified by grid templates and pattern-based rewriting, marks a transition toward high-level, automated, and physically rigorous solver synthesis. Discrete conservation laws, embedded dual-complex stencils, and extensible pattern libraries position this methodology as a candidate for broad integration into emerging multiphysics DSL and code-generation ecosystems. The separation of physics from discretization and backend, combined with the ease of template overrides and platform targeting, provides flexibility and robustness for rapidly evolving scientific applications (III et al., 2023).

The integration opportunities with Over++/BROOMStyx suggest both frameworks may serve as foundations for future advances in declarative multiphysics simulation, furthering abstraction, correctness, and modularity in solver development.