Entity

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!).

Join the community

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.

Contributors (alphabetical)

• 🎸 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}

Branch policy

• 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/ and dev/ 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 release 1.X.Yrc.
• Stale branches will be archived with a tag starting with archive/ (can still be accessed via the "Tags" tab) and removed.