Skip to main content

orbitplan

Feasibility planner for inference in orbit — find the constraint that's actually stopping you.

Three things decide whether a model can run in space, and they fight each other: the array has to make the power, the radiator has to shed the heat that power becomes, and the ground link has to carry whatever data survives. Optimising one in isolation is how orbital compute plans die. orbitplan reconciles all three against a real sensor or serving load and names the binding constraint.

Part of a set:

  • orbitherm — sizes the radiator (used automatically when installed)
  • radshield — keeps the model correct under radiation-induced bit flips

Install

pip install orbitplan            # core
pip install orbitplan[thermal]   # + orbitherm for the full thermal model

Quick start

import orbitplan as op

plan = op.MissionPlan(
    sensor=op.Sensor(burst_gb_per_s=10, duty_cycle=0.002),      # SAR instrument
    workload=op.Workload.preset("sar_segmenter", input_mb=800, output_mb=2),
    accelerator=op.Accelerator.preset("jetson_agx_orin"),
    power=op.PowerBudget(array_area_m2=8),
    thermal=op.ThermalBudget(radiator_area_m2=2),
    link=op.LinkBudget(band="x_band"),
)

r = plan.evaluate()
print(r.bottleneck)     # -> 'none'
print(r.summary())

Drop the onboard inference (output_mb=800) and the same satellite becomes downlink-bound: 1,728 GB/day of raw data against 72 GB/day of X-band capacity. That gap is the entire business case for processing in orbit.

What it models

Power — solar array output derated for cell efficiency, packing, eclipse fraction, battery round-trip and PMAD losses, minus bus overhead.

Thermal — the heat-rejection ceiling on sustained compute. Delegates to orbitherm when installed; falls back to a bare Stefan-Boltzmann estimate otherwise.

Downlink — contact time × rate × passes, derated for protocol overhead, versus the data actually produced. Anything the payload can't process has to go down raw.

Workload — energy and latency per inference from real accelerator efficiency (peak TOPS derated by an achievable-utilisation factor, which is where most naive estimates go wrong).

Verdicts

evaluate() returns a PlanResult whose bottleneck is one of:

value meaning
power the array can't sustain the processing load
thermal the radiator can't shed the heat that load produces
downlink compute keeps up, but the results still don't fit the link
none all three close, with margin

Every result carries the numbers behind the call — margins, watts required versus available, GB/day generated versus downlinked — so you can see how far off you are, not just that you failed.

Presets

Accelerators: jetson_orin_nx, jetson_agx_orin, nvidia_l4, nvidia_h100. Workloads: resnet50, vit_b16, yolov8m, sar_segmenter, llm_1b_token. Bands: s_band, x_band, ka_band, optical. All overridable.

Scope

First-order feasibility triage — for architecture trade studies, go/no-go calls and sanity-checking orbital compute claims. Not a substitute for detailed mission design: it assumes circular LEO, worst-case (β=0) eclipse geometry, an isothermal radiator, and steady-state operation.

License

Apache-2.0

Metadata

Release files for orbitplan 0.1.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for orbitplan 0.1.0
File Size Uploaded
orbitplan-0.1.0.tar.gz 14.1 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for orbitplan 0.1.0
File Interpreter ABI Platform
orbitplan-0.1.0-py3-none-any.whl Python 3 none any Details

Total release size: 28.8 kB

Release files / orbitplan-0.1.0.tar.gz

Download URL orbitplan-0.1.0.tar.gz
Size 14.1 kB
Tags Source
SHA-256 checksum
How to use checksums
1b6c30beb6f3c283225db6d9eafa88d4002924d1442026c33bc0dbe67700cc51
BLAKE2b-256 checksum
How to use checksums
5e7054955bdb4270e0bbe77ebe2788328a13e67caa95dfe60d5d43abdac78e85
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Jul 29, 2026.

Transparency log

Release files / orbitplan-0.1.0-py3-none-any.whl

Download URL orbitplan-0.1.0-py3-none-any.whl
Size 14.7 kB
Tags Python 3
SHA-256 checksum
How to use checksums
a56631705060a440c58d97695c7430ea274e0961f2aa3f50ea6a7e604dd74db2
BLAKE2b-256 checksum
How to use checksums
b46ca42d3998a6e178e8ce34b0943f47024daceeb0efc47bf816fa0fa712c6b5
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Jul 29, 2026.

Transparency log

Release history Release notifications | RSS feed

0.4.0

2 release files

0.3.0

2 release files

0.2.0

2 release files

This release

0.1.0 This release

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page