When to Compute in Space paper under review

Overview

The starting point was an existing single-utility model that scored each compute location with one weighted number. I reframed the problem as multi-objective trade-space search: the decision variable is a policy vector on the probability simplex over compute tiers — a fractional split of the workload, not a hard single-tier pick — and the answer is the Pareto front of feasible splits. Weights only change how you navigate the feasible region, not the region itself, so a Pareto view is more honest than one utility number.

I built the two-stage framework, both mission evaluators, and the benchmarked optimizer suite; that work became the computational core of the journal paper (second author, 2nd of 4), submitted to the AIAA Journal of Aerospace Information Systems and currently under review.

Design decisions 05

• The decision splits into two stages — discrete flight-computer selection by weighted utility under hard TRL and radiation gates, then continuous workload routing over the simplex — because hardware is picked once while the routing policy varies per workload; mixing them wastes evaluations re-deriving the same processor choice.
• Optimizer steps stay feasible by Euclidean projection onto the simplex, and hard mission constraints (latency caps, radiation margin) are handled with constraint-domination — a feasible solution beats an infeasible one; two infeasibles rank by violation magnitude — so no penalty weight needs hand-tuning.
• Six optimizers (NSGA-II, SPEA2, MOEA/D, MOPSO, ε-constraint sweep, projected gradient) run behind one uniform archive interface, so why one algorithm beats another on this problem is directly comparable on hypervolume, spacing, and feasible rate.
• The original model’s missing-data penalty was rejected as an ad-hoc risk knob: a tier with missing metrics instead contributes only through its known metrics, renormalized over present variables — so novel architectures with sparse data, like orbital data centers, are not systematically penalized.
• A purely linear evaluator makes objectives piecewise-linear in the policy, collapsing scalarizations onto simplex vertices — so a second, nonlinear evaluator was built from seven named subsystem couplings drawn from spaceflight engineering (M/M/1 queueing on latency, contact-window saturation, link-setup energy, security-protocol overhead, thermal-margin degradation, congestion-driven link availability, silent-data-corruption compounding), each an independent penalty that can be disabled and ablated. All seven carried into the paper intact.

Python · NSGA-II · SPEA2 · MOEA/D · MOPSO · ε-constraint · projected gradient

paper write-up → code ↗

listed under research & publications →