fix: crashes in suggest_extraction_scheme for cont extraction

[jdhenshaw]

Summary

Three minimal fixes in suggest_extraction_scheme that resolve crashes in batch_extract_continuum when freq_ranges_ghz is specified with either channel_ghz: None or channel_ghz values that
are lower than the native res of the only covering SPW.

Bug 1 — np.nanmin on empty total_nchans

When the per-SPW loop excludes every covering SPW (because chan_width_kms > target_chan_kms for all of them if channel_ghz is set low), total_nchans ends up empty and np.nanmin([]) raises ValueError.

Example: channel_ghz: 0.001 on ALMA Band 6 centres 232–234 GHz window. Target = 1.287 km/s, native chan width = 40 km/s -> SPW excluded -> empty lists -> crash.

Fix: guard np.nanmin with if total_nchans:; emit a warning and return the empty scheme (which batch_extract_continuum's outer loop silently skips). May not be perfect solution, but it emits a warning.

Bug 2 — binfactor exceeds the SPW's channel count

int(np.floor(target_chan_kms/chan_width_kms)) can exceed vm.spwInfo[this_spw]['numChannels'] when the user's freq_ranges_ghz overshoots the SPW's actual bandwidth. The resulting per-spw target resolution ends up being
finer than the SPW's native width and mstransform crashes with calcChanFreqs failed. Discovered because i didn't set the windows correctly.

Example: range [215.97, 217.85] = 1.88 GHz on an SPW that actually covers only 1.875 GHz (1920 channels × 976.5 kHz). binfactor = 1925, per-spw target = 1.34980 km/s = 976,623 Hz, < native 976,672
Hz → crash.

Fix: clamp this_binfactor to nchan_spw. The clamp enforces that binfactor can never exceed available channels.

Bug 3 — TOPO/LSRK frame mismatch - not 100% sure on the cause

PHANGS reads chan_width_kms from vm.spwInfo[this_spw]['chanWidth'] from the MS (TOPO?). mstransform, with outframe='lsrk', internally converts input channels to LSRK before validating the requested output width. The LSRK-converted native is larger than TOPO by a small factor.

When target = refvwidth / binfactor lands above TOPO native but below LSRK native the downstream safety net passes the request through, but mstransform's internal check rejects it.

Example: range [219.06, 219.52] with channel_ghz: null. refvwidth = 628.87 km/s, chan_width_kms = 0.667532 km/s, binfactor = floor(942.080) = 942, per-spw target = 0.667588 km/s = 488323 Hz.
LSRK native = 488336 Hz -> target is below native -> crash.

2026-06-10 08:31:25 WARN MSTransformRegridder::calcChanFreqs *** Requested new channel width (488323 Hz) is smaller than smallest original channel width
2026-06-10 08:31:25 WARN MSTransformRegridder::calcChanFreqs+ which is 488336 Hz
2026-06-10 08:31:25 WARN MSTransformRegridder::calcChanFreqs+ or 667.607 m/s
2026-06-10 08:31:25 SEVERE MSTransformRegridder::calcChanFreqs calcChanFreqs failed, check input start and width parameters

Fix: when total_nchan == 1 (the signature of "one channel per range" intent), decrease binfactor by 1. This inflates per-spw target by 1/(N-1), which then exceeds (slightly) the requirement for the check.

The fix is targeted only to the total_nchan == 1 case (line cubes have total_nchan in the hundreds). Final output dimensionality is preserved: the rebin step's chanbin = N-1 still collapses to 1 channel; only the intermediate per-channel width is affected.

Verification

Tested with the PHANGS-CMZs NGC 1087 anchor data (project 2023.1.01182.S). All four ranges extract cleanly into a 4-SPW cont MS, including continuum window (previously silently dropped by the np.nanmin guard's empty-scheme
behaviour under probelm 1 above).

Final ngc1087_12mext_cont.ms:

SPW	Source range	nchan	Bandwidth
0	215.97–217.85 GHz	1	1.88 GHz
1	219.06–219.52 GHz	1	0.46 GHz
2	228.91–229.85 GHz	1	0.94 GHz
3	232.03–234.02 GHz	1	1.99 GHz

Changes

All in phangsPipeline/casaVisRoutines.py, function suggest_extraction_scheme:

1. Guard np.nanmin(total_nchans) against empty list; log warning and return empty scheme in that case.
2. Clamp this_binfactor to vm.spwInfo[this_spw]['numChannels'].
3. Decrement this_binfactor by 1 when total_nchan == 1 and this_binfactor > 1.

No changes to build_mstransform_call, extract_continuum, or downstream code. No new dependencies.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 6.27%. Comparing base (70674e8) to head (826529d).

Files with missing lines	Patch %	Lines
phangsPipeline/casaVisRoutines.py	0.00%	13 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##           master    #352      +/-   ##
=========================================
- Coverage    6.28%   6.27%   -0.01%     
=========================================
  Files          38      38              
  Lines       15232   15239       +7     
  Branches     3660    3663       +3     
=========================================
  Hits          957     957              
- Misses      14261   14268       +7     
  Partials       14      14              

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

[thomaswilliamsastro]

This seems reasonable to me. Tagging @astrojysun who has done a bunch of continuum work for another look

[astrojysun]

The fixes look good to me too!

Just wanted to mention that in practice we usually choose channel_ghz more deliberately to avoid bandwidth smearing (see here). For band 6, using a channel width of 0.05 GHz is likely safe enough.

[thomaswilliamsastro]

@jdhenshaw, you wanna flip this off draft if you're happy and we can merge this in?