Adaptive pixelisations (Delaunay, KNNBarycentric) crash in FitImaging; ConstantSplit broken on RectangularUniform #332

Activity

1. Jammy2211 commented on Jul 28, 2026

   

   Jammy2211

   on Jul 28, 2026

   Collaborator

   More actions

   Thanks @rhayes777, and sorry for the delay on this one. I've re-run both parts against current main (autoarray @ 616e8b4c, autolens @ 6567b3b1c). Here's what I found.

   Part 2 is confirmed straight out. ConstantSplit on RectangularUniform raises:

   AttributeError: 'InterpolatorRectangularUniform' object has no attribute '_mappings_sizes_weights_split'
   

   while the same regularization works fine on Delaunay (log_evidence 5096.44 on your simulation). That's a real bug with no workaround, and we'll fix it.

   Part 1 is subtler than it first looked. Delaunay and KNNBarycentric aren't broken in the released wheel — they need an image-plane mesh grid supplied via adapt_images, and with it both fit cleanly on your exact simulation:

   Delaunay(pixels=100)       + Constant + adapt_images  ->  log_evidence 5084.7513
   KNNBarycentric(pixels=100) + Constant + adapt_images  ->  log_evidence 5211.7226
   Delaunay(pixels=100)       + Constant, no adapt       ->  AttributeError: 'NoneType' ...
   

   The idiom is:

   adapt_images = al.AdaptImages(
       galaxy_image_plane_mesh_grid_dict={source: image_plane_mesh_grid}
   )
   fit = al.FitImaging(dataset=dataset, tracer=tracer, adapt_images=adapt_images)

   as used in autolens_workspace/scripts/imaging/features/pixelization/delaunay.py. Your snippet omitted it, which is why the grid arrived at the border relocator as None.

   That said, you found a genuine defect and your diagnosis was close to the mark. A missing required precondition should not surface as AttributeError: 'NoneType' object has no attribute 'array' three frames down in border_relocator.py:446 — that's exactly the head-scratch failure mode you describe in your other reports. And your reading that the wiring belongs inside the mesh classes is the direction we'll take: either the mesh sets the grid up itself, or construction fails immediately with a message that names adapt_images. Reproducing this took me straight to the right line, so the report did its job even though the headline was broader than the underlying cause.

   Both items are being tracked alongside the rest of your audit (#333, PyAutoGalaxy#440, PyAutoLens#531, PyAutoLens#532) as a single campaign — the two here are in the "genuine crash / bad error" bucket rather than the constructor-validation sweep. I'll link the tracking issue here shortly.
2. Jammy2211 commented on Jul 28, 2026

   

   Jammy2211

   on Jul 28, 2026

   Collaborator

   More actions

   As promised above — the tracking issue for this campaign is
   #415, which carries the verification evidence for all 16
   findings and the phase breakdown.

   The findings from this issue are in phase 1 (#416), which
   is where we're starting — they're the ones with real user impact and no workaround.

   One thing worth flagging back to you: while tracing the ConstantSplit failure I
   found it's wider than reported. InterpolatorRectangularUniform is missing
   _mappings_sizes_weights_split entirely (InterpolatorRectangular and
   InterpolatorDelaunay both have it, and the abstract base doesn't supply it) — and
   three regularizations consume that property, not one:

   constant_split.py:67
   adapt_split.py:104
   adapt_split_zeroth.py:105
   

   So AdaptSplit and AdaptSplitZeroth fail on RectangularUniform for the same
   reason. You found one of three. The fix and its tests cover all of them.
3. Jammy2211 commented on Jul 28, 2026

   

   Jammy2211

   on Jul 28, 2026

   Collaborator

   More actions

   Correction to my note above, and it changes the outcome for you — worth flagging
   rather than leaving you to discover it from a changelog.

   Rectangular meshes do not support Split regularization. That's the design
   intent, confirmed with @Jammy2211. So the fix here is not to make
   ConstantSplit work on RectangularUniform — it's to raise a clear exception
   saying the combination is unsupported, pointing you at a mesh that does support it.

   Digging into it turned up more than the one case you hit. Nine combinations are
   affected, in two different failure modes — three rectangular meshes x three Split
   regularizations:

   Mesh	Today
   RectangularUniform	AttributeError: ... has no attribute '_mappings_sizes_weights_split' (your case)
   RectangularAdaptDensity	IndexError: index 4 is out of bounds for axis 0 with size 4
   RectangularAdaptImage	same IndexError (inherits)

   The second mode is the one I'd have missed by reading only your report.
   InterpolatorRectangular does define _mappings_sizes_weights_split, but as a
   pass-through with this comment:

   # Rectangular pixelizations use bilinear interpolation which already factors
   # in the 4-corner neighbourhood, so no separate split-cross calculation is
   # needed — split regularization reuses the same mappings.
   return self._mappings_sizes_weights

   That's aspirational rather than true — it hands 4-corner mappings to
   reg_split_from, which expects the split-cross structure, and crashes one frame
   later. It's going away in favour of the explicit error.

   Delaunay + ConstantSplit works fine (log_evidence 5096.4420), so if you need
   split regularization that's the direction. Tracked in #416.
4. Jammy2211 commented on Jul 28, 2026

   

   Jammy2211

   on Jul 28, 2026

   Collaborator

   More actions

   Phase 1 is up for review — the crash-level findings from your audit.

   • fix: reject split regularization on rectangular meshes at construction #417 — split regularization on rectangular meshes
   • fix: PointSolver zero-image and coarse-precision crashes, plus two consumer gaps PyAutoLens#662 — both PointSolver crashes

   Two things worth reporting back, since both change what you'd expect to see.

   Your ConstantSplit finding was one of nine. InterpolatorRectangular (used by
   RectangularAdaptDensity and RectangularAdaptImage) does define
   _mappings_sizes_weights_split, but as a pass-through commented "split regularization reuses the
   same mappings". It doesn't — reg_split_from expects the split-cross structure, so those two
   meshes failed with IndexError rather than your AttributeError. Three meshes × three split
   schemes, two failure modes. All nine now raise one clear error at Pixelization construction
   naming both sides, and the misleading pass-through is deleted.

   Your outside-the-caustic case yields zero images, not one. You predicted a single image near
   the source position; the tiling finds none, because the grid spans ±2″ and the source sits at
   (5,5). So rather than fabricate an image, solve() now returns an empty grid and logs why.
   Your underlying point stands — a raw AxisError was useless — but the fix is "return nothing,
   clearly" rather than "return the one image".

   Chasing the second one turned up something adjacent that you didn't hit but would have: with zero
   images, FitPositionsImagePairAll computed -log(0) against an infinite sum and produced a NaN
   chi-squared. fitness.py converts NaN likelihoods into resample-rejects, so a search would have
   silently discarded those models instead of scoring them. Its two sibling fit classes already had a
   finite no_image_residual floor for exactly this; PairAll was the one missing it. Fixed in the
   same PR.

   Still to come: the constructor-validation sweep (#333, PyAutoGalaxy#440, #532's B4), the
   adapt_images error-legibility fix, and the z_lens > z_source question I asked you on #532 —
   that one's genuinely open, no rush.
5. Jammy2211

   added a commit that references this issue on Jul 28, 2026

   fix: reject split regularization on rectangular meshes at construction (

   ...

   9411904
6. Jammy2211

   closed this as completedin #442on Aug 9, 2026
7. Jammy2211 commented on Aug 9, 2026

   

   Jammy2211

   on Aug 9, 2026 – with Claude

   Collaborator

   More actions

   Fixed and merged in #442 (5dedb5e). Thanks @rhayes777.

   To restate the correction from our earlier reply, since it is what shaped the fix: the meshes are not broken. Delaunay and KNNBarycentric work; they require an image-plane mesh grid, supplied via adapt_images. Re-verified on the branch — with it supplied, Delaunay + Constant, KNNBarycentric + Constant and Delaunay + ConstantSplit all fit, and RectangularUniform + Constant fits with no adapt_images at all.

   So the defect was the error, and that is what changed. Instead of AttributeError: 'NoneType' object has no attribute 'array' from inside border_relocator.py, you now get a MeshException that names adapt_images, shows the AdaptImages idiom, and points out that the rectangular family needs none. The guard sits at Delaunay.interpolator_from, which the whole adaptive family inherits.

   On your suggestion that "the wiring probably needs to move inside the mesh classes themselves" — we went the other way, and it is worth saying why rather than just doing it. Building an image-plane mesh grid requires a weighting policy, and that policy is exactly what adapt_images carries. Having the mesh invent one would make a science choice on the user's behalf, silently, in precisely the case where they have given no indication of what they want. Failing fast keeps that choice explicit. It also matches how the rectangular/split combination was handled in #417. Happy to revisit if you think the intended API really is for Delaunay(pixels=N) to self-wire.

   Small correction to our own notes while we were in there: the None is the mesh_grid argument (border_relocator.py:450), not the grid one at line 446.

   Part 2 of this issue (ConstantSplit on RectangularUniform) shipped back in #417 and is untouched.

   The regression tests assert the clear failure plus controls that each adaptive mesh still builds with its grid supplied — so if these meshes ever genuinely do break, those controls fail and the correction above gets revisited rather than quietly becoming wrong.

   That closes phases 2 and 3 of the audit. Epic #415 stays open for the one remaining item, the z_lens > z_source question on PyAutoLens#532, which is still with you.

   ---

   Generated by Claude Code