🔭 astrophysics

Mercury-Opal: the GPU-accelerated version of the n-body code for planet formation Mercury-Arxes

This paper introduces Mercury-Opal, a GPU-accelerated version of the Mercury-Arxes n-body planet formation code implemented via OpenACC to ensure cross-platform compatibility and demonstrate performance advantages over CPU-serial execution even under limited computational loads.

Original authors: Paolo Simonetti, Diego Turrini, Romolo Politi, Scigé J. Liu, Sergio Fonte, Danae Polychroni, Stavro Lambrov Ivanovski

Published 2026-01-28

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Paolo Simonetti, Diego Turrini, Romolo Politi, Scigé J. Liu, Sergio Fonte, Danae Polychroni, Stavro Lambrov Ivanovski

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 trying to predict how a crowded dance floor will evolve over millions of years. You have a few big, heavy dancers (planets) and thousands of tiny, lightweight dancers (dust and rocks) all swirling around a central spotlight (a star). Every time two dancers get too close, they might bump, merge, or fling each other away. To figure out where everyone ends up, you have to calculate the gravitational pull between every single pair of dancers at every single moment.

This is the challenge of N-body simulations in planet formation. For a long time, scientists used standard computer processors (CPUs) to do this math. It's like having one very smart accountant trying to add up the interactions of a million people one by one. It works, but it takes a long time.

This paper introduces Mercury-Opal, a new, supercharged version of a famous planet-forming code called Mercury-Arχes. Here is the simple breakdown of what they did and why it matters:

1. The Problem: The "One Accountant" Bottleneck

The original code, Mercury-Arχes, was already quite good. It could simulate planets forming in a disk of gas and dust. However, as scientists wanted to simulate more planets and more dust particles to get a clearer picture, the "accountant" (the CPU) started to get overwhelmed. The more bodies you add, the harder the math gets, and the longer the simulation takes.

2. The Solution: Hiring a "Gym Class" of Accountants

The authors decided to move the heavy lifting from a single accountant to a whole gym class of accountants working simultaneously. In computer terms, they moved the code from a standard CPU to a GPU (Graphics Processing Unit).

Think of a CPU as a single, highly intelligent professor who solves complex math problems one at a time. A GPU is like a stadium filled with thousands of students who are slightly less individually brilliant but can all do simple math problems at the exact same time. Since the job of calculating gravity involves doing the same type of math for thousands of different bodies, the "stadium" (GPU) is perfect for the job.

3. The Trick: Using "OpenACC" (The Universal Translator)

Moving code from a CPU to a GPU is usually like trying to translate a book from English to a completely alien language; you often have to rewrite the whole story from scratch.

The authors used a tool called OpenACC. Think of OpenACC as a universal translator or a set of sticky notes. Instead of rewriting the entire code, they just stuck notes on the specific parts of the code that needed to be done in parallel. This allowed them to keep most of the original "story" (the physics and logic) intact while telling the computer, "Hey, do this part for everyone at once."

This was a smart choice because:

It saved them from rewriting the whole code (saving time).
It made the code work on different types of computers (portability).
It kept the code readable for other scientists.

4. The Results: Speed vs. Reality

They tested Mercury-Opal on a standard, consumer-grade laptop computer (the kind you might buy at a store), not a supercomputer. This was a "stress test" to see if it could handle the load even on modest hardware.

Small Simulations (Few Planets): When there were only a few planets (like 1 to 100), the GPU was actually slower than the CPU. Why? Because setting up the "gym class" takes time. If you only have 5 people to teach, it's faster to just do it yourself than to organize the whole class.
Large Simulations (Many Planets): Once they added more bodies (up to 1,000), the GPU started to shine. It became 2.2 times faster than the CPU.
The Future: The paper notes that for the massive simulations scientists really want to run (with 100,000+ bodies), the GPU speedup will be even more dramatic, potentially making simulations that used to take years finish in days.

5. Did the Math Still Work?

A major concern with using a different type of computer is whether the answers change. If you ask a professor and a gym class to solve the same problem, do they get the same result?

The authors checked this rigorously. They ran simulations for 100,000 years and compared the results.

Energy Conservation: The total energy of the system stayed the same in both versions.
Orbital Paths: The planets ended up in the exact same spots with the same speeds.
Conclusion: The GPU version is just as accurate as the CPU version; it just gets there faster.

Summary

Mercury-Opal is a new, faster way to simulate how planets are born. By using a "universal translator" (OpenACC) to move the heavy math calculations to a graphics card (GPU), the authors created a tool that can handle much larger, more detailed simulations of planet formation than before. While it's not faster for tiny simulations, it is a game-changer for the massive, complex simulations needed to understand how our solar system and others came to be.

Technical Summary: Mercury-Opal

