WPlanner performance and persistence architecture

Authoritative topic-oriented contract for the R125–R130 Planner remediation: immutable GUI operations, bounded interval parallelism, vector transformation and deferred validated-segment persistence.

GUI and operation boundary

EphemGen() and PlotGen() construct immutable operations and submit them to the shared background QThread runner. The widget contains no QApplication.processEvents() and no direct heavy compute call. Progress travels through signals and elapsed time through QTimer.

One job per comet/apparition interval

Planner batches all requested epochs for one comet/apparition interval into one job. That job performs at most one forward and one backward integration, rather than integrating each requested midnight independently.

The contract is interval-count based: one comet × four midnights and one comet × 500 epochs are each one interval job.

Bounded process ownership

One operation owns at most one spawn process pool. Pool workers cannot create nested pools. Automatic reference scenarios use at most four workers, so 300 comet intervals remain 300 jobs routed through four workers rather than 300 independent process pools.

Vector frame transformation

Planner element batches use one vector Astropy frame-transform call. Per-row transformations are outside the protected production route.

Deferred persistent-segment service

Fitting, validation, compression and writing are deferred through a bounded single-worker service. A successfully computed ephemeris is valid before persistence finishes.

  • Persistence failure cannot invalidate the ephemeris.
  • Queue saturation cannot invalidate the ephemeris.
  • Shutdown timeout cannot invalidate the ephemeris.
  • Only later cache reuse is lost when persistence does not complete.
  • Atomic validated writes prevent partial data from becoming trusted cache state.

Deterministic reference scenarios

ScenarioInterval jobsAutomatic workers
One comet × four midnights11
One comet × 500 epochs11
Four comets × 300 epochs44
300 comets × four epochs3004
cold interval: 1 integration
warm covered interval: 0 integrations
background persistence: drained successfully

Wall time, CPU utilisation and RSS remain target-system diagnostics rather than portable release thresholds.

Scientific non-regression and widget isolation

R130 changes no DE440s dynamics, Cowell equations, DOP853 tolerances, date-aware element/apparition selection, light-time, topocentric geometry, provenance or Cancel semantics. WStack remains serial and does not use the Planner persistent-segment cache or Planner process workers.

Release gate, Markdown hygiene and QA

wplanner_performance_release_gate.py enforces the complete production routing. documentation_hygiene.py separately enforces a small topic-oriented Markdown set for CLEAN and QA archives; obsolete per-release Markdown trees must not be restored during future merges.

  • R130 complete QA: 1767 passed, 8 skipped, 0 failed.
  • Final gates: analysis, modal ephemeris, WPlanner performance, documentation hygiene and performance validation all PASS.
  • R130 manifests: 342 QA files and 95 CLEAN files.

Supplied R130 report · Plain-text reference

Target-system acceptance

The build environment lacked the complete production PyQt5, Astropy, jplephem, DE440s and representative 300-comet runtime. Record cold/warm timing for all reference scenarios, 1/2/4-worker utilisation, Cancel during integration and deferred persistence, peak RSS, cache size and numerical comparison with R129.