Keep exposure stores node-local in single-allocation runs; persist only per-exposure products
Maintainer thường phản hồi trong vòng 1 ngày
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 18/100
- Loại issue
- Tái cấu trúc
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- hpc, python
- Lĩnh vực
- data, infrastructure
Hướng nghiên cứu
Start with how sp run --in-allocation sets the exposure store location, and find where tile stores already use node-local $SLURM_TMPDIR. Then check sp_check_products.py and the star catalogue merge for any direct read of an exposure store. Done means exposure stores live on node-local disk in allocation mode, only the per-exposure PSF tars and exposure-map fragments are persisted, and a resumed failed batch still completes.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
On Nibi a production batch is now one 144-core allocation running about 25 tiles (sp run --in-allocation). Its tile work is already node-local (#947 and the node-local tile stores). Its exposure stores are not: each batch builds about 43 of them on /scratch. Each node has 3 TB of local disk, so the exposure stores should live there too, and only the per-exposure products the catalogue needs should be persisted.
What the first production wave measured (smk-b01–b05, 10 Oct)
| batch | tiles | exposures | wall | billed core-h/tile |
|---|---|---|---|---|
| b01 | 25 | 42 | 2h09m | 12.4 |
| b02 | 25 | 43 | 1h58m | 11.3 |
| b03 | 25 | 42 | 2h08m | 12.3 |
| b04 | 25 | 43 | 2h06m | 12.1 |
| b05 | 25 | 44 | running |
- Scratch bytes are what binds. With wave 1's stores live,
/scratchreached ~1.9 TiB against Nibi's 1 TiB per-user soft quota, and it dropped back to 783 GiB as batches finished. The scale is ~6.6 GiB per exposure store, ~300 GiB per batch. Above the soft quota a 60-day grace counter runs, and it resets only when usage drops back below 1 TiB. So on/scratchwe can run only 2–3 batches at a time, or keep relying on the grace period. - File count does not bind at this scale. It is ~1,000 files per exposure store, ~50K per batch.
- Boundary recompute is real but cheap. The five batches build 214 exposure stores for 156 distinct exposures, so 27% are recomputed at batch edges. The exposure chain is ~1 of the ~12 billed core-h per tile (g12: 0.99), so the recompute costs about 2% of the total (inferred from g12's split).
Proposal
In --in-allocation mode, put the exposure stores on node-local disk ($SLURM_TMPDIR), next to the tile stores, and persist to the products directory only what downstream reads: the per-exposure PSF tars and the exposure-map fragments.
- A batch's
/scratchfootprint goes to roughly its products, so the soft quota stops limiting how many batches run at once. It is then limited by the scheduler and fairshare. - It makes #951 (packing per-exposure intermediates for the 1M-file quota) unnecessary for single-allocation runs. #951 still matters for the multi-job Slurm-executor launch.
- I/O moves off shared NFS. This is the same effect #947 had for
tile_detect: 8.7 → 1.0 min.
Not proposed: a cross-batch shared exposure store. It would save the ~2% recompute, but it would bring back a persistent shared store, with locking between concurrent batches and a bigger /scratch footprint. Ordering batches as compact 2D blocks gets most of that 2% for free.
What to check while implementing:
- Peak node-local use per batch. It should be ~300 GiB stores plus tile stores, well under 3 TB, but measure it on a dense batch.
- That a failed batch can be resumed. With node-local stores it re-runs from the start: ~2 h, which is acceptable.
- That nothing downstream (the star catalogue merge, the coverage and defect maps,
sp_check_products.py) reads an exposure store directly rather than a persisted product.
Claude (Opus, nibi chair) on behalf of Cail. Measurements by the nibi surveyor session from the smk-b01–b05 ledger.
- Ngôn ngữ chính
- Python
- Star
- 18
- Fork
- 14
- Merge trung bình
- 2 ngày 13 giờ
- Pull request đã merge (30 ngày)
- 35
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của CosmoStat/shapepipe
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 85/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Workflow: sp run refreshes the code snapshot before the lock; re-clean erases exposure tombstones; missing run-dir undetectedCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 18/100
CosmoStat/shapepipe#956 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của CosmoStat/shapepipe
Issue tương tự
-
Consolidate the now-identical CLI-native and composed tasks_packages guards (#5945 follow-up)Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
spec-kitty/spec-kitty#6112 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: OpenRouter streaming chunks report the requested router name instead of the model OpenRouter servedCó thể đã có người làm @Mrun25 đã nhận hôm nay. Đang mởbug llm translation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
BerriAI/litellm#46095 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
uberdeveloper/fastbt#29 ·
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
andrew-blake/melcloudhome#368 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
lane:discover
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
SPARDiffData/differential-data-collection#33 ·
Maintainer thường phản hồi trong vòng 1 ngày