Einstein Toolkit != Cactus

[Zach Etienne]

When following the download instructions

https://einsteintoolkit.org/download.html

a directory named Cactus is populated. This directory should be named EinsteinToolkit . This is purely an historical artifact, and goes completely against our philosophy that ET is more than just Cactus (because it is!) As this is the first thing that new users typically see, it’s very important that we get our messaging straight.

Ideally we fix this before the May 2023 release.

[Roland Haas]

Priority

Value	Meaning
blocker	The ET does not build, or another problem which means development cannot continue.
critical	At least one important thorn cannot be used, or something else is severely broken.
major	Needs to be fixed before release, or documented as broken in release notes
minor	Not important enough to necessarily look at before a release
trivial	Very low priority, though maybe not trivial to implement

Since this does not got imply that the ET does not build, or another problem or otherwise means development cannot continue.

Not a blocker. Please don’t abuse priorities.

[Roland Haas]

Note that what is in the “Cactus” directory is actually Cactus. For the non-cactus based codes (SelfForce1D and kuibit) we (have to, since they do not work well with GetComponents) provide separate download instructions.

So certainly what GetComponents downloads is not all of the Einstein Toolkit.

[Zach Etienne]

There are a number of modules that don’t depend on Cactus in the Cactus directory, including NRPyPN, and ExternalLibraries.

Maybe a directory structure should be created under EinsteinToolkit/ , including Cactus, SelfForce, NRPyPN etc? Also wouldn’t it be best if the download directions for the Einstein Toolkit downloaded the entire Toolkit, instead of separate instructions for other modules under the ET umbrella?

Yeah sorry I was confused of the definition of “blocker”, thanks for clarifying. Still I believe this should be fixed, as one of the top priorities for the next release.

[Gabriele Bozzola]

I recently gave a tutorial on the Einstein Toolkit, and made this (confusing) image to explain how I personally see our ecosystem.

* The Einstein Toolkit is in the red circle. It includes several different modules.

* The most important module is Cactus, a high-performance computational infrastructure.

* Einstein Toolkit includes several components that are built on top of Cactus, these are called thorns (green circle). Several thorns that are not part of the Einstein Toolkit exist, some open-source, many private. It is perfectly acceptable for a research group to develop their own thorns for internal use.

* Some of the thorns interact with tools that are not part of the Einstein Toolkit (e.g., LORENE, but also GSL). I call them bridges because they interface codes that are developed completely outside of ET and bring functionalities in.

* The Einstein Toolkit also contains codes that do not depend on Cactus at all. I call them stand-alone codes, such as Self-force-1D.

* The Einstein Toolkit comes with several *utilities*, some that interact with Cactus based codes (e.g., kuibit), some that do not. There exist several utilities that work closely with the Einstein Toolkit but are not part of the ET.

* Finally, the Einstein Toolkit would not exist without a decent amount of *infrastructure*. In my personal view, this infrastructure is part of the project and its value.

EDIT: The formatting broke for some reason, hopefully the message is readable.

[Roland Haas]

Note that there is also the SelfForce-1D code which is part of the ET but not related to Cactus at all. http://einsteintoolkit.org/components.html has a partial list.

[Gabriele Bozzola]

Indeed, I listed it among the stand-alone codes in my message (and the icon in the plot was supposed to represent it)