Missing input validation across light & mass profiles

[rhayes777]

Title: Missing input validation across light & mass profiles

Repo: Jammy2211/PyAutoGalaxy

Tag: @Jammy2211

---

Four small validation gaps in lp.* / mp.* constructors. Each turns a clear
"invalid parameter" into a numba / NumPy traceback. Found while auditing
autogalaxy == 2026.5.21.1.

B9. NFW(scale_radius=0) produces an all-NaN deflection field

import autolens as al, numpy as np
grid = al.Grid2D.uniform(shape_native=(40, 40), pixel_scales=0.05)
m = al.mp.NFW(centre=(0, 0), kappa_s=0.1, scale_radius=0.0)
defl = m.deflections_yx_2d_from(grid=grid)
np.isnan(np.array(defl)).sum()    # 3200 (= 40 × 40 × 2)

B10. Isothermal(ell_comps=(0, 0)) ≠ IsothermalSph numerically

grid = al.Grid2D.uniform(shape_native=(20, 20), pixel_scales=0.05)
ell  = al.mp.Isothermal(centre=(0, 0), ell_comps=(0.0, 0.0), einstein_radius=1.0)
sph  = al.mp.IsothermalSph(centre=(0, 0), einstein_radius=1.0)
diff = np.abs(
    np.array(ell.deflections_yx_2d_from(grid=grid))
    - np.array(sph.deflections_yx_2d_from(grid=grid))
).max()
# 2.357e-06

They're analytically identical; presumably the Ell form goes through a
slightly different evaluation path even at the degenerate point. Not
load-bearing for science, but worth a regression unit test.

B11. Sersic(sersic_index=0) raises ZeroDivisionError

al.lp.Sersic(intensity=1.0, effective_radius=0.5, sersic_index=0.0)\
    .image_2d_from(grid=grid)
# ZeroDivisionError: float division by zero (from deep in the profile)

Rather than a ValueError("sersic_index must be > 0") from the constructor.

B12. |ell_comps| > 1 silently accepted on light profiles

al.lp.Sersic(centre=(0, 0), ell_comps=(2.0, 0.0),
             intensity=1.0, effective_radius=0.5, sersic_index=4
).image_2d_from(grid=grid)
# returns a finite, non-physical image

e1**2 + e2**2 < 1 is the definition of a valid axis ratio; outside that
range the underlying $q$ is undefined.

Suggested fix shape

Either a shared _validate_ell_comps() helper called from every elliptical
profile constructor, or a slot-level @field_validator if the profiles are
already attrs / pydantic dataclasses. For Sersic.sersic_index and
NFW.scale_radius, a plain if value <= 0: guard.

Environment

• autogalaxy == 2026.5.21.1, Python 3.12.8.

Full repro at work/edge_case_tests/02_profiles.py and
work/edge_case_tests/10_final_edges.py in the audit workspace.

[Jammy2211]

Thanks @rhayes777, and apologies for the long silence here — this deserved a reply a lot sooner.

I've re-run all four against current main (autogalaxy @ f0b65f39) and every one still reproduces:

• B9 — NFW(kappa_s=0.1, scale_radius=0.0).deflections_yx_2d_from(...) on a 40x40 grid gives 3200 NaNs out of 3200 values. The entire deflection field is NaN, silently.
• B10 — Isothermal(ell_comps=(0.0, 0.0)) vs IsothermalSph, max absolute deflection difference 2.3570e-06 — your figure exactly.
• B11 — Sersic(sersic_index=0.0).image_2d_from(...) raises ZeroDivisionError: float division by zero.
• B12 — Sersic(ell_comps=(2.0, 0.0), ...) returns a finite, wholly non-physical image (sum 1296.05 on a 40x40 grid, all values finite).

Your framing of these as separate classes is right, and it's how we're going to treat them. B9, B11 and B12 are constructor-validation gaps — scale_radius > 0, sersic_index > 0, and e1**2 + e2**2 < 1 are all cheap guards that turn a numba/NaN mystery into a one-line message. B10 is a different animal: as you say it isn't load-bearing for science, and 2.4e-06 is a numerical path difference at the degenerate point rather than a correctness bug. We'll pin it with a regression test at an explicit tolerance rather than try to force bit-identity between the elliptical and spherical evaluation paths.

On the fix shape — a shared _validate_ell_comps() called from the elliptical constructors is what we'll do, with plain positivity guards for scale_radius and sersic_index.

Thanks also for the offer to PR. We're going to take these in-house: the profile constructors are on JAX-traced paths, and getting guards that stay correct under tracing (and cost nothing when traced) is fiddly enough that it isn't a fair hand-off.

Tracked alongside the rest of your audit (PyAutoArray#332, PyAutoArray#333, PyAutoLens#531, PyAutoLens#532) as one campaign — I'll link the tracking issue here shortly and update as fixes land.

[Jammy2211]

As promised above — the tracking issue for this campaign is
PyAutoLabs/PyAutoArray#415, which carries the verification evidence for all 16
findings and the phase breakdown. Watch that one for overall progress; I'll keep
updating this thread as the parts touching it land.

Phase 1 (the three crash-level findings, which is where we're starting) is
PyAutoLabs/PyAutoArray#416.

[Jammy2211]

Fixed and merged in #566 (a366f77). Thanks @rhayes777 — all four findings closed.

• B9 scale_radius — guarded across the whole halo family (5 assignment sites, 29 dark profile classes), not just NFW. The zero case was the nastiest of the four: it returned all-NaN deflections rather than raising, so the profile looked like it worked.
• B11 sersic_index — guarded at both AbstractSersic bases, so the stellar mass Sersic is covered too, not only the light profile.
• B12 ell_comps — one guard at EllProfile. It turns out ell_comps has exactly one assignment site in the codebase, so your "not a copy per subclass" point was straightforward to honour: every elliptical light and mass profile is covered by that single call. |e| == 1 is rejected along with |e| > 1, since it degenerates to q == 0.
• B10 — pinned at explicit tolerances rather than chased to bit-identity.

One thing worth your attention on B10. You measured the deflection difference (2.357e-06). While pinning it I measured the other two quantities as well:

Quantity	max abs diff	relative
deflections	2.357e-06	2.36e-06
convergence	1.207e-05	1.45e-06
potential	5.375e-03	1.95e-03

The potential agrees ~three orders of magnitude worse than the other two, for two forms that are analytically identical. That is outside B10 as filed and is not fixed here — its tolerance is pinned at the observed level as an explicit ratchet, with a docstring saying so, rather than hidden inside a loose bound. It is getting its own investigation. Your audit found the thread; this is where pulling it led.

Also merged here: the negative-redshift half of PyAutoLens#532. al.Galaxy is ag.Galaxy, so the guard belongs where the class lives — a Tracer-level check would have missed a bare al.Galaxy(redshift=-0.5), which is your actual reproduction. Zero and 1e-12 stay accepted (degenerate, not invalid).

z_lens > z_source is untouched and still waiting on your answer over on #532 — and there is now a test pinning today's permissive behaviour, so that decision stays yours rather than drifting.

---

Generated by Claude Code