Problem Statement
Large-scale $n$ -body simulations involving fully interacting objects represent a critical frontier in computational planetary formation studies. While the general-purpose integrator Mercury (Chambers, 1999) and its specialized parallel extension Mercury-Arχes (Turrini et al., 2019, 2021) have enabled detailed modeling of planet formation, they are constrained by the computational efficiency of their dynamical algorithms and available hardware resources. Current CPU-based parallelism (e.g., via OpenMP) allows for simulations of $\sim 10^5$ bodies over $\sim 10^7$ years, but managing a fully interacting set of $\sim 10^5$ bodies remains challenging due to the $O(N^2)$ scaling of gravitational interactions. The transition to GPU-accelerated computing offers increased computational density and energy efficiency but requires careful data management and code restructuring to overcome limitations in GPU internal RAM and host-device bandwidth.

Methodology
The authors present Mercury-Opal, a GPU-accelerated version of Mercury-Arχes, developed using the OpenACC 3.3 specification. The choice of OpenACC was driven by the need to minimize deep code restructuring while retaining performance gains and ensuring cross-platform support.

Key methodological steps included:

Profiling: Serial execution of Mercury-Arχes was profiled across varying numbers of massive bodies ( $N_{big}$ ). The analysis identified the mdt_hy subroutine (handling gravitational and non-gravitational forces) as the primary computational bottleneck, consuming up to 68% of the runtime for large $N$ .
GPU Porting Strategy:
- Parallelization: The mdt_hy routine was ported to the GPU, encompassing force calculations (gravitational and gas drag), Keplerian drift, and collision checks.
- Exclusion of Bulirsch-Stoer: The mdt_hkce routine, which handles close encounters via Bulirsch-Stoer integration, was kept on the CPU (host). This decision was made because close encounters involve a small, irregular subset of bodies (<1%), leading to load imbalance and limited parallelization gains, while keeping the data transfer volume low.
- Code Restructuring: To accommodate OpenACC stack size limits (512 kB), large routines (mfo_drct, arxes_gas, mce_snif) were unpacked and moved directly into mdt_hy.
- Language Conversion: The integrated WHFAST library was converted from C99 to Fortran to resolve compilation errors in the Fortran-C interface and slightly improve serial execution efficiency.
Data Management: A data region encompassing mdt_hy was defined. Scalar disk parameters are copied once; position, velocity, and mass arrays are transferred at the start and end of the region. If close encounters are detected on the GPU, specific arrays (indices of interacting bodies) are transferred to the host for CPU-based integration, and updated positions are sent back.
Testing Environment: Tests were conducted on consumer-grade hardware (Intel Core i5-10200H CPU and Nvidia GeForce RTX 3060 mobile GPU) to stress-test the GPU code under conditions favoring the CPU (specifically, the GPU's lower double-precision performance).

Key Contributions

Mercury-Opal: The first GPU-accelerated implementation of the Mercury-Arχes code, enabling the simulation of planet formation with fully interacting bodies.
OpenACC Implementation: Demonstrates that OpenACC can effectively port complex, multi-physics $n$ -body codes with minimal restructuring, maintaining the physical recipes of the original code (including disk-planet interactions and aerodynamic drag).
Hybrid Execution Model: Establishes a hybrid approach where the bulk of the $O(N^2)$ force calculations run on the GPU, while the complex, irregular logic of close encounter integration remains on the CPU to avoid data transfer bottlenecks and load imbalance.

Results

Performance:
- For small numbers of bodies ( $N \lesssim 100$ ), the GPU execution is slower than serial CPU execution due to kernel launch overhead and data transfer costs.
- For $N=1000$ , the GPU-parallel execution achieves a speedup ( $S_w$ ) of 2.2 over the serial CPU execution.
- When normalized to the 1-body case (relative speedup $S_1$ ), the GPU is 16 times faster at $N=1000$ .
- Profiling with Nvidia Nsight Systems indicates that data transfer operations account for less than 1% of the total wall time for large $N$ , with the primary efficiency loss attributed to the CPU-bound mdt_hkce routine.
Accuracy and Stability:
- Energy conservation tests over $10^5$ years show relative energy oscillations within $\sim 10^{-13}$ for both serial and GPU runs, consistent with the original Mercury-Arχes performance.
- Orbital parameter evolution (eccentricity and semi-major axis) in $N=10$ and $N=100$ systems shows negligible deviation between serial and GPU runs, confirming that the GPU port does not introduce significant numerical errors.

Significance
The paper claims that Mercury-Opal provides the planetary science community with a physically realistic and efficient integrator for formation-to-observation simulation campaigns, specifically supporting the preparation of the ESA Ariel mission. By leveraging GPU acceleration, the code allows for the modeling of larger numbers of fully interacting bodies than previously feasible with CPU-only parallelism, addressing the computational bottleneck of $O(N^2)$ interactions. The authors emphasize that the use of OpenACC ensures the code remains accessible and portable, facilitating its adoption by the broader community without requiring deep expertise in low-level GPU programming. The work validates that even on consumer-grade hardware with suboptimal double-precision performance, GPU acceleration offers a tangible advantage for large-scale $n$ -body simulations.