🔭 astrophysics

Compute System Organization for High Frequency High Order Wavefront Sensing and Control

This paper proposes offloading high-order wavefront sensing and control (HOWFSC) computations to a dedicated co-flying satellite at Sun-Earth L2, enabling the use of modern high-performance processors to achieve significantly faster control cadences and lower power consumption while maintaining the extreme stability required for the Habitable Worlds Observatory.

Original authors: Barry Lyu, Vaibhavi Manjarekar, Nathaniel Bleier

Published 2026-02-25

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Barry Lyu, Vaibhavi Manjarekar, Nathaniel Bleier

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are trying to take a photo of a tiny, glowing firefly sitting right next to a blindingly bright searchlight. The firefly is your exoplanet (a planet outside our solar system), and the searchlight is its host star.

To see the firefly, you need a special camera lens (a coronagraph) that blocks the searchlight's glare. But here's the problem: the lens isn't perfect. Tiny vibrations, heat changes, and even the movement of the telescope itself create tiny "ripples" in the light, like looking at the firefly through a wobbly window. These ripples make the firefly invisible again.

To fix this, the telescope has a "smart mirror" (a deformable mirror) that can wiggle its surface millions of times a second to cancel out those ripples. This process is called Wavefront Sensing and Control.

The Problem: The "Brain" is Too Slow

The paper argues that for the future Habitable Worlds Observatory (HWO), the current computers on the telescope are too slow to fix these ripples fast enough.

The Current Situation: The telescope's computer is like a super-protective, radiation-proof turtle. It's built to survive the harsh vacuum of space without breaking, but it's also very slow and old-fashioned. It can only adjust the mirror a few times a second.
The Consequence: Because it's too slow, the "ripples" in the light get worse between adjustments. The telescope loses the ability to see the faint firefly (the exoplanet).
The Alternative (Ground Control): You could send the photos back to Earth, let supercomputers there do the math, and send the instructions back. But Earth is too far away (about 1.5 million km). The signal takes 10 seconds to go there and back. By the time the instruction arrives, the mirror has already missed its chance to fix the ripple.

The Solution: The "Co-Pilot" Satellite

The authors propose a brilliant idea: Don't put the super-computer on the main telescope. Put it on a tiny, separate satellite flying right next to it.

Think of the main telescope as a luxury cruise ship that needs to stay perfectly steady. The new idea is to attach a small, high-speed speedboat right next to it.

The speedboat doesn't need to be as tough as the cruise ship (it doesn't need to be radiation-hardened).
It can carry a brand-new, incredibly fast modern computer (like the ones in your gaming PC or data centers).
Because the speedboat is only a few kilometers away from the cruise ship, they can talk to each other instantly.

Why This Changes Everything

Speed: The new computer can adjust the mirror 100 times a second (or even more), instead of just once a second. This keeps the "window" perfectly clear, allowing us to see the faint firefly clearly.
Cost & Risk: If the speedboat breaks or gets fried by space radiation, we just launch a new one. We don't risk the entire multi-billion dollar cruise ship.
Power: The paper dives deep into the "engine" of this new computer. They found that standard super-fast computers (like GPUs) are actually wasteful for this specific job. They are like using a massive diesel engine to power a bicycle; they burn too much fuel (electricity) and generate too much heat.

The "Memory" Bottleneck

The authors discovered that the real bottleneck isn't how fast the computer thinks, but how fast it can grab data.

The Analogy: Imagine a chef (the processor) who is incredibly fast at chopping vegetables. But if the vegetables are in a warehouse 10 miles away, the chef spends all their time driving back and forth, not chopping.
The Fix: The paper suggests building a custom computer where the "warehouse" (memory) is built right next to the "chef" (processor). This eliminates the driving time. They propose two ways to do this:
- HBM (High-Bandwidth Memory): Stacking memory chips like a tower of pancakes right next to the processor.
- SRAM (Distributed Memory): Breaking the memory into tiny chunks and placing a mini-chef right next to every single chunk. This is slower to build but uses way less electricity.

The Bottom Line

This paper is a blueprint for how to build a space-based "speedboat" to help our future telescopes see the universe's most distant and faint planets.

By moving the heavy math off the main telescope and onto a nearby, modern, and replaceable satellite, we can finally keep the "window" steady enough to find Earth-like worlds. It's a shift from trying to make the old, slow computer faster, to simply moving the job to a new, faster partner that lives right next door.

1. Problem Statement

The Habitable Worlds Observatory (HWO), a planned NASA flagship mission for the 2040s, aims to directly image Earth-like exoplanets by achieving a contrast ratio of $10^{-10}$ . This requires a high-contrast coronagraph and continuous High-Order Wavefront Sensing and Control (HOWFSC) to maintain a "dark hole" (a region of suppressed starlight) against thermal and mechanical drifts.

The core challenge is a computational gap:

Performance Requirements: LUVOIR-scale HOWFSC requires control cadences in the range of tens to hundreds of Hertz (optimal ~100 Hz) to maintain contrast.
Current Limitations:
- Onboard RadHard Processors: Current radiation-hardened spacecraft processors lack the throughput and memory bandwidth, falling short by 3–5 orders of magnitude.
- Ground-in-the-Loop (GITL): Offloading computation to Earth is constrained by the ~10-second round-trip light time to the Sun-Earth L2 point and limited downlink bandwidth, restricting control rates to sub-Hertz levels.
Consequence: Operating at low frequencies degrades achievable contrast by up to two orders of magnitude, significantly reducing the mission's exoplanet detection yield.

