[Users] Community question — reproducible q≈9 GW190814-like workflow for Einstein Toolkit

[Zach Etienne]

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 at 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 at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20260827/b22e04f8/attachment-0001.htm>