Implementing Quadrature Module

[zasexton]

Problem

Quadrature rules are still defined through Fortran-style, per-element dispatch tables that hard-code Gauss point counts, weights, and reference coordinates directly into initialization routines. This keeps quadrature setup tightly coupled to mesh storage, basis evaluation, face initialization, and physics assembly. A modular FE/Quadrature folder is therefore necessary because it gives us a single mesh-agnostic interface for reference-element integration rules, plus centralized construction, caching, validation, and compatibility pathways for both existing solver behavior and future finite-element extensions.

• Quadrature setup is implemented as hard-coded element tables. Code/Source/solver/nn_elem_gip.h stores per-element and per-face point/weight data directly in dispatch maps, while Code/Source/solver/nn.cpp allocates and populates solver-facing w and xi arrays procedurally.
• Quadrature state is embedded directly in solver containers rather than represented by reusable rule objects. Code/Source/solver/ComMod.h stores nG, w, xi, xib, shape tables, and quadrature modifiers inside mshType, faceType, and fsType, which makes integration rules hard to test or replace independently.
• Low-order simplex modifiers such as qmTRI3 and qmTET4 are encoded as explicit position-based quadrature rules with documented validity and exactness behavior.
• Higher-order and extensible integration paths are not centralized. Efficient symmetric triangle/tetrahedron rules, tensor-product rules, surface rules, adaptive rules, and future cut or singular integration support should be developed and validated in one module instead of spreading through mesh, basis, geometry, and assembly code.

Solution

To address the current solver’s quadrature infrastructure, we should create a dedicated, mesh-agnostic FE/Quadrature module with a common QuadratureRule interface for reference-space points, weights, polynomial order, reference measure, and stable cache identity. Quadrature rules should be constructed through a factory keyed by element type, requested order, and quadrature family, with caching for reusable rules and explicit compatibility paths for existing solver behavior.

The initial module will migrate quadrature rule infrastructure from a modern FE test branch, including standard Gauss and Gauss-Lobatto rules, tensor-product line/quadrilateral/hexahedron rules, simplex triangle/tetrahedron rules, and wedge rules, surface quadrature helpers, symmetric simplex rules, and position-based TRI3/TET4 rules that preserve qmTRI3 and qmTET4 behavior. The first integration step should provide an adapter that maps legacy consts::ElementType values and existing mesh/face settings into QuadratureRule objects, then fills the current mshType and faceType w/xi arrays. This lets us replace nn_elem_gip.h incrementally without forcing a simultaneous rewrite of assembly loops, which will be a separate and more consequential refactor.

Longer term, mesh and element setup should hold lightweight quadrature rule objects or cache handles rather than hard-coded point arrays, while geometry mapping should remain responsible only for transforming reference-space integration data to physical space. Standard and symmetric rules should become the default path for accuracy-driven integration, while position-based rules should remain an explicit low-order simplex compatibility. With quadrature construction, caching, validation, and testing centralized in FE/Quadrature, the solver can replace current behavior safely while also gaining a robust foundation for future FE assembly refactors (a critical long-term goal of the refactoring efforts).

[ktbolt]

@zasexton An excellent plan !