Large-Scale Showcases¶

Two packaged examples exercise a 1,584-satellite LEO shell over a full day. They demonstrate different scaling regimes: one materializes global coverage for three explicit cases; the other resolves regional demand and sparse inter-satellite routing for one network.

Both were executed successfully from the same installed, source-free Astraeus 0.3.0-alpha.5 candidate on an Ubuntu 26.04 x86-64 VPS with 8 logical CPUs, 30.6 GiB memory, SSD storage, and CPython 3.11.14. Use them as concrete planning context for this host and candidate; allow headroom for differences in hardware, storage, and workload configuration.

flowchart TB SHELL["1,584-satellite Walker shell · 24 hours · 120-second output cadence"] SHELL --> COVERAGE["Global coverage batch\n3 elevation-mask cases"] SHELL --> NETWORK["Regional service network\n2 gateways + sparse adjacent ISLs"] COVERAGE --> COVRESULT["Coverage sensitivity\n1.89 GB output"] NETWORK --> NETRESULT["Delivery and route evidence\n1.11 GB output"]

Qualification Snapshot¶

Evidence	Global coverage batch	Routed service network
Successful cases/runs	3/3	1/1
Wall time	668.45 s (11.14 min)	1,145.26 s (19.09 min)
Peak process-family RSS	16.39 GiB	5.02 GiB
Written output	1,891,664,204 bytes (1.89 GB)	1,112,033,452 bytes (1.11 GB)

Plan both compute and storage around the measured envelope, with headroom for the operating system and platform variation. The coverage batch has the larger memory requirement; the routed network has the longer wall time.

Preflight Before Execution¶

Memory preflight uses the resolved RunSpec dimensions to estimate the active process working set before stage execution. The current model projects 17.13 GiB for each large coverage child and 6.03 GiB for the routed service network, compared with observed peaks of 16.39 GiB and 5.02 GiB respectively.

Run the individual case dry-run before committing to the full workload:

astraeus run \
  astraeus-resources/examples/user/cases/large-leo-global-coverage-elevation-10.yaml \
  --dry-run

astraeus run \
  astraeus-resources/examples/user/large-leo-service-network.yaml \
  --dry-run

The other two coverage children have the same population, grid, duration, and cadence. Plan the batch with one worker so only one large child is active at a time. Review the reported projected_peak, threshold, status, and recommendations against the machine that will execute the study.

Global Coverage Sensitivity¶

large-leo-global-coverage.yaml is a serial three-case batch. Every child case retains the 1,584-satellite shell, 24-hour timeline, 5° global grid, and 120-second reporting cadence; the terminal elevation mask changes from 10° to 25° to 40°.

astraeus batch plan \
  astraeus-resources/examples/user/large-leo-global-coverage.yaml

astraeus batch run \
  astraeus-resources/examples/user/large-leo-global-coverage.yaml \
  --workers 1

Serial execution bounds the number of large coverage grids resident at once. The qualified results show a coherent reduction in covered-surface fraction as the elevation requirement tightens:

Minimum elevation	Covered-surface fraction
10°	93.74%
25°	86.60%
40°	84.36%

The batch summary is the comparison entry point. Each child run also retains its own manifest, state timeline, pointwise coverage data, represented-area summary, and gap statistics for deeper inspection.

Large Routed Service Network¶

large-leo-service-network.yaml couples the shell to three bounded demand regions, two separated gateways, and sparse Walker-adjacent ISLs. It is a single core RunSpec, so the Console can open its geometry, routes, timelines, and Analysis artifacts directly.

astraeus run \
  astraeus-resources/examples/user/large-leo-service-network.yaml \
  --run-id large-leo-service-network \
  --strict

The qualified run delivered all admitted demand. Sparse routing was material to the result:

Network KPI	Qualified result
Delivery success	100%
Paths using more than one hop	82.06%
Mean hops	2.54
p95 hops	5
Maximum hops	7

Review transport/transport_summary.json for the delivery ledger, transport/isl_summary.json for topology state, route artifacts for selected paths, and the global latency histogram for timing. Gateway and regional KPI tables show where the admitted traffic entered and left the network.

Operational Review¶

Give the run a dedicated output root and keep the monitor available throughout execution:

astraeus monitor serve --runs-root runs

After completion, verify the run or grouped manifest first, then review warning and degraded-stage counts before interpreting KPIs. Use deterministic review and report commands for a portable summary; open the same saved evidence in the Console for spatial and time-dependent inspection.

For a shorter coupled study suitable for learning the full interpretation workflow, use the Integrated Constellation Case Study.