refactor(core): CDM+baryon mass radius, one KAccuracy, sigma(R) kernels, stage domains by steven-murray · Pull Request #421 · halomod/hmf

steven-murray · 2026-10-08T00:43:26Z

Summary

The last decided changes to hmf.core before LinearPower (σ8, P(k, z)) and MassFunction. Neither stage is built here. hmf.core is experimental, so there is no deprecation path.

1. Mass ↔ radius always uses the CDM + baryon density

The PowerSource.rho_mean0 protocol is now defined as the CDM + baryon mean density, whatever species the power is. UnnormalisedPower.rho_mean0 (from Transfer.power_kernel(species)) returns rho_mean0(cosmology, "cb") for "tot" too.
TabulatedPower.mean_density is documented as cb.
Docs updated in power_source.py, transfer.py, mass_variance.py (new "Mass and radius" section) and docs/core.rst.
Physical test, for a cosmology with 3 × 0.1 eV neutrinos and every filter:
- the "tot" and "cb" MassVariance give bit-identical R(M);
- that R(M) equals (3M / 4π ρ̄_cb)^{1/3} / c to 1e-12, with ρ̄_cb taken independently from astropy's critical_density0 · Om0;
- the test also checks that ρ̄_tot would differ by more than 1%.

2. One `KAccuracy` drives the k-space calculation

Growth.k_accuracy is a new field (default KAccuracy()). GrowthModel.solve takes k_accuracy, and CambGrowth/ClassGrowth use it for their own runs instead of a hard-coded KAccuracy(). So KAccuracy.high() now switches those runs to high precision.
Growth.from_transfer defaults k_accuracy to the transfer stage's.
A growth stage shares its transfer stage's run only if the two accuracies are equal. Otherwise it makes its own run at its own accuracy.
New accuracy.check_consistent(first, *others):
- it returns the shared KAccuracy, or raises ValueError listing each stage's;
- equal values count as one;
- it comes with a HasKAccuracy protocol.
accuracy.py (a table) and docs/core.rst document which fields each stage reads, and the one-KAccuracy rule. LinearPower will own the KAccuracy.

Which `KAccuracy` fields each stage reads

