Skip to content

Make the quadrature scheme the configuration choice#728

Draft
haakon-e wants to merge 1 commit into
he/implicit-Tfrom
he/quadrature-choice
Draft

Make the quadrature scheme the configuration choice#728
haakon-e wants to merge 1 commit into
he/implicit-Tfrom
he/quadrature-choice

Conversation

@haakon-e

@haakon-e haakon-e commented Jun 14, 2026

Copy link
Copy Markdown
Member

Make the quadrature scheme the configuration choice

Motivation

The P3 size-distribution integrals (deposition and sublimation, melting, riming, ice-rain collection, sedimentation) were configured through a single integer quadrature_order knob. build_quadrature then mapped a magic set of orders, {16, 32, 40, 64}, to Gauss-Legendre and silently fell back to Chebyshev-Gauss for every other order. That coupling makes the knob misleading: the order selects the scheme as a side effect, so a caller who lowers the order from 40 to 36 to trade a little accuracy for speed silently switches integration rules and changes the error characteristics in a way the knob name does not suggest. The two attributes being conflated, the scheme and its order, are independent choices.

What changed

The quadrature scheme is now the explicit configuration value, passed as a scheme instance that carries its own parameters, the order among them:

Microphysics2MParams(FT; with_ice = true,
    quadrature = Quadrature.GaussLegendre(40))

build_quadrature is reduced to materializing the chosen scheme in the working float type. Chebyshev-Gauss has closed-form nodes and passes through unchanged; Gauss-Legendre is rebuilt so its stored nodes and weights adopt FT, since a Float64 rule would leak Float64 into Float32 collision integrals. This is host-side and one-shot, and the result is isbits and reused in the GPU hot loop with no per-call construction, as before.

The default is Chebyshev-Gauss at order 100, which reproduces the previous default behavior exactly (the old default order of 100 was not in the Gauss-Legendre magic set, so it already resolved to Chebyshev-Gauss). The documentation now states the scheme tradeoff directly: at matched order Gauss-Legendre is substantially more accurate on the smooth P3 integrands, roughly a factor of 20 lower error on the dominant ice-rain collision integral, while Chebyshev-Gauss remains the conservative default; the cusp-limited ice self-collection diagonal is quadrature-limited under either scheme.

Breaking change

The quadrature_order keyword argument to Microphysics2MParams and P3IceParams is removed and replaced by the quadrature keyword, which takes a scheme instance. Callers passing quadrature_order must switch to quadrature = Quadrature.ChebyshevGauss(n) or Quadrature.GaussLegendre(n). Callers relying on the implicit order-to-scheme mapping (e.g. expecting order 40 to mean Gauss-Legendre) must now name the scheme explicitly. The default behavior is unchanged.

Testing

The bulk-tendencies quadrature tests are updated to construct schemes explicitly and to cover both the pass-through (Chebyshev-Gauss) and the FT-rebuild (Gauss-Legendre) paths of build_quadrature.

The P3 size-distribution quadrature was configured through a single
quadrature_order knob, with build_quadrature silently mapping a magic
set of orders {16, 32, 40, 64} to GaussLegendre and everything else to
ChebyshevGauss. The scheme — with its parameters, notably the order —
is now the explicit choice: pass a scheme instance,

    Microphysics2MParams(FT; with_ice = true,
        quadrature = Quadrature.GaussLegendre(40))

and build_quadrature only materializes it in the working float type
(GaussLegendre nodes are rebuilt in FT; ChebyshevGauss is closed-form
and passes through). The default ChebyshevGauss(100) preserves the
previous default behavior.
@haakon-e haakon-e changed the base branch from he/rosenbrock-2m-p3 to he/implicit-T June 14, 2026 04:08
@haakon-e haakon-e force-pushed the he/quadrature-choice branch from aaf6093 to 603d7a2 Compare June 14, 2026 04:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant