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.