Performance and platform limits
KOPR chooses bounded worker and memory limits automatically. This page summarizes the limits that can affect observing workflows and explains what users should expect during long calculations.
Automatic processing limits
| Operation | Planning model | Important limit |
|---|---|---|
| Masterdark/masterflat combination | Bounded internal threading | Shared memory allowance |
| Prepared master cache | Byte-budgeted current workset | No fixed “two-pair” retention rule |
| LIGHT calibration | Fixed production cap of 2 workers | Higher concurrency was measured but not adopted because the practical gain did not justify the RAM cost |
| Mean / Sum reprojection | Automatic host-aware scheduler | Hard cap 8, additionally limited by physical cores, useful blocks and available RAM |
| Sigma-clipped mean | Automatic host-aware fused scheduler | RAM-safe planning and temporary-disk preflight |
| Astrometry.net batch | Automatic workload/host-aware scheduler | Native-host hard cap 6; RAM-aware and deliberately more conservative on unknown/WSL backends |
These limits are planning ceilings, not targets. KOPR can select fewer workers when the job is small or resources are constrained. Users normally do not need to tune worker counts.
Long-running work and cancellation
- Numerical and I/O-heavy work runs outside the GUI thread where the workflow supports background execution.
- Cancel is cooperative. The current unit of work may need to reach a safe boundary before the operation closes.
- Failed, cancelled or stale work does not replace a previously committed valid result.
- Persistent caches are written only after their data have passed the relevant validation.
Ephemeris work by workflow
| Workflow | Position / geometry model | Cache behaviour |
|---|---|---|
| Process Visual Obs. | DE440s N-body astrometric positions when the N-body runtime is available | In-memory trajectory reuse |
| Process CCD Obs. | DE440s N-body position helpers when available | In-memory trajectory reuse |
| Image Calibration & Stacking | DE440s N-body positions for comet seeds and stacking trajectories when available | In-memory trajectory reuse |
| Observation Planner | Fast two-body candidate filtering followed by N-body refinement of accepted rows | Persistent validated N-body segments |
| Comet Analyzer | Two-body photometric geometry for light-curve analysis | In-memory geometry cache |
| Finding charts | Deferred N-body physical-track refinement for the selected comet | Planner trajectory and prepared-scene reuse |
Planner and finding charts
Planner does not run N-body integration for every search candidate. Candidate dates are filtered first; only accepted rows are refined. A warm persistent cache can therefore make a repeated interval much faster than the first calculation.
Finding-chart generation can be more expensive than the ephemeris itself because the selected comet track is adaptively refined and checked in projected page space. Refinement is bounded by a depth limit of 8 and an operation budget of 4096 N-body epochs. Mixed component versions are rejected before expensive map work begins.
Comet Analyzer
Changing display style, point size, legend encoding or a valid cached plot range redraws prepared data without rerunning the scientific analysis. Recalculation is required when observations, physical geometry, formulas or fit inputs change.
Scenario restore validates the stored state before replacing the current workspace. A failed restore leaves the existing analysis available.
Measured WStack reference results
Performance figures are workload- and host-specific measurements, not guaranteed speedups for every computer or observing session.
- On the N=7 Sigma reference, fused Sigma reprojection was about 2.87× faster than the historical two-transform / two-worker core while preserving exact output/statistics parity.
- On the reference Calibration→Astrometry→Stack flow, the measured Calibration→Astrometry→Stack sequence changed from 456.473 s to 431.146 s (−5.55%), largely by reducing repeated metadata/header work at stage boundaries.
- Across the five-session, 229-frame Relative-WCS corpus, the measured validation section changed from 408.332 s to 69.976 s (−82.86%) with zero decision divergences in the reference corpus.
These percentages describe different and partly overlapping benchmark sections and must not be added together.
Platform notes
Linux
KOPR runs natively. Astrometry.net can use a local solve-field installation and local index files.
Native Windows
KOPR runs with native Windows Python. Astrometry.net is normally provided through WSL 2 when no native solver is available. Paths with spaces and Unicode are supported by the documented WSL path-translation workflow.
Windows with WSL 2 Astrometry.net
KOPR uses conservative automatic solver concurrency on WSL/unknown backends. Cancelling an astrometry batch terminates the Linux solver process group without shutting down the entire WSL distribution.
Memory and storage expectations
Scientific and Compact FITS differ mainly in on-disk storage. Calibration, reprojection, stacking and photometry still use floating-point working arrays, so Compact mode should not be expected to halve peak RAM use.
Large-image reprojection is planned against available RAM. Sigma also checks temporary disk capacity before committing to the operation; an unsafe plan stops with an actionable error rather than producing a partial stack.
The first N-body calculation for an interval can be slower because no persistent trajectory segment is available yet. Subsequent calculations can reuse validated stored segments.
See Scientific and Compact FITS, Observation Planner and Troubleshooting.