Other Simulation Codes (in development)
Mera 1.x is RAMSES only. Support for other simulation codes is in active development for version 2.0 and lives on the multicode branch. This page is the single place that says what exists, what does not, and how to try it.
docs/multicode_status.md in the repository is the collaborator view: which reader supports which function, what the tests actually prove, and the known gaps. It is not part of this site.
Status
| code | reader | status |
|---|---|---|
| RAMSES | in every release | complete, this is the reference implementation |
| PLUTO | multicode branch | in development |
| Chombo | multicode branch | in development |
| Athena++ | multicode branch | in development |
| FLASH | multicode branch | in development |
| GADGET / AREPO | multicode branch | in development, one reader for the shared HDF5 family |
Coverage is deepest for RAMSES. It is the only code with dedicated getgravity, getrt and getclumps readers, because it writes those to separate files. Where another code stores the same physics inside its snapshot, Athena++ phi, FLASH gpot, Chombo gravitational-potential, the reader maps it to the canonical field so getvar(gas, :gpot) works there too. AREPO and GADGET add particles and FoF group catalogues through getgroups; subhalos are not read.
Trying it
] add https://github.com/ManuelBehrendt/Mera.jl#multicodeThat branch is master plus the frontends, so everything documented on this site behaves the same there. It is never registered, so this URL form is the only way to install it.
These readers are newer and narrower than the RAMSES one, and are tested mainly against synthetic fixtures rather than a wide range of real snapshots. Treat results as provisional and check them against something you already trust. Bug reports and contributions move this forward quickly.
What already works on the release
This is the part that surprises people, so it is worth stating plainly: the analysis layer is code-blind and ships in every release. Only the readers are branch-specific.
Once data is in memory as a Mera object, getvar, subregion, projection, profile, filterdata, savedata and the rest do not know or care which code wrote it. That is why adding a code is mostly reader work rather than core work.
Two consequences:
- Physics written for another code's data model is already present in the release. The gas-particle thermodynamics used by the GADGET/AREPO family, computed from the specific internal energy
:urather thanp/ρ, is implemented and documented here. You simply cannot read such a snapshot without themulticodebranch. - Anything you learn from these pages transfers. There is no separate API to learn for another code, and no separate tutorial set.
Detection
On the multicode branch the code is detected from the folder contents. When detection fails, name it:
info = getinfo(path, code=:gadget)Those six symbols are the whole list, one per reader:
| symbol | reads |
|---|---|
:ramses | RAMSES |
:gadget | GADGET and AREPO, which share the same HDF5 snapshot family |
:pluto | PLUTO |
:chombo | Chombo |
:athena | Athena++ |
:flash | FLASH |
code= names the reader, not the code that wrote the file, and one reader serves the whole GADGET-HDF5 family. So there is no :arepo to pass: for an AREPO snapshot, use code=:gadget.
That does not mean Mera confuses the two. getinfo reads the producer out of the file and reports it, so info.simcode is "AREPO" for an AREPO snapshot and "GADGET" for a GADGET one, and the printed summary says so. You only need code= at all when detection fails.
See Troubleshooting for what an unrecognised folder looks like.
For maintainers
master is the 1.x release line and RAMSES only. multicode is master plus the frontends and is never registered. Work that is code-agnostic belongs on master and reaches multicode by merge; only reader-specific work lands on multicode directly. The merge is one way.