Hi Nadelyn,

The reproducibility and post-processing aspects sound potentially useful, but I think it is important to distinguish those from the computational feasibility of the proposed q~9 production runs.

For context, the Einstein Toolkit GW150914 gallery example

https://einsteintoolkit.org/gallery/bbh/index.html

is only q=36/29 ~ 1.24, yet it already requires about 98 GB of memory and 8,700 core-hours for a single run at the published resolution.

More importantly, that gallery resolution should not be regarded as production-quality simply because the example runs successfully. Etienne, Phys. Rev. D 110, 064045 (2024), arXiv:2404.01137, revisited essentially this setup. The gallery has puncture resolution M/28; Etienne increased this by 50% to M/42 and found that even M/42 lies slightly outside the convergent regime for that physical scenario. The TwoPunctures resolution also had to be increased because the gallery defaults produced initial-data constraint violations that dominated the early evolution.

A q~9 calculation is a substantially different computational problem. Standard estimates for unequal-mass BBH numerical relativity give computational cost growing at least quadratically with mass ratio: one factor comes from the increasing number of orbital cycles and another from the increasingly restrictive timestep needed to resolve the smaller object. The additional spatial resolution needed around the progressively smaller secondary increases the cost further.

Relative to the gallery's q~1.24,

So even the optimistic quadratic scaling already suggests of order 50 times the cost for a comparable single evolution. In practice, a q~9 moving-puncture calculation requires additional refinement around the smaller hole, and those extra refinement levels have significant memory, evolution, synchronization, prolongation, and communication overhead. The scaling is therefore worse than the simple quadratic estimate.

Moreover, the workflow you describe is not one such run: it includes an eccentricity-reduction pilot and three resolutions for convergence testing. Taken as a complete production campaign, I would therefore expect the resource requirement to be comfortably more than 100 times that of the gallery example, and potentially substantially more depending on starting separation, refinement hierarchy, required waveform accuracy, and CarpetX performance on the target machine.

For that reason, I would suggest separating two goals:

1.

Developing and validating the reproducible CarpetX workflow and post-processing infrastructure, which could certainly be useful independently. 2.

Demonstrating that a q~9, three-resolution production campaign is computationally feasible with an identified HPC allocation.

A sensible validation path might be to reproduce a lower-q case first, establish convergence at resolutions actually inside the convergent regime, measure the CarpetX scaling and memory requirements, and only then extrapolate those measurements to q~9. I would be hesitant to specify workstation-scale hardware for the q~9 production target before that exercise; this is much more naturally an HPC allocation problem.

The post-processing and validation helpers could still make a useful public contribution even if the eventual q~9 evolutions require substantially larger resources than presently anticipated.

Best,

-Zach

* * * Zachariah Etienne Prof. of Physics, U. of Idaho Adjunct Prof. of Physics & Astronomy, West Virginia U. https://etienneresearch.com https://blackholesathome.net

On Tue, Aug 25, 2026 at 9:20 AM Nadelynq via Users < users@einsteintoolkit.org> wrote:

Hello Einstein Toolkit users,

I’m Nadelyn Zoe King, an independent citizen scientist building a reproducible Einstein Toolkit/CarpetX workflow for a GW190814-like q≈9 compact-binary benchmark.

The package is intended to manage preflight, parameter rendering, an eccentricity-reduction pilot, three-resolution runs, Multipole/Psi4 collection, convergence and fixed-frequency-integration post-processing, and comparison against public GWOSC strain. I am not claiming completed COSMA8 results; the current goal is a transparent, independently reviewable workflow.

I would appreciate community guidance on whether the workflow is appropriately scoped for Einstein Toolkit, what machine and configuration assumptions should be documented, and whether a well-tested post-processing or validation helper would be useful as a public contribution. If appropriate, I can share the source repository, build/test logs, parameter templates, and a short reproducibility note.

Thank you for maintaining an open community around relativistic astrophysics software. I will also review the weekly-call and contribution guidance.

Best regards, Nadelyn Zoe King _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users