Four programs and logs: parallel evidence, no standard answer first

XARTATOMS 0900170101 · M31CGM 0800732701 · M31HotISM 0112570101 · esas_playground v1.4.1

Published on

July 13, 2026

comparison-rules

We do not rank directly by "largest file-name version number", but look at five kinds of evidence.The user has selected esas_playground_v1.4.1.py as the unified canonical engine; the division of runner/acceptance/failure-corpus is still bounded by the following evidence.

entry point: which shell / Python / .par；
stage semantics：redu、C、full actually opens which steps;
spatial contract: how exact DS9, source exclusion, camera coverage enter mos-spectra；
product contract: source/QPB/RMF/ARF, headers, counts, BACKSCAL, and no-fit QA;
replay evidence: real logs, status, hash, test, qualification, not the ideal flow in comments.

Path-name correction

The user-mentioned xmm/python_scripts/ipynb/esas* does not exist in the current file tree; the actually active directory is xmm/python_xmmscripts/ipynb/esas*. This page takes this live tree as the fourth material, but does not automatically equate "latest modification time" with "production-qualified".

Software version and task-name boundary

This round's local exemplar wrapper/log uses xmmsas_20211130_0941 distribution environment, and calls legacy interfaces mos-spectra and mos_back. The current SAS online documentation (re-read 2026-07-13) uses mosspectra and mosback as task headings; the official routine concordance also lists the old→new name mapping.

Therefore this tutorial is local legacy-runtime audit, not a current-SAS command migration guide. Before the user specifies a golden runtime, task names are not automatically rewritten to the current interface.

Claim-level provenance

Evidence ID	Public source label	Supported claim
`XART-E01` / `XART-E02` / `XART-E03`	Phase2 pilot/batch wrapper + pilot `.par`	clean shell, pilot→batch, background-only/no-fit configuration, and engine hash gate
`XART-E04`	remaining-six qualification JSON	six new regions qualified; combined with the Wind N pilot gives 7/8, S8 unavailable
`CGM-E01` / `CGM-E02` / `CGM-E03`	PBS job、v1.3.2 `.par`、2025-11-30 main log	historical `redu/C`, cluster scale, 49,609,621-byte log, and legacy credential caveat
`HOTISM-E009` / `HOTISM-E009-QA` / `HOTISM-E009-RUN`	E009 record、84-gate JSON、pilot wrapper	camera-specific point mask, MOS1/MOS2 products, 84/84 PASS, no unintended PN
`ENGINE-E01`	`esas_playground_v1.4.1.py`	exact engine SHA-256 and the source-level improvements/open points listed on this page

All SHA-256 see public source inventory. Public evidence labels do not expose internal absolute paths.

summary-table

Dimension	XARTATOMS 0900170101	M31CGM 0800732701	M31HotISM 0112570101	upstream v1.4.1
Real engine	`esas_playground_v1.4.1.py`	history `v1.2.0C` / `v1.3.0`, preparing to migrate to `v1.3.2`	`v1.3.2.py`	engine body
Entry point	clean-shell pilot / remaining batch wrapper	PBS `job_demo_v1.3.2.sh` + root batch script	project runner + compat + mask + linker + verifier	`python engine.py config.par`
Representative mode	`full`, but only opens `4.background + extra_region + background`	`redu` full chain; `C` can open background	`C` / custom runner	supports `full/resume/redu/C...`
camera	recent R4–7 branch MOS2-only	MOS1+MOS2, historical configuration does not include PN	MOS1+MOS2, explicitly no PN	Both MOS/PN supported
region	exact FK5 sector + exclusion file	Large batches of annulus/Angle2 + exclusion	exact variable-W1 polygon + camera point-source masks	`extra_region_list` / `extra_region_file`
preflight	clean namespace、SUM count、tool path、geometry tests、pilot release hash	PBS resources / qstat; fewer product-level fail-close	clean env、input hash、inventory、mask rebuild	engine internal checks, wrapper has more responsibility
output QA	pilot/replay/qualification + no-fit/spatial handoff	Rich real logs, but old-process acceptance is looser	84/84 product gates	not a release layer
log characteristics	recent production + replay; also retains noisy bootstrap	49,609,621-byte main log, environment dump extremely heavy	targeted audit logs + cognition OS	Many historical logs, current production log is on the project side
Main value	production discipline	history + scale + failure corpus	geometry/product acceptance	reusable engine logic
Main risk	Project-specific wrapper cannot be directly generalized	Expired environment, full copies, credentials, giant logs	recovery logic mixed into routine runner	rProfile/sync/noisy bootstrap not fully closed

A. XARTATOMS `0900170101`: the most complete recent production exemplar in this inventory

real-entry-point

run_esas_r47_eight_axis_centered_phase2_pilot_mos2_windN.sh
run_esas_r47_eight_axis_centered_phase2_remaining_seven_mos2.sh
esas_playground_r47_eight_axis_centered_phase2_{pilot,remaining}.par
engine SHA-256: 67ce592641201f92bf6952f7ee5555e9c8a508198ee571f924a8caa9d7e96063 (ENGINE-E01)

Representativeness .par Not running the full ODF chain, but:

[DEFAULT]
obsID = 0900170101
mode = full

[full]
cifbuild = no
odfingest = no
1.calibration = no
2.filter = no
3B.background = no
4.background = yes
extra_region = yes
background = yes
4.fitting = no

[back]
INST = mos2,
generate_spectra_and_back = yes
EMINLIST = 700,
EMAXLIST = 1000,
MASK = 1,
extra_region_file = "<approved source-exclusion.reg>"
extra_region_list = <approved R4-7 sector.reg>,

why-it-is-worth-learning-first

