DR6 campaign scope: all 23,114 tiles, or the 20,242 above δ=30°?

[cailmdaley]

The question

The DR6 shear campaign has to be scoped to a tile set before it can be sized, and the choice is worth ~14% of the total cost. Two candidates:

scope	tiles	grid-cell area	share
all of DR6 r-band	23,114	5,778 deg²	100%
δ > 30° core only	20,242	5,060 deg²	87.6%

This is a scientific decision about what the release covers, not something the data settles, so it wants a deliberate answer rather than a default.

Why it is being asked now

Sizing the Snakemake campaign (#848, #852) turned up that the tile counts in circulation are wrong, in ways that propagate straight into cost estimates:

• DR6 is 23,114 r-band tiles. Direct listing of vos:cfis/tiles_DR6/ at CADC, set-verified against auxdir/CFIS/tiles_202604/tiles_r.txt (23,114 lines, identical set).
• The ~7,300 figure that has been used in planning is not DR6 — it is the entry count of a partial processed_tiles/ download. DR6 is 3.2× larger.
• The ~20,000 in Snakemake orchestration for shapepipe #848 was correct for the previous vintage: tiles.cfis.r.use and auxdir/tiles_202402/tiles_all.txt are both exactly 20,859 and are the same set. The survey has since grown.
• Grid-cell area of 23,114 tiles is 5,778 deg², within 2.4% of the 5,638 deg² the UNIONS overview paper quotes for CFIS-r (Table 1, §II.2.1) — an independent check that the tile set is the right one.

Exposure counts, since they are usually quoted alongside

Three different numbers are all in use and none of them is the one the pipeline builds:

• 24,736 — r-band exposures ever taken (vos:cfis/cfis.r.sum, refreshed 2026-08-24). This is the "~25k" in workflow/config.yaml.
• 19,082 — of those, Use=OK (rejects: 1,603 short, 1,584 bad IQ, 2,212 duplicates, …). This is roughly the "~20k" in the PRD.
• ~16,000 — unique exposures actually referenced by DR6 tiles, which is what the pipeline processes. 13,843 measured exactly over the 20,859 tiles in Gwyn's map; the remaining 2,255 DR6 tiles add an estimated 1,500–2,450.

The correction that matters most for cost

Exposure work per tile is 0.69 builds/tile, not 3.44. The 3.44 came from measuring a 34-tile patch, where each exposure appears to have 2.25 consumers; the survey value is 10.03. It is an identity rather than a model — builds/tile ≡ N_exp / N_tiles — so a small patch necessarily overstates it, here by a factor of 5.

Practical consequence for anyone scaling a measurement: costs must be split into three buckets with three multipliers, or exposure work gets priced five times over.

• per-tile work (detect, vignets, ngmix chunks, merge, make_cat) × 23,114
• per-exposure-build work (get_images, split, mask, psf, star_cat) × ~16,000
• per-exposure-read work × ~154,000 incidences, and divide the measured value by 1.16 first, because the calibration patch reads 7.74 exposures/tile against a survey mean of 6.66

Star-catalogue network cost is its own bucket and scales with sky area alone: 2,243 NSIDE=32 HEALPix chunks for the DR6 footprint with the current 2° padding. (Same code predicts 48 for the 34-tile benchmark set, which is exactly what was measured.)

Suggested default

Start with δ > 30° — 20,242 tiles — and treat the lower-declination remainder as a documented extension rather than an assumption. Objections welcome; the point of the issue is to have the number written down and agreed rather than inferred differently by each estimate.

Sources

vos:cfis/tiles_DR6/, vos:cfis/cfis.r.sum (2026-08-24), vos:cfis/tiles.cfis.r.use (2025-10-21 — note this lags the survey by ~10 months, which is the gap the ~16,000 estimate spans), auxdir/CFIS/tiles_202604/tiles_r.txt, src/shapepipe/utilities/cfis.py:479-482 for the grid definition, and the UNIONS overview paper for the area cross-check.

🤖 Generated with Claude Code