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 (co-author, 3rd 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 →