Skip to content

Campaign Performance

Campaign cost is driven primarily by satellite mission solves and optional per-mission artifacts. Choose execution settings from the campaign scale and the memory available on the target machine.

solver:
  mission_artifact_detail: summary
  mission_execution_backend: auto
  mission_worker_count: 4
  mission_auto_parallel_threshold: 20
  emit_execution_diagnostics: true
  • summary avoids writing a side bundle for every satellite.
  • auto remains serial below the threshold and selects bounded process workers above it.
  • four workers is the default starting point; tune the worker count for the available CPU, memory, and campaign workload.
  • serial is useful for small cases, constrained systems, and deterministic diagnosis of one mission path.
  • thread is reserved for explicit diagnostics; solver-heavy campaigns should normally use process or auto.

Equivalent CLI overrides are:

astraeus campaign-plan run --input <request.yaml> --mission-artifact-detail summary --mission-execution-backend auto --mission-workers 4 --mission-auto-parallel-threshold 20 --campaign-execution-diagnostics

Scale Carefully

Before increasing campaign size:

  1. validate and run a small representative request
  2. confirm assignment, sequence, and mission-result semantics
  3. measure wall time and memory with summary artifacts
  4. increase workers only while memory and throughput improve
  5. reserve full mission artifacts for targeted investigation

More workers can reduce wall time but multiply active solver memory. The best setting depends on mission complexity as well as satellite count.

Diagnostics

When execution diagnostics are enabled, inspect:

Diagnostic Use
campaign_mission_executor requested and effective backend, workers, timeout policy, and ordering
campaign_mission_bridge_timing total request-generation and mission-solve time
campaign_mission_timing per-satellite status and timing outliers
campaign_artifact_policy summary/full selection and side-bundle count
campaign_mission_solve_cache_summary exact-cache eligibility, hits, and misses

Use aggregate executor and bridge diagnostics before opening per-mission traces.

Exact Mission Reuse

An opt-in per-run cache can reuse successful mission solves whose normalized physical and solver inputs are exactly equal:

solver:
  parameters:
    mission_solve_cache_enabled: true

Identity-only differences may still be reusable. Different orbit targets, release epochs, phase slots, spacecraft or propulsion properties, tolerances, or solver settings produce distinct cache identities. The cache reports its decisions in the campaign summary and diagnostics.

Use the cache only when the campaign intentionally contains repeated physical mission requests. A low hit count is expected when assignments or release context differ.

Operational Guidance

  • Keep summary artifacts for routine large campaigns.
  • Use the Run Monitor for long-running visibility.
  • Preserve execution diagnostics with benchmark or qualification evidence.
  • Compare result semantics across backend changes, not wall time alone.
  • Fall back to serial when a target machine shows instability or no useful speedup.