Hey Nyx team,
I am a massive fan of the AMReX framework and the scale at which Nyx operates for cosmological hydrodynamics. I am the lead architect of a related open-source project called the String-Star Manifold, and I wanted to open a discussion about an algorithmic overlap regarding cosmological grid scaling.
While our engine is built on a vastly different stack (pure JAX designed for TPU acceleration rather than C++/MPI), we recently tackled the shared problem of simulating metric expansion (the Hubble Flow) over an N-body spatial hash.
The Scaling Problem:
In standard grid-based solvers, applying the FLRW metric over long epochs usually forces the coordinate grid to physically grow, which can trigger massive memory reallocation overheads or complex boundary recalculations across nodes.
Our Algorithmic Approach ("Stretchy Boundaries"):
To completely bypass dynamic memory reallocation and maintain perfect $O(N \log N)$ complexity, we implemented what we call a "stretchy spatial hash."
Rather than resizing the grid cell arrays in memory, our engine keeps the memory structure perfectly static. Instead, at each epoch, we multiply the physical "mathematical bounds" of the grid (grid_min, grid_max, grid_res) by the dynamic cosmic Scale Factor $a(t)$ derived from the Friedmann equations.
The arrays remain static, but the physical volume they represent stretches. This allows us to aggregate distant macro-nodes with zero loss of computational efficiency.
Questions for the Nyx Architects:
Given how Nyx utilizes Adaptive Mesh Refinement (AMR):
- How does the AMReX framework handle the computational overhead of the expanding background cosmology? Do the base grids and refined levels physically scale in memory, or do you utilize a similar "co-moving coordinate" mathematical transformation to keep memory structures static?
- When tracking massive dynamic ranges (from cosmic voids down to dark matter halos), does the expanding metric introduce significant MPI communication overhead as particles cross the boundaries of stretching grid cells?
I realize our TPU/JAX approach is fundamentally different from exascale C++, but I am fascinated by how these grid-scaling physics problems are solved at your level.
If anyone is curious about the "stretchy" hash architecture or our relativistic time-dilation models, you can check out the source code or run the interactive engine here:
https://github.com/Rupayan52/String-Star-Manifold
https://colab.research.google.com/drive/1jU_KBP_PVUUk4sagIxJsA4NnRKCN2LBh?usp=sharing
Would love to hear how exascale mesh solvers handle the Hubble Flow under the hood!
Hey Nyx team,
I am a massive fan of the AMReX framework and the scale at which Nyx operates for cosmological hydrodynamics. I am the lead architect of a related open-source project called the String-Star Manifold, and I wanted to open a discussion about an algorithmic overlap regarding cosmological grid scaling.
While our engine is built on a vastly different stack (pure JAX designed for TPU acceleration rather than C++/MPI), we recently tackled the shared problem of simulating metric expansion (the Hubble Flow) over an N-body spatial hash.
The Scaling Problem:
In standard grid-based solvers, applying the FLRW metric over long epochs usually forces the coordinate grid to physically grow, which can trigger massive memory reallocation overheads or complex boundary recalculations across nodes.
Our Algorithmic Approach ("Stretchy Boundaries"):$O(N \log N)$ complexity, we implemented what we call a "stretchy spatial hash."
To completely bypass dynamic memory reallocation and maintain perfect
Rather than resizing the grid cell arrays in memory, our engine keeps the memory structure perfectly static. Instead, at each epoch, we multiply the physical "mathematical bounds" of the grid ($a(t)$ derived from the Friedmann equations.
grid_min,grid_max,grid_res) by the dynamic cosmic Scale FactorThe arrays remain static, but the physical volume they represent stretches. This allows us to aggregate distant macro-nodes with zero loss of computational efficiency.
Questions for the Nyx Architects:
Given how Nyx utilizes Adaptive Mesh Refinement (AMR):
I realize our TPU/JAX approach is fundamentally different from exascale C++, but I am fascinated by how these grid-scaling physics problems are solved at your level.
If anyone is curious about the "stretchy" hash architecture or our relativistic time-dilation models, you can check out the source code or run the interactive engine here:
https://github.com/Rupayan52/String-Star-Manifold
https://colab.research.google.com/drive/1jU_KBP_PVUUk4sagIxJsA4NnRKCN2LBh?usp=sharing
Would love to hear how exascale mesh solvers handle the Hubble Flow under the hood!