Shamrock
Shamrock 2025.10.0 #1337
tdavidcl
announced in
Announcements
Shamrock 2025.10.0
#1337
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
The first Shamrock release to achieve quasi-exascale performance!
Outstanding changes
Aurora testing (close to exascale)
These are just two of the numerous PRs that allowed Shamrock to exceed the 10,000-GPU milestone, resulting in an impressive performance milestone of 223 Gpart/s on 24,000 GPU tiles, with a parallel weak-scaling efficiency of 82.9%.
Solvergraphs
This one isn’t the simplest, but it stems from a major issue common to complex codes. As the number of features, physical models, and modules implemented in a solver continues to grow, the code paths become increasingly tangled — full of conditionals, deeply nested functions, and opaque data flows. The result is a solver that’s hard to read, hard to modify, and difficult to maintain.
To address this, we need to untangle the mess.
Following discussions with @thomasguillet and taking inspiration from softwares like Blender, Autodesk Maya’s Hypergraph, or Quest3D (for those who remember it!), we realized that what’s needed is a graph-based API to express data flow between abstract modules.
Here is an example of a composition of nodes from blender
The idea is to represent each component of the solver as a node in such a graph, where the final output corresponds to the solver’s state after one timestep. We plan to write a more detailed post, document, or paper on this topic, but the TL;DR is that we’ve already implemented this concept in Shamrock, in a system we call Solvergraphs. For example, in a Godunov scheme, the conversion between conservative and primitive variables would be represented as a single node, such as ConsToPrim, but we do not want the node to be self-contained and independant on the sources and targets.
Now, if we apply this approach to the full solver, we get the following (although Graphviz doesn’t do a very good job of organizing the layout...)
(grey = data, white = node)
With the new Solvergraph API, we can now express modules independently of the specific data they operate on. This greatly improves reusability, allowing modules to be used across the codebase with different sets of inputs and outputs.
The next step, planned for a future release, is to fully migrate all solvers to this API and further simplify development — both on the C++ side and through graphical external tools or Python bindings.
Others
Addition of Shamrock restart dumps to the Ramses solver:
Multiple analysis modules were added for SPH:
As well as features in setups:
The possibility of directly installing python bindings without having to fiddle with .so (s):
There have also been changes on the physics side, but you’ll have to check arXiv in the coming months (hopefully) for the details ;)
What's Changed
New Contributors
Full Changelog: v2025.05.0...v2025.10.0
This discussion was created from the release Shamrock 2025.10.0.
Beta Was this translation helpful? Give feedback.
All reactions