env -i clean shell, explicit HEADAS/SAS/ESAS initialization;
PREFLIGHT_ONLY can only gate, not extract;
checks unique SUM, engine/tool path, clean output namespace;
the pilot's release manifest and hashes are the batch pre-gate;
run completion does not directly claim "qualified", status is first pipeline_finished_qa_pending；
Wind N pilot passes source/QPB/ARF/RMF + outer-corner replay; the other six regions use production-only QPB qualification; S8 is fail-closed unavailable because it only has CCD1 and no outer anchor (XART-E04）；
no-fit spectrum and exact region/camera-mask spatial QA are delivered independently.

still-needs-your-judgment

production log still contains import-time test noise, test.txt, environment setup expansion, and Unicode logging error;
the wrapper is highly specialized for R4–7 sector/CCD/pilot release;
v1.4.1 still retains historical behaviors such as unconditional rProfile / final calibration sync;
full whether the "resume-like background only" name should be kept, or changed to a more explicit mode.

XARTATOMS's full + all preceding stage=no + 4.background=yes is the standard C-mode writing you now recommend? Or should you use C/resume, and put field preparation in another .par？

B. M31CGM `0800732701`: historical scaling material, not the current template

real-entry-point-and-evidence

root command_v1.3.2.sh copy job/config for each OBSID, sed replace OBSID, manual hardlink sync, qsub；
per-OBSID job_demo_v1.3.2.sh request 6 CPU / 60 GB, copy v1.3.2.py then run with IPython;
the existing 2025-11-30 log actually executes v1.2.0C.ipynb、mode=redu；
redu simultaneously opens calibration, filter, source detection, background, showing it is a full observation reduction, not a routine extraction per region;
v1.3.2.par in C mode uses 4.background + cheese + extra_region + background；[back] contains a large number of Angle2 regions.

most-valuable-part

Real multi-observation PBS scheduling and resource history;
redu / B / C / C1 / C2 / C3 / D / E mode evolution;
16 main/error logs totaling 369,293,176 bytes, can learn SAS failure and environment drift (CGM-E03 inventory）；
extra_region_file + extra_region_list 's early large-batch practice.

should-not-be-copied-as-is

copy the entire engine for each OBSID;
use sed to modify configuration, lacking config schema / exact hash gate;
shell hard-codes notification credentials (public material has [REDACTED]）；
49,609,621-byte single log contains the entire environment and a large number of SAS parameters, making it hard to distinguish real errors;
root hardlink sync mixed with extraction;
notification after job ends does not equal product acceptance.

Which M31CGM log do you think is most worth using as the golden log for "from ODF to extractable RPC"? Currently I only use 0800732701 's 2025-11-30 full reduction as a historical sample, not as a success template.

C. M31HotISM `0112570101`: acceptance exemplar, but the runner needs slimming

Validated extraction core

extra_region_list
→ add_extra_region_v2
→ ds9_to_xmmexpr(coordtype='det')
→ mos-spectra
→ mos_back

E009 for adopted a=0–4′ polygon result:

MOS1/MOS2 source, QPB, RMF, ARF complete;
84/84 hard gates PASS（HOTISM-E009-QA）；
PHA channel / RMF grid / exposure / BACKSCAL / headers / exact selection all checked;
camera-specific 80% EEF point-source masks；
explicitly no pn-spectra、pn_back, PN OoT, or new PN-like products;
explicitly no fit / no physical result.

Why the runner became thick

old v1.3.2 + Python/HEASOFT/SAS compatibility；
restores clean files deleted by the engine before running;
rebuilds point-source masks separately;
post-run OGIP linker + verifier；
inventory/hash/audit/rejected-attempt records;
current mask builder/linker/verifier still hard-codes 0112570101's S001/S002 exposure IDs, 92/90 mask rows, and rejected-attempt regression; before migrating to a new OBSID, it must be changed to manifest/parameters, not copied as-is.

These are mostly recovery and acceptance , not mos-spectra → mos_back itself.

Which of M31HotISM's 84 gates do you want to keep as the minimum acceptance for all new spectra? Which are only suitable for this custom polygon / compatibility event?

D. upstream `esas_playground_v1.4.1.py`: engine, not a complete release workflow

Known additions/fixes

Python 3.13 subprocess bootstrap；
relative-CWD / MOS-only bookkeeping；
extra-region path and decimal basename;
region-specific MOS CCD preflight and QPB outer-corner anchors;
xmmtools.esas_pha helpers；
XARTATOMS recent production actually uses this hash.

known-unclosed-points

rProfile default post-processing may block;
final 1.calibration sync should not be unconditionally required;
import-time test/logging noise；
the changelog file still stops at v1.3.1, cannot rely on changelog alone to understand v1.4.1;
the local tree has a large number of historical notebooks/logs, and you must specify the "golden version".

The user has confirmed v1.4.1.py is the main program, and requires all changes to go through .par configuration. What still awaits central qualification is open points such as rProfile/final-sync, not choosing another per-OBSID engine.

material-division-after-the-user-decision

CANONICAL ENGINE

v1.4.1 engine

The only processing program specified by the user; different OBSID/region/band are all configured by .par configuration.

PRODUCTION PATTERN

XARTATOMS wrapper

Learn clean-shell, pilot, hash, status, fail-close, qualification.

ACCEPTANCE PATTERN

M31HotISM E009

Learn exact geometry, point mask, source/QPB/response, and no-PN gates.

FAILURE CORPUS

M31CGM logs

Learn full reduction, cluster environment, and real errors; do not copy the legacy launcher.

The user's teaching decision has been adopted; go to Teach Hermes page to continue revising. The original decision execution_authorized=false, does not authorize any specific run.