Stage	Fields	What for
`Transfer`	`dln_k`	CAMB/CLASS precision and k sampling (finer than the code's default below 0.02, plus CAMB `high_precision`). Other models read nothing.
`Growth`	`dln_k`	The same, for a run its CAMB/CLASS growth model makes itself.
`MassVariance`	`dln_k`, `ln_k_min`, `k_max_r_min`	The k grid of the σ integrals.

The effect of each preset:

KAccuracy.high() refines the runs and the σ grid.
fast() and the defaults leave the Boltzmann codes at their own precision.

3. New kernels on `MassVariance`

All of these work in canonical units and check their input with check_extent against valid_domain.

Kernel	Input → output	Notes
`ln_sigma_at_radius_kernel(r)`	r [Mpc/h] → ln σ	Direct evaluation with the stage's filter, power and k grid. No lattice, no memo, and `mass_accuracy.extension` does not apply. Raises `DomainError` where the k grid can't resolve the integral, like the lattice. For σ8: a TopHat `MassVariance` on the normalisation species at R = 8.
`m_from_radius_kernel(r)`	r [Mpc/h] → m [Msun/h]
`radius_from_m_kernel(m)`	m [Msun/h] → r [Mpc/h]	Any m > 0; the lattice range does not apply.
`m_from_sigma_kernel(sigma)`	σ → m [Msun/h]	The body of `m_from_sigma`; the public method now calls it.

New public constant INTERPOLATION_RTOL = 1e-5. It records the existing documented accuracy of the lattice interpolant against direct evaluation at default settings.
Physical tests:
- Power law P ∝ kⁿ with TopHat (n = −2.5, −2). With the documented k_min truncation added back, σ²R^{n+3} is constant and equals the closed form I(n)/2π² to 1e-6. The fitted slope d ln σ / d ln R = −(n+3)/2 to 1e-6. The residual ~1e-6 comes from the top-hat's oscillating tail beyond k_max.
- Direct vs lattice. ln_sigma_at_radius_kernel matches the lattice σ to INTERPOLATION_RTOL, for EH and BAO spectra and all three filters. At lattice nodes they agree to 1e-13.
- Round trips. m → R → m and R → m → R both hold to 1e-12.
- Batch independence, and kernel == public method.

4. Stage domains

MassVariance.valid_domain is instance-level:
- m: > 0, or the default lattice range when mass_accuracy.extension="raise";
- r and sigma: > 0.
TabulatedPower.valid_domain is instance-level:
- k > 0, or the table's range (to round-off) when extension="raise".
Public methods check with Domain.check, kernels with check_extent. The ad-hoc checks (check_finite_positive / check_in_range / the hand-written table and lattice errors) are gone. Messages and inf/NaN handling now match Transfer, Growth, the filters and the fits.
Behaviour change: m_from_radius/radius_from_m now reject r or m that is not finite and > 0. They had no check before.
Message changes:
- error messages for out-of-table k and out-of-lattice m changed format, and tests were updated;
- the where string still names extension='raise'.

5. Two-argument boundary benchmark gate

test_unit_boundary_overhead_gate is parametrised over one and two dimensional arguments.
_wrap_many now takes _wrap_one's identity fast paths: it views canonical Quantities as ndarrays and finishes ndarray outputs inline.

Wrapper	Before	After	Budget
two arguments (`_wrap_many`)	2.64 µs (fails)	1.81 µs (three runs: 1.80–1.83)	2 µs
one argument (`_wrap_one`, unchanged, for reference)	1.30 µs	1.33 µs	2 µs

These numbers are from this container. The margin is ~10%. A specialised loop-free two-argument wrapper measured about 0.3 µs faster, but I kept the generic version.

What `LinearPower` / `MassFunction` will call

Need	Stage → method
σ8 of the unnormalised power	`MassVariance(power=transfer.power_kernel(sigma_8_species), filter=TopHat(), k_accuracy=K).ln_sigma_at_radius_kernel(8.0)`
one accuracy	`accuracy.check_consistent(transfer, growth, mass_variance)` (LinearPower owns `K`)
unnormalised P(k) shape	`Transfer.power_kernel(species).ln_power_kernel(ln_k)` (being renamed to `power_source` in #parallel)
ln σ_raw(m), dlnσ/dlnm	`MassVariance.ln_sigma_and_slope_kernel(m)`
n_eff	`mass_variance.n_eff_kernel(dlnsigma_dlnm)`
m(σ_raw)	`MassVariance.m_from_sigma_kernel(sigma)`
m ↔ R	`MassVariance.m_from_radius_kernel(r)`, `MassVariance.radius_from_m_kernel(m)`
ρ̄ (CDM + baryons)	`power_source.rho_mean0` (any species)
D(z), f(z)	`Growth.growth_factor_kernel(z, species)`, `Growth.growth_rate_kernel(z, species)`
Ω_m(z) (cb)	`_species.omega_m(cosmology, z, "cb")` (becoming public `species` in the parallel PR)
Δ_halo of the fit's mdef	`MeasuredMassDefinition.delta_halo_mean_kernel(omega_m_z)`
f(σ)	`FittingFunction.fsigma_kernel(FitInputs(...))` or `fits.evaluate_fsigma(..., owner=self)`
fit's dn/dm modification	`FittingFunction.modify_dndm_kernel(...)`
domains to inspect	`Transfer`/`Growth` model `valid_domain`, `MassVariance.valid_domain`, `TabulatedPower.valid_domain`, fits' `valid_domain`/`calibration_domain`
δc	open: a field of `MassFunction`

Coordination

This PR conflicts with refactor/core-naming-visibility on these names:

power_kernel → power_source;
_species → species;
window_derivatives → window_derivatives_kernel.

It will merge origin/main (no rebase) and adopt the new names once that PR lands.

Type of change

New feature
Documentation
Maintenance (refactoring, CI, dependencies, etc.)

Checklist

I have

Added or updated tests covering this change.
Updated docstrings and/or docs where relevant.

Checks run locally:

tests/core + tests/regression: 1835 passed;
benchmarks/test_gates.py: 19 passed;
-Werror on the touched test files;
mypy strict: clean;
prek on the changed files: clean;
sphinx-build -W: clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MuqUZzdEaJGwATE9r1ELXo

Generated by Claude Code

Summary by Sourcery

Standardize core k-space accuracy, CDM+baryon mass-radius conversions, kernel APIs, and domain validation across the calculation stages.

New Features:

Add direct sigma-at-radius, mass/radius conversion, and sigma-inversion kernels to MassVariance.
Introduce shared KAccuracy validation and propagate accuracy settings through growth and transfer calculations.
Expose instance-level valid domains for MassVariance and TabulatedPower with consistent domain checking.

Bug Fixes:

Ensure mass-to-radius conversions always use the CDM plus baryon mean density, regardless of power species.
Only reuse transfer Boltzmann runs when transfer and growth accuracies match.

Enhancements:

Standardize stage input validation and error reporting through the domain framework.
Optimize multi-argument unit-boundary wrappers while adding a two-argument performance benchmark gate.
Document k-space accuracy ownership, mass-radius conventions, kernels, and stage domains.

CI:

Extend the unit-boundary benchmark gate to cover both one- and two-argument wrappers.

Documentation:

Update core documentation and API descriptions for CDM+baryon mass-radius conversion, shared KAccuracy, sigma-radius kernels, and stage domains.

Tests:

Add physical, numerical, domain-safety, round-trip, accuracy-sharing, and unit-boundary coverage for the new behavior.

…l arguments _wrap_many converted every dimensional argument through _convert_argument and finished every output through _finish. It now takes the same fast paths as _wrap_one: an argument that is a plain Quantity in exactly its canonical unit is viewed as an ndarray, and a plain ndarray output gets its unit inline. The units-boundary gate in benchmarks/test_gates.py now also measures a method with two dimensional arguments: 2.64 µs per call before, 1.81 µs after (budget 2 µs; the one-argument wrapper measures 1.30 µs on the same machine). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MuqUZzdEaJGwATE9r1ELXo

Growth gains a k_accuracy field (default KAccuracy()), which the CAMB and CLASS growth models use for a run they make themselves, so KAccuracy.high() refines those runs as it does the transfer stage's. Growth.from_transfer takes the transfer stage's k_accuracy, and a growth stage shares its transfer stage's run only when their accuracies are equal. accuracy.py documents which KAccuracy settings each stage reads, and the rule that a composing stage passes one KAccuracy to all of them; check_consistent() checks it (ValueError on a mismatch), for the coming LinearPower stage. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MuqUZzdEaJGwATE9r1ELXo

* A PowerSource's rho_mean0 is the mean density of CDM + baryons, whatever the species of its power: Transfer's power source returns rho_mean0(cosmology, "cb") for "tot" too, so R(M) matches v3 and the fits' calibrations. TabulatedPower documents its mean_density as CDM + baryons. * MassVariance.ln_sigma_at_radius_kernel: sigma at filter radii (Mpc/h), evaluated directly with the stage's filter and power, without the lattice (for sigma_8). It agrees with the lattice to INTERPOLATION_RTOL (1e-5). * MassVariance.m_from_radius_kernel, radius_from_m_kernel and m_from_sigma_kernel, the kernel-level counterparts of the public converters. * MassVariance and TabulatedPower have an instance-level valid_domain (the lattice with mass_accuracy.extension="raise", the table with extension="raise"). Their public methods check it with Domain.check and their kernels with check_extent, so every stage reports out-of-domain input the same way. m_from_radius and radius_from_m now reject masses and radii that are not finite and > 0. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MuqUZzdEaJGwATE9r1ELXo

sourcery-ai · 2026-10-08T00:43:30Z

Sorry @steven-murray, you've used your own review budget of 250,000 diff characters for the last 7 days.

You can request another review in 2 days and 18 hours by commenting @sourcery-ai review. Upgrade to get a review now.

sourcery-ai · 2026-10-08T00:43:44Z

Reviewer's Guide

This PR refactors core stage composition around a single KAccuracy, makes all mass–radius conversions use CDM+baryon density, adds direct MassVariance kernels and explicit stage domains, and unifies unit-boundary handling with multi-argument performance coverage; documentation and extensive physical, domain, numerical, and regression tests are updated accordingly.

Sequence diagram for accuracy-aware growth construction

sequenceDiagram
    participant Transfer
    participant Growth
    participant GrowthModel
    participant Boltzmann
    Transfer->>Growth: from_transfer(transfer)
    Growth->>Growth: copy transfer.k_accuracy
    Growth->>GrowthModel: solve(cosmology, k_accuracy)
    alt matching backend and k_accuracy
        GrowthModel->>Transfer: reuse boltzmann_run
        Transfer-->>GrowthModel: shared run
    else accuracy or backend differs
        GrowthModel->>Boltzmann: run(cosmology, k_accuracy)
        Boltzmann-->>GrowthModel: growth solution
    end

Entity relationship diagram for CDM+baryon mass-radius mapping

erDiagram
    POWER_SOURCE {
        float rho_mean0_cb
        string species_power
    }
    MASS_VARIANCE {
        float mass_assignment
        float mass
        float radius
    }
    POWER_SOURCE ||--|| MASS_VARIANCE : sets
    MASS_VARIANCE }o--|| POWER_SOURCE : uses_rho_mean0_cb

Flow diagram for MassVariance radius and sigma kernels

flowchart LR
    R[r > 0] --> S["ln_sigma_at_radius_kernel(r)"]
    R --> M["m_from_radius_kernel(r)"]
    Mv[m > 0] --> RR["radius_from_m_kernel(m)"]
    Sv[sigma > 0] --> MS["m_from_sigma_kernel(sigma)"]
    S --> D[Direct sigma integral on k grid]
    M --> CB[CDM+baryon rho_mean0]
    RR --> CB
    S --> V[check_extent against valid_domain]
    M --> V
    RR --> V
    MS --> V

File-Level Changes

Change	Details	Files
Standardize mass–radius conversion on CDM+baryon density across power species.	Redefine the PowerSource density contract and update transfer/tabulated implementations and documentation. Add massive-neutrino tests proving cb/tot radius identity and independent density agreement.	`src/hmf/core/power_source.py` `src/hmf/core/transfer.py` `src/hmf/core/mass_variance.py` `tests/core/test_core_mass_variance.py` `tests/core/test_core_power_source.py` `docs/core.rst`
Make KAccuracy the shared precision control for transfer, growth, and mass-variance stages.	Add Growth.k_accuracy and propagate it through GrowthModel.solve and CAMB/CLASS-owned runs. Share transfer Boltzmann runs only when backend and KAccuracy match. Add check_consistent and document stage-specific KAccuracy field usage.	`src/hmf/core/accuracy.py` `src/hmf/core/growth.py` `src/hmf/core/growth_models.py` `tests/core/test_core_accuracy.py` `tests/core/test_core_boltzmann.py` `docs/core.rst`
Add direct sigma-radius and mass/radius/sigma conversion kernels to MassVariance.	Implement direct sigma(R), mass-from-radius, radius-from-mass, and kernel-level mass-from-sigma APIs with array-shape preservation. Expose INTERPOLATION_RTOL and retain the public m_from_sigma implementation through its kernel. Cover power-law scaling, lattice agreement, round trips, batch independence, and kernel/public parity.	`src/hmf/core/mass_variance.py` `tests/core/test_core_mass_variance.py`
Unify stage input validation around instance-level Domain definitions.	Define MassVariance and TabulatedPower valid_domain properties for positive inputs and configured lattice/table bounds. Replace ad-hoc finite, range, and custom boundary checks with Domain.check and check_extent. Update behavior and error-message tests, including strict validation of mass/radius conversions.	`src/hmf/core/mass_variance.py` `src/hmf/core/power_source.py` `tests/core/test_core_kernel_safety.py` `tests/core/test_core_mass_variance.py` `tests/core/test_core_power_source.py`
Optimize and broaden unit-boundary performance coverage for multi-argument methods.	Add canonical-Quantity ndarray fast paths and inline ndarray return handling to _wrap_many. Parameterize the benchmark gate for one- and two-dimensional argument wrappers. Add tests for canonical fast paths, conversions, scalar outputs, and invalid units.	`src/hmf/core/units.py` `benchmarks/test_core_units.py` `benchmarks/test_gates.py` `tests/core/test_core_units.py`

Tips and commands

Interacting with Sourcery

Trigger a new review: Comment @sourcery-ai review on the pull request.
Continue discussions: Reply directly to Sourcery's review comments.
Generate a GitHub issue from a review comment: Ask Sourcery to create an
issue from a review comment by replying to it. You can also reply to a
review comment with @sourcery-ai issue to create an issue from it.
Generate a pull request title: Write @sourcery-ai anywhere in the pull
request title to generate a title at any time. You can also comment
@sourcery-ai title on the pull request to (re-)generate the title at any time.
Generate a pull request summary: Write @sourcery-ai summary anywhere in
the pull request body to generate a PR summary at any time exactly where you
want it. You can also comment @sourcery-ai summary on the pull request to
(re-)generate the summary at any time.
Generate reviewer's guide: Comment @sourcery-ai guide on the pull
request to (re-)generate the reviewer's guide at any time.
Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
pull request to resolve all Sourcery comments. Useful if you've already
addressed all the comments and don't want to see them anymore.
Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
request to dismiss all existing Sourcery reviews. Especially useful if you
want to start fresh with a new review - don't forget to comment
@sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

Enable or disable review features such as the Sourcery-generated pull request
summary, the reviewer's guide, and others.
Change the review language.
Add, remove or edit custom review instructions.
Adjust other review settings.

Getting Help

Contact our support team for questions or feedback.
Visit our documentation for detailed guides and information.
Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

github-actions · 2026-10-08T00:45:44Z

Bencher Report

Project	hmf
Branch	refactor/core-step3-decisions
Testbed	ubuntu-latest

Click to view all benchmark results

Benchmark	Latency	Benchmark Result microseconds (µs) (Result Δ%)	Upper Boundary microseconds (µs) (Limit %)
benchmarks/test_construction.py::test_default_cached_dndm	📈 view plot 🚷 view threshold	2.07 µs (-16.41%) Baseline: 2.48 µs	4.21 µs (49.12%)
benchmarks/test_construction.py::test_default_construct	📈 view plot 🚷 view threshold	382,067.15 µs (-21.44%) Baseline: 486,328.02 µs	800,777.43 µs (47.71%)
benchmarks/test_construction.py::test_default_construct_and_dndm	📈 view plot 🚷 view threshold	383,645.07 µs (-21.07%) Baseline: 486,028.86 µs	797,927.36 µs (48.08%)
benchmarks/test_construction.py::test_default_first_dndm	📈 view plot 🚷 view threshold	79.32 µs (-15.06%) Baseline: 93.38 µs	144.29 µs (54.97%)
benchmarks/test_construction.py::test_eh_construct_and_dndm	📈 view plot 🚷 view threshold	48,075.01 µs (-23.25%) Baseline: 62,636.66 µs	119,449.24 µs (40.25%)
benchmarks/test_construction.py::test_get_hmf_z	📈 view plot 🚷 view threshold	467,354.74 µs (-17.42%) Baseline: 565,962.68 µs	935,879.67 µs (49.94%)
benchmarks/test_construction.py::test_import[import_hmf]	📈 view plot 🚷 view threshold	947,364.18 µs (-14.52%) Baseline: 1,108,302.49 µs	1,701,255.43 µs (55.69%)
benchmarks/test_construction.py::test_import[python]	📈 view plot 🚷 view threshold	14,093.40 µs (-15.25%) Baseline: 16,628.41 µs	24,878.02 µs (56.65%)
benchmarks/test_construction.py::test_introspection[get_all_parameter_defaults]	📈 view plot 🚷 view threshold	431.03 µs (-17.12%) Baseline: 520.07 µs	852.15 µs (50.58%)
benchmarks/test_construction.py::test_introspection[get_all_parameter_names]	📈 view plot 🚷 view threshold	221.16 µs (-23.61%) Baseline: 289.52 µs	477.80 µs (46.29%)
benchmarks/test_construction.py::test_introspection[parameter_info]	📈 view plot 🚷 view threshold	344.14 µs (-16.15%) Baseline: 410.44 µs	670.75 µs (51.31%)
benchmarks/test_construction.py::test_introspection[quantities_available]	📈 view plot 🚷 view threshold	412.07 µs (-24.43%) Baseline: 545.31 µs	913.63 µs (45.10%)
benchmarks/test_core_units.py::test_unit_boundary_overhead[canonical]	📈 view plot 🚷 view threshold	9,558.86 µs (-31.61%) Baseline: 13,977.53 µs	24,664.86 µs (38.75%)
benchmarks/test_core_units.py::test_unit_boundary_overhead[physical]	📈 view plot 🚷 view threshold	22,119.40 µs (-30.57%) Baseline: 31,859.34 µs	55,552.47 µs (39.82%)
benchmarks/test_core_units.py::test_unit_boundary_overhead[undecorated]	📈 view plot 🚷 view threshold	426.82 µs (-23.88%) Baseline: 560.70 µs	996.83 µs (42.82%)
benchmarks/test_derived.py::test_halofit_after_z_change	📈 view plot 🚷 view threshold	770.16 µs (-30.28%) Baseline: 1,104.70 µs	2,144.24 µs (35.92%)
benchmarks/test_derived.py::test_halofit_first	📈 view plot 🚷 view threshold	1,062.40 µs (-16.65%) Baseline: 1,274.63 µs	2,235.46 µs (47.52%)
benchmarks/test_derived.py::test_mass_conversion_first	📈 view plot 🚷 view threshold	83,779.91 µs (-23.77%) Baseline: 109,905.12 µs	207,141.34 µs (40.45%)
benchmarks/test_derived.py::test_mass_conversion_z_loop	📈 view plot 🚷 view threshold	416,208.35 µs (-24.87%) Baseline: 553,950.73 µs	1,041,016.03 µs (39.98%)
benchmarks/test_scans.py::test_fit_scan	📈 view plot 🚷 view threshold	5,861.78 µs (-19.91%) Baseline: 7,319.24 µs	13,285.98 µs (44.12%)
benchmarks/test_scans.py::test_n_scan	📈 view plot 🚷 view threshold	93,188.24 µs (-37.90%) Baseline: 150,062.91 µs	271,219.68 µs (34.36%)
benchmarks/test_scans.py::test_sigma8_scan	📈 view plot 🚷 view threshold	7,434.31 µs (-21.72%) Baseline: 9,496.81 µs	17,562.00 µs (42.33%)
benchmarks/test_scans.py::test_wdm_z_loop	📈 view plot 🚷 view threshold	10,881.62 µs (-20.54%) Baseline: 13,694.08 µs	25,414.10 µs (42.82%)
benchmarks/test_scans.py::test_z_loop_dndm	📈 view plot 🚷 view threshold	10,560.08 µs (-20.83%) Baseline: 13,338.91 µs	24,917.57 µs (42.38%)
benchmarks/test_scans.py::test_z_loop_ngtm	📈 view plot 🚷 view threshold	35,568.41 µs (-18.77%) Baseline: 43,786.74 µs	76,852.63 µs (46.28%)

🐰 View full continuous benchmarking report in Bencher

codecov · 2026-10-08T00:45:51Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.57%. Comparing base (e49c47b) to head (3ed5d5c).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #421   +/-   ##
=======================================
  Coverage   99.57%   99.57%           
=======================================
  Files          59       59           
  Lines        7210     7279   +69     
=======================================
+ Hits         7179     7248   +69     
  Misses         31       31

☔ 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.

claude added 3 commits October 8, 2026 00:42

steven-murray added type: maint: refactoring Refactoring type: accuracy Enhancement that improves accuracy labels Oct 8, 2026 — with Claude

github-actions Bot added the type: maint: documentation Improvements or additions to documentation label Oct 8, 2026

Navigation Menu

Repository navigation

refactor(core): CDM+baryon mass radius, one KAccuracy, sigma(R) kernels, stage domains - #421

refactor(core): CDM+baryon mass radius, one KAccuracy, sigma(R) kernels, stage domains#421
steven-murray wants to merge 3 commits into
mainfrom
refactor/core-step3-decisions

steven-murray commented Oct 8, 2026 •

edited by sourcery-ai Bot

Loading

Uh oh!

sourcery-ai Bot commented Oct 8, 2026

Uh oh!

sourcery-ai Bot commented Oct 8, 2026

Interacting with Sourcery

Customizing Your Experience

Getting Help

Uh oh!

github-actions Bot commented Oct 8, 2026

Uh oh!

codecov Bot commented Oct 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

steven-murray commented Oct 8, 2026 • edited by sourcery-ai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

1. Mass ↔ radius always uses the CDM + baryon density

2. One KAccuracy drives the k-space calculation

Which KAccuracy fields each stage reads

3. New kernels on MassVariance

4. Stage domains

5. Two-argument boundary benchmark gate

What LinearPower / MassFunction will call

Coordination

Type of change

Checklist

Summary by Sourcery

Uh oh!

sourcery-ai Bot commented Oct 8, 2026

Uh oh!

sourcery-ai Bot commented Oct 8, 2026

Reviewer's Guide

Sequence diagram for accuracy-aware growth construction

Entity relationship diagram for CDM+baryon mass-radius mapping

Flow diagram for MassVariance radius and sigma kernels

File-Level Changes

Interacting with Sourcery

Customizing Your Experience

Getting Help

Uh oh!

github-actions Bot commented Oct 8, 2026

Bencher Report

Uh oh!

codecov Bot commented Oct 8, 2026

Codecov Report

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

steven-murray commented Oct 8, 2026 •

edited by sourcery-ai Bot

Loading

2. One `KAccuracy` drives the k-space calculation

Which `KAccuracy` fields each stage reads

3. New kernels on `MassVariance`

What `LinearPower` / `MassFunction` will call