2. Methodology

The authors propose and evaluate a co-flying compute satellite architecture located near the primary observatory at L2. This satellite would host the HOWFSC processing pipeline using radiation-tolerant, high-performance commercial hardware, connected to the telescope via high-speed, low-latency inter-satellite links (ISL).

The methodology involves:

Algorithmic Analysis: Characterizing HOWFSC kernels (Pairwise Probing, Extended Kalman Filter, Electric Field Conjugation) using the Roofline Model to determine if they are compute-bound or memory-bound.
Hardware Evaluation: Benchmarking current and future hardware platforms (RadHard CPUs, Edge AI accelerators, Commercial GPUs like Nvidia H100/B200) against the algorithmic requirements.
Architectural Exploration: Designing custom, memory-centric architectures to overcome the limitations of general-purpose GPUs. Two specific custom designs are proposed:
- HBM-based Process-Near-Memory: Utilizing High Bandwidth Memory stacks.
- SRAM-only Distributed Memory: Using a hierarchical network of SRAM banks with co-located compute elements.
System-Level Modeling: Estimating power, mass, cost, and latency for these architectures, including inter-satellite communication overheads and radiation mitigation strategies.

3. Key Contributions

A. Identification of the Memory Bottleneck

The paper demonstrates that HOWFSC algorithms (specifically Electric Field Conjugation and EKF) are memory-bound, not compute-bound.

Operational Intensity: The algorithms have very low operational intensity (approx. 0.2–0.9 FLOPs/Byte).
Limiting Factor: Performance is constrained by memory bandwidth and capacity (requiring ~110 GB for LUVOIR-scale Jacobian matrices in double precision), not raw floating-point throughput.
Implication: Even the most powerful GPUs (e.g., Nvidia B200) are inefficient because their architectures are optimized for high operational intensity (AI workloads) and data reuse, which HOWFSC lacks.

B. The Co-Flying Compute Solution

The authors argue that offloading computation to a dedicated satellite at L2 is the only viable path to achieving high-frequency control.

Latency: Proximity (e.g., 100 km) reduces communication latency to ~1 ms, enabling control frequencies >100 Hz, whereas Earth-based links are limited to <0.1 Hz.
Hardware Flexibility: A companion satellite can use non-RadHard, radiation-tolerant commercial hardware, offering orders of magnitude better performance per watt than onboard RadHard processors.

C. Custom Architectural Designs

The paper proposes two custom architectures that significantly outperform commercial GPUs in energy efficiency:

HBM-Based Architecture: Uses 27 HBM modules to provide sufficient bandwidth. It reduces power from 3 kW (GPU baseline) to **939 W**.
SRAM-Only Distributed Architecture: A memory-centric design where compute elements are co-located with SRAM banks to eliminate off-chip memory traffic. This achieves the target 100 Hz control rate with only ~85 W of power, though it requires a large silicon area (~24,000 mm²).

D. Radiation Mitigation Strategy

The paper outlines a "defense-in-depth" strategy for using commercial CMOS hardware in space:

Inherent Tolerance: Leveraging modern FinFET/GAA process nodes which have improved radiation tolerance.
System-Level Protection: Using Error Correcting Codes (ECC) for memory, Algorithm-Based Fault Tolerance (ABFT) for matrix operations, Triple Modular Redundancy (TMR) for control logic, and a "graceful degradation" mode.
Replaceability: The satellite is designed as a replaceable unit, decoupling its lifetime from the multi-decade HWO mission.

4. Results

Performance Gains:
- RadHard (BAE RAD5545): ~0.05 Hz (insufficient).
- Commercial GPU (Nvidia B200): ~35 Hz (single GPU) to ~104 Hz (3-GPU cluster).
- Custom HBM/SRAM Architectures: Capable of sustaining 100–300 Hz control frequencies.
Power Efficiency:
- GPU Baseline: Requires >3 kW to approach 100 Hz.
- HBM Custom: ~939 W for 100 Hz.
- SRAM Custom: ~85 W for 100 Hz.
Cost Analysis:
- Mission cost is dominated by the power provisioning and mass of the satellite.
- A low-power (90 W) custom system results in a total mission cost of ~$203M (over 25 years).
- A high-power (3000 W) GPU-based system nearly triples the cost to ~$602M.
- Custom silicon NRE costs are offset by massive savings in recurring launch and operational costs.

5. Significance

This paper provides a critical systems engineering roadmap for the HWO and future flagship missions.

Feasibility: It proves that the extreme computational demands of LUVOIR-scale wavefront control are solvable without waiting for a breakthrough in RadHard processor technology.
Paradigm Shift: It advocates for a shift from "onboard processing" to "distributed space computing," where specialized, high-performance, replaceable satellites support the main observatory.
Energy Efficiency: By identifying memory bandwidth as the primary bottleneck, the paper guides hardware designers toward memory-centric architectures (HBM/SRAM) rather than general-purpose GPUs, drastically reducing the power and thermal load on the spacecraft.
Scientific Impact: Achieving high-frequency control is essential for maintaining the $10^{-10}$ contrast required to detect and characterize potentially habitable exoplanets, directly enabling the core science goals of the HWO.

In conclusion, the authors demonstrate that a co-flying compute satellite utilizing custom, memory-centric architectures is the most practical, cost-effective, and scientifically enabling solution for the high-frequency wavefront control required by the Habitable Worlds Observatory.