tl;dr: One particle-in-cell code to rule them all.
Entity
is a community-driven open-source coordinate-agnostic general-relativistic (GR) particle-in-cell (PIC) code written in C++17 specifically targeted to study plasma physics in relativistic astrophysical systems. The main algorithms of the code are written in covariant form, allowing to easily implement arbitrary grid geometries. The code is highly modular, and is written in the architecture-agnostic way using the Kokkos
performance portability library, allowing the code to efficiently use device parallelization on CPU and GPU architectures of different types. The multi-node parallelization is implemented using the MPI
library, and the data output is done via the ADIOS2
library which supports multiple output formats, including HDF5
and BP5
.
Entity
is part of the Entity toolkit
framework, which also includes a Python library for fast and efficient data analysis and visualization of the simulation data: nt2py
.
Our detailed documentation includes everything you need to know to get started with using and/or contributing to the Entity toolkit
. If you find bugs or issues, please feel free to add a GitHub issue or submit a pull request. Users with significant contributions to the code will be added to the list of developers, and assigned an emoji of their choice (important!).
Everyone is welcome to join our small yet steadily growing community of code users and developers; regardless of how much you are planning to contribute -- we always welcome fresh ideas and feedback. We hold weekly Zoom meetings on Mondays at 12pm NY time, and have a dedicated Slack channel where you can be easily added by emailing one of the maintainers. If you prefer to just join our Zoom meetings without the Slack involvement -- that's totally fine, just email, and we can send you the Zoom link.
Another way of contacting us is via GitHub issues and/or pull requests. Make sure to check out our F.A.Q., as it might help you answer your question.
Keep in mind, you are free to use the code in any capacity, and there is absolutely no requirement on our end of including any of the developers in your project/proposal (as highlighted in our Code of Conduct). When contributing, also keep in mind that the code you upload to the repository automatically becomes public and open-source, and the same standards will be applied to it as to the rest of the code.
- 🎸 Ludwig Böss {@LudwigBoess}
- 👀 Yangyang Cai {@StaticObserver}
- 💁 Alexander Chernoglazov {@SChernoglazov}
- 🍵 Benjamin Crinquand {@bcrinquand}
- 🧋 Alisa Galishnikova {@alisagk}
- 🚂 Evgeny Gorbunov {@Alcauchy}
- ☕ Hayk Hakobyan {@haykh}
- 🥔 Jens Mahlmann {@jmahlmann}
- 🐬 Sasha Philippov {@sashaph}
- 📻 Siddhant Solanki {@sidruns30}
- 🤷 Arno Vanthieghem {@vanthieg}
- 🐱 Muni Zhou {@munizhou}
master
branch contains the latest stable version of the code which has already been released.- Development on the core is done on branches starting with
dev/
. - Bug-fixes are being pushed to branches starting with
bug/
. - All
bug/
anddev/
branches must have an open pull-request describing in detail its purpose. - Before merging to the master branch, all the branches must first be merged to the latest release-candidate branch, which ends with
rc
, via a pull request. This can either be a major release:1.X.0rc
, or a patch release1.X.Yrc
. - Stale branches will be archived with a tag starting with
archive/
(can still be accessed via the "Tags" tab) and removed.