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 | Maximum concurrency | Memory policy |
|---|---|---|
| Masterdark/masterflat median | 4 threads | One shared 192 MiB allowance |
| Prepared master cache | Two recent pairs | 768 MiB hard ceiling and 25% of available RAM |
| LIGHT calibration | 2 threads | Adaptive per-image RAM estimate |
| Row reprojection | 2 threads | One shared 256 MiB allowance |
| Sigma clipping | 2 threads | One shared 256 MiB allowance |
| Astrometry.net batch | 2 external processes | Isolated solver working directories |
These are upper bounds, not targets. KOPR can use fewer workers when the job is small, RAM is limited or only one CPU is available.
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.
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 can run up to two solver processes. 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.
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.
Developer performance details
Release validators, benchmark fixtures and implementation-level scheduling contracts are kept in the .