FE Quadrature Phase 02: bounded Gaussian line generators

[zasexton]

Current situation

Phase 01 (#593) introduced the concrete QuadratureRule value type, but the module does not yet provide generators for Gaussian line rules. This PR implements Phase 02 of
#580 by adding Gauss-Legendre and Gauss-Lobatto-Legendre generators on [-1, 1].

Both functions accept signed int requested_exactness and return a complete QuadratureRule by value with at least that exactness. Each family owns its conversion to the smallest sufficient point count; future selectors do not need to duplicate these formulas or infer exactness limits from point limits. These line rules provide factors for later element generators. Existing solver quadrature tables and consumers are unchanged.

Newton refinement computes the Legendre polynomial roots or stationary points needed to support each requested size. The implementation uses a three-term recurrence and analytic derivatives, computes one half of the samples, and
mirrors them into increasing order. Refinement has a defensive 100-iteration bound. Correction and measure tolerances are 64 * epsilon and 32 * 128 * epsilon, respectively, where epsilon is std::numeric_limits<double>::epsilon(); both are qualified over every supported point count. Invalid exactness requests raise InvalidArgumentException before
point-count conversion or sample allocation; unsuccessful refinement or numerical validation raises ConvergenceException. Failed weights are never rescaled to force the reference measure.

Release Notes

• Add make_gauss_legendre_rule(int requested_exactness) for requests 0..255, using integer division n = requested_exactness / 2 + 1 to select 1 through 128 interior points with actual exactness 2n - 1.
• Add make_gauss_lobatto_rule(int requested_exactness) for requests 0..253, using n = requested_exactness / 2 + 2 to select 2 through 128 points, including both endpoints exactly, with actual exactness 2n - 3.
• Accept degree zero and preserve actual returned exactness: requests 4 and 5 both produce degree-5 rules, using three Gauss points or four Lobatto points.
• Expose constexpr noexcept capacity queries max_gauss_legendre_exactness() returning 255 and max_gauss_lobatto_exactness() returning 253. The internal 128-point ceiling is a project support bound that limits construction cost and downstream product-rule growth, not a mathematical or convergence limit.
• Return ordered, symmetric samples with positive weights, exact odd-rule centers, and the correct reference measure within the documented tolerance.

Documentation

The two public headers document supported request ranges, integer-division conversion formulas, at-least-requested semantics, degree-zero behavior, actual metadata, ordering, endpoints, capacity rationale, and exception semantics in
the existing FE_Quadrature Doxygen group. Implementation and test comments explain the numerical tolerances and qualification strategy.

The PR contains only the two generator headers, their implementations, and test_QuadratureGenerators.cpp. Current upstream's svmp_fe_quadrature target and unit-test discovery include these files without CMake edits.

Testing

The eight focused tests cover:

• Canonical low-order fixtures, degree-zero minimum counts, and returned exactness greater than an even request.
• Every supported request: all 256 Gauss-Legendre degrees and all 254 Lobatto degrees, selecting 128 and 127 distinct rules respectively. Both even and odd requests check point counts, actual metadata, ordering, containment, symmetry, positive weights, exact assigned coordinates, and reference measure.
• All advertised analytic monomial moments for both request parities: 65,536 checks using compensated long-double accumulation, plus first-unadvertised-degree checks for small rules.
• Supported upper boundaries, first unsupported degrees, negative requests, integer extremes, and exception diagnostics.
• Representative Lobatto node comparisons with the independent Basis implementation, with the cross-module dependency confined to test code.
• svmp_fe_quadrature, run_all_unit_tests, and svmultiphysics built successfully with the revised API.
• All eight generator tests passed across four suites.
• All 17 Quadrature tests passed across seven suites.
• All 260 unit tests passed across 35 suites.

Code of Conduct & Contributing Guidelines

• I agree to follow the Code of Conduct and Contributing Guidelines.

[codecov]

Codecov Report

❌ Patch coverage is 86.75799% with 58 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.98%. Comparing base (d18b323) to head (af36aa4).

Files with missing lines	Patch %	Lines
...ce/solver/FE/Quadrature/GaussLobattoQuadrature.cpp	81.98%	20 Missing ⚠️
...tTests/FE/Quadrature/test_QuadratureGenerators.cpp	91.34%	20 Missing ⚠️
...de/Source/solver/FE/Quadrature/GaussQuadrature.cpp	81.25%	18 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #645      +/-   ##
==========================================
+ Coverage   72.88%   72.98%   +0.09%     
==========================================
  Files         272      275       +3     
  Lines       40148    40599     +451     
  Branches     6718     6761      +43     
==========================================
+ Hits        29263    29630     +367     
- Misses      10663    10748      +85     
+ Partials      222      221       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[michelebucelli]

Thanks @zasexton! I left some comments below.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[michelebucelli]

Thanks @zasexton, I did another pass and left only a few minor comments.

They all relate to avoid using static_cast when the cast would be safely done implicitly anyways: this code is already pretty low-level, so I believe it benefits from being as noiseless as possible, and I feel that many static_casts may hinder readability in a few places (especially when the implicit cast is the one that you would naturally expect to take place).

Other than that, looks good to me.

[michelebucelli]

I think the cast from size_t to int is implicit, and we don't need static_cast here.

Having said that, maybe half_root_index can also be made unsigned (seeing as it is an index, as per its name).

[michelebucelli]

Same as before, the static_cast can probably be dropped.

[michelebucelli]

Same as above for both these static_casts. For the comparison expression, the narrower type (double) will be implicitly converted to the wider one (long double), so the cast adds noise without having any effect, I believe.

[michelebucelli]

Same as above, even though here the case is actually a bit more subtle. If you want to be safe against overflow, you can change this to 2 * static_cast<int>(num_points) - 3, but I don't really think it's necessary (I assume that by this point if this number were to come out negative some other exception would have fired).

[michelebucelli]

Similar comment about static_casts here and in the rest of this file.