#2963: ET website inconsistency on Kuibit version for ET_2026_05
Reporter: Jordan Nicoules
Status: open
Milestone: ET_2026_05
Version:
Type: bug
Priority: trivial
Component: EinsteinToolkit website
Changes (by Roland Haas):
status: open (was new)
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2963/et-website-incons…
#2962: Split the ET
Reporter: Steven R. Brandt
Status: new
Milestone:
Version:
Type: enhancement
Priority: major
Component: Cactus
Current toolkit problems:
(1) CarpetX replaces low-level interfaces, e.g. ADMBase with ADMBaseX which leads to massive breakage and duplication of code.
(2) The list of thorns in the ET has become massive. It takes a long time to compile and test.
(3) There's always been this ambiguity in the name of our software product vs. the name of the umbrella name. I.e. the thing built from einsteintoolkit.th is "The Einstein Toolkit", but the same term applies to the thing build from einsteintoolkit.th and to Peter's self-force code collectively.
Proposed solution to all of these problems:
Split into two thornlists, one for carpet and one for carpetx, each to be built and tested separately. This means, for example, that ADMBaseX could be renamed to ADMBase and still remain completely distinct. TwoPunctures could compile and run without modification in either collection of thorns.
In addition, we could provide flags -DCARPET or -DCARPETX which thorns could use to write conditional code if only a minor modification would be needed to make a code compatible with either framework.
A little farther down the road down the road, we might consider renaming ODESolvers to MoL and making them look a little more uniform.
Each codebase would have a distinct name: "The Carpet Toolkit"/"The CarpetX Toolkit" seem fairly logical. It would also eliminate the ambiguity in the name ET.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2962/split-the-et
#2961: util_ExpressionEvaluate fails with custom evaluator
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component: Cactus
Comment (by Roland Haas):
Now it does. One needs to name a variable with a ""::" in it (note that `util_ExpressionEvaluate` is not supposed to make *any* assumption about the allowed names of variables).
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2961/util_expressionev…
#2961: util_ExpressionEvaluate fails with custom evaluator
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component: Cactus
Comment (by Roland Haas):
Uh, correction, the SEGFAULT was a fault of mine. Now of course the simple test case works. Will need to make it more like Trigger t trigger a failure I guess.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2961/util_expressionev…
#2961: util_ExpressionEvaluate fails with custom evaluator
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component: Cactus
The piraha provides `util_ExpressionEvaluate` fails when passed a custom evaluator.
For Trigger (see #1077) it tries to evaluate a string itself (it should pass it to the evaluator) for the test case of the original utils code (in cactustest/testexpr https://bitbucket.org/cactuscode/cactustest/branch/rhaas/testexpr) it produces a SEGFAULT (parfile is in par).
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2961/util_expressionev…