Gaia DR3 Flux Analyzer — ObjectScript Edition

A solution to InterSystems Employee Programming Challenge #1. It scans 20 gzipped
Gaia DR3 epoch-photometry files and reports every astronomical object whose BP or RP
flux varied by more than 100 % across the observation period.

Implementation language: InterSystems ObjectScript (pure — no Python on the
execution path). A companion Python Embedded Python Edition exists as a separate
variant; this repository is the ObjectScript variant and is fully self-contained.

What it computes

For each source_id, over the valid (finite, non-NaN) values of each band:

bp_percentage_change = ((bp_max - bp_min) / bp_min) * 100
rp_percentage_change = ((rp_max - rp_min) / rp_min) * 100
percentage_change    = max(bp_percentage_change, rp_percentage_change)

A source is written only if percentage_change > 100 (strict; exactly 100 is
excluded). Output columns, in order:

source_id,bp_min_flux,bp_max_flux,rp_min_flux,rp_max_flux,percentage_change

Prerequisites

• Docker Desktop
• git

Build & run (the moderator workflow)

git clone https://github.com/bostonbrad/gaia-dr3-flux-objectscript.git
cd gaia-dr3-flux-objectscript
docker compose up --build -d
docker compose exec iris iris session iris

Then in the IRIS terminal (namespace USER):

USER>do ^RunScript

This prints the qualifying row count and elapsed time, and writes the result to
data/out/result.csv.

How it works

• src/RunScript.mac — the benchmark entry point. Run() times the work with
  $ZHOROLOG and calls $$Process^GaiaChallenge.
• src/GaiaChallenge.mac — the solution:
  • reads each data/in/*.csv.gz with the native %Stream.FileCharacterGzip (no
    external decompression), in sorted filename order;
  • skips the 365-line ECSV comment header and the column header;
  • splits rows with a quote-aware parser that stops at the rp_flux column (17);
  • collects valid $DOUBLE flux values per band (ignoring NaN/null/±Inf/
    invalid), computes min/max and the per-band percentage, takes the larger, and
    emits rows above 100 %;
  • writes data/out/result.csv (UTF-8, LF, one trailing newline).
• It fails loudly (throws, non-normal exit, no partial output) on malformed,
  missing, or corrupt input, naming the file, row, and reason.

Correctness methodology

Correctness is defined by an independent Python reference oracle
(tools/reference_solution.py), kept structurally separate from the production code.
A tolerance comparator (tools/compare_results.py) checks equivalence by parsed value
(abs/rel 1e-9), not text.

• 16/16 test cases pass (14 computed fixtures + 2 loud-failure cases:
  tests/, run python tests/test_reference.py).
• Production output equals the oracle over the full 20-file dataset: 57,099
  rows, identical source_id set and order, all fields within 1e-9.
• A clean docker compose build --no-cache reproduces the output byte-identically
  (SHA-256 776a0e3e…).

Measured performance

Median ~101 s inside Run() on the development machine (three runs:
103.6 / 101.1 / 93.9 s, re-measured 2026-07-24). These are local measurements; runtime
is hardware-dependent and official moderator results may differ. Only the code
inside Run() is timed.

Output

• File: data/out/result.csv
• Rows (this dataset): 57,099
• SHA-256: 776a0e3ea95c5befa6663cdf3cfe176608b5745e5bb701d8ab0ea794aff6ed7e

Project notes

Design decisions, data profiling, and engineering reports are in docs/. The data/in/
inputs are the fixed challenge benchmark and are never modified.

License

See LICENSE.