From trac-noreply at einsteintoolkit.org Thu Jul 2 11:31:28 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Thu, 02 Jul 2026 16:31:28 +0000 Subject: [ET Trac] #2956: CarpetX: Allow conditional expressions after SCHEDULE declarations Message-ID: #2956: CarpetX: Allow conditional expressions after SCHEDULE declarations Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: enhancement Priority: minor Component: CarpetX Current Cactus/CarpetX behavior allows conditional expressions in `schedule.ccl`, but only before a `SCHEDULE foo` block. This means that routines whose `READS`/`WRITES` or other actions/metadata that depend on runtime parameters currently require multiple near-duplicate schedule blocks, one for each branch. For example, a routine such as `function_set_xyz` may optionally read or write gridfunctions `x`, `y`, and `z` depending on parameters such as `param_set_x`, `param_set_y`, and `param_set_z`. Scheduling each branch properly would take 2^3 = 8 schedule blocks. Allowing (single or multiple) conditional expressions after the scheduled routine declaration would let one schedule block cover all branches of behavior. The parser/build system could expand the conditional schedule metadata at compile time, while the actual selected branch would still be determined at runtime from result of the conditionals. Should be a relatively safe,"opt-in" style feature that requires a thorn to move their conditionals somewhere that previously was invalid. In principle it does admit some risk if used improperly. A thorn could cover all possible branches determined by runtime parameters without explicitly scheduling them, supporting some branches of behavior accidentally. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2956/carpetx-allow-conditional-expressions -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jul 2 11:33:50 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Thu, 02 Jul 2026 16:33:50 +0000 Subject: [ET Trac] #2956: CarpetX: Allow conditional expressions after SCHEDULE declarations in schedule.ccl Message-ID: #2956: CarpetX: Allow conditional expressions after SCHEDULE declarations in schedule.ccl Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: enhancement Priority: minor Component: CarpetX Changes (by Maxwell Rizzo): title: CarpetX: Allow conditional expressions after SCHEDULE declarations in schedule.ccl (was CarpetX: Allow conditional expressions after SCHEDULE declarations) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2956/carpetx-allow-conditional-expressions -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jul 2 12:40:44 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Thu, 02 Jul 2026 17:40:44 +0000 Subject: [ET Trac] #2957: Discussion: Support multiple centering options for Cactus/CarpetX Grid Functions Message-ID: #2957: Discussion: Support multiple centering options for Cactus/CarpetX Grid Functions Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: enhancement Priority: minor Component: Continuing a discussion from a few CarpetX calls: Current Cactus/CarpetX supports Grid Functions (GFs) with a single selected choice of centering (cell centered ccc, vertex centered vvv, face centered/edge centered). Thorns ADMBaseX/HydroBaseX/TmunuBaseX and similar are used in exchanging and providing unified storage for GFs between evolution thorns and diagnostic / initial data thorns. The BaseX thorns makes a centering choice, provides the storage for the GFs, and some initial zeroing routines. This presents an issue if the user want to use thorn that modifies or claims partial ownership of similar fields from the BaseX thorns, typically an evolution thorn. If this thorn needs a different centering option for one or more GF, it cannot use the BaseX GFs properly from the mismatch in centering. Current workarounds are: 1. The user can exchange GFs between thorns that have mismatches in centerings, being careful of differences in shape. 2. The user can couple the thorns directly and remove the BaseX handoff for those GFs, adding a thorn dependency and storing near redundant GFs. 3. The user can modify their evolution code to properly interpolate back and forth, resulting in near duplicate GFs at different centering, increased memory and decreased performance from the added interpolation. This issue arises more specifically in different evolution formulations for GRMHD, some use a cell centered magnetic field while others a face centered one. From today's CarpetX call, there was hesitance, as breaking from the convention that a thorn declares single centering GFs could have major implications for compiling/running Cactus/ CarpetX. For the BaseX thorns multiple centerings might be fairly straightforward as the only centering specific actions are the zeroing routines, which are about as trivial as it gets, for more complicated applications of multiple centerings it is less obvious how to proceed. Possible generic solutions: 1. An opt-in style where all thorns with single centering GFs behave as normal and thorns could declare multiple specific centerings for GFs that are flexible. This probably would be the most invasive Cactus/CarpetX wise, providing the most flexibility. 2. BaseX (or simliar behaving thorns) can provide separate GFs for different supported centerings, say `foo_cellcen` and `foo_vertcen`, and a parameter to toggle the between the two. With conditional storage this can be done as to not reduce the amount of evolved GFs, but does increase the amount of knobs the user needs to turn correctly for BaseX thorns, which should have a minimal amount of runtime parameters. 3. The problem is possibly specific to just HydroBaseX/ADMBaseX/TmunuBaseX, and specific solutions might be simpler than a general one. Liwei suggested that the magnetic field shouldn't be included in HydroBase at all, not qualifying as a pure Hydro quantity. 4. A built in generic interpolation routine into the BaseX thorns to handle the mismatch, basically workaround 3 but centralized into the BaseX thorn to reduce the amount of duplicate implementations. Probably not advisable for similar reasons listed above. Overall there is no immediate issue, there are current workarounds of direct coupling of thorns bypassing the BaseX thorns, simply using a GF as a different centering than it is, or interpolating. It may be worthwhile to address this in anticipation of future evolution thorns which do not follow the centering conventions set forth by BaseX thorns. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2957/discussion-support-multiple-centering -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jul 7 11:51:19 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Tue, 07 Jul 2026 16:51:19 +0000 Subject: [ET Trac] #2958: Regression in TwoPuncturesX Message-ID: #2958: Regression in TwoPuncturesX Reporter: Steven R. Brandt Status: new Milestone: ET_2016_05 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn The recently added TwoPuncturesX thorn broke the gallery example. The reason was that the gallery example uses "give_bare_mass = no", invoking a code path not used by any of the tests. In this code path, the parameters were updated with ParameterSet, however the copies of the parameters used by the refactored TwoPuncturesX did not get updated. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2958/regression-in-twopuncturesx -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jul 7 11:56:07 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 07 Jul 2026 16:56:07 +0000 Subject: [ET Trac] #2958: Regression in TwoPuncturesX Message-ID: #2958: Regression in TwoPuncturesX Reporter: Steven R. Brandt Status: new Milestone: ET_2016_05 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Comment (by Roland Haas): Pull request is here: https://bitbucket.org/einsteintoolkit/einsteininitialdata/pull-requests/25 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2958/regression-in-twopuncturesx -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jul 7 11:56:13 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 07 Jul 2026 16:56:13 +0000 Subject: [ET Trac] #2958: Regression in TwoPuncturesX Message-ID: #2958: Regression in TwoPuncturesX Reporter: Steven R. Brandt Status: new Milestone: ET_2016_05 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Comment (by Roland Haas): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2958/regression-in-twopuncturesx -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jul 7 11:57:44 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 07 Jul 2026 16:57:44 +0000 Subject: [ET Trac] #2958: Regression in TwoPuncturesX Message-ID: #2958: Regression in TwoPuncturesX Reporter: Steven R. Brandt Status: new Milestone: ET_2016_05 Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): priority: major (was blocker) Comment (by Roland Haas): not a "blocker" in that it does not prevent compilation. https://docs.einsteintoolkit.org/et-docs/Tickets#Priority Possibly "critical" depending on how important one deems TwoPunctures(X) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2958/regression-in-twopuncturesx -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jul 7 12:00:49 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 07 Jul 2026 17:00:49 +0000 Subject: [ET Trac] #2958: Regression in TwoPuncturesX Message-ID: #2958: Regression in TwoPuncturesX Reporter: Steven R. Brandt Status: new Milestone: ET_2016_05 Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): With a better commit message, please. ``` : ``` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2958/regression-in-twopuncturesx -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jul 7 16:12:22 2026 From: trac-noreply at einsteintoolkit.org (Beyhan Karakaş) Date: Tue, 07 Jul 2026 21:12:22 +0000 Subject: [ET Trac] #2959: Include BHNSTracker Message-ID: #2959: Include BHNSTracker Reporter: Beyhan Karaka? Status: new Milestone: Version: development version Type: enhancement Priority: major Component: EinsteinToolkit thorn BHNS gallery example currently depends on `PunctureTracker` and `VolumeIntegralGRMHD`. Rahime and I wrote `BHNSTracker` to better track the stars. It has been tested for low resolution and it is now being tested for high resolution simulations. Once confirmed, it will be ready for a review for inclusion for the next release. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2959/include-bhnstracker -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jul 7 16:18:01 2026 From: trac-noreply at einsteintoolkit.org (rahime matur) Date: Tue, 07 Jul 2026 21:18:01 +0000 Subject: [ET Trac] #2959: Include BHNSTracker Message-ID: #2959: Include BHNSTracker Reporter: Beyhan Karaka? Status: new Milestone: Version: development version Type: enhancement Priority: major Component: EinsteinToolkit thorn Changes (by rahime matur): responsible: [] (was ) assignee: rahime matur (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2959/include-bhnstracker -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jul 8 11:03:53 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 08 Jul 2026 16:03:53 +0000 Subject: [ET Trac] #2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior Message-ID: #2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior Reporter: Jordan Nicoules Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: open (was resolved) Comment (by Roland Haas): Outputting (and computing) volume_form for test7patch is very slow (10min runtime) due to high number of MC particles used. Tolerance is also excessively tight for the "sum" reduction (resulting in the total volume) for an expected output value of 2e8 or so. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2912/inconsistent-computation-of-the-volume -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jul 8 11:04:34 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 08 Jul 2026 16:04:34 +0000 Subject: [ET Trac] #2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior Message-ID: #2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior Reporter: Jordan Nicoules Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Pull request is here: https://bitbucket.org/llamacode/llama/pull-requests/11 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2912/inconsistent-computation-of-the-volume -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jul 8 11:04:43 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 08 Jul 2026 16:04:43 +0000 Subject: [ET Trac] #2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior Message-ID: #2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior Reporter: Jordan Nicoules Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2912/inconsistent-computation-of-the-volume -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jul 8 11:04:57 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 08 Jul 2026 16:04:57 +0000 Subject: [ET Trac] #2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior Message-ID: #2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior Reporter: Jordan Nicoules Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Backport (kind of) to 2026_05 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2912/inconsistent-computation-of-the-volume -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jul 9 12:11:31 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Thu, 09 Jul 2026 17:11:31 +0000 Subject: [ET Trac] #2960: CarpetRegrid2: failure to regrid on relative radius change - possible underlying race condition Message-ID: #2960: CarpetRegrid2: failure to regrid on relative radius change - possible underlying race condition Reporter: Jordan Nicoules Status: new Milestone: Version: Type: bug Priority: major Component: Carpet ### Initial bug... `CarpetRegrid2` does not properly check for a change of radius of the refinement levels (when they are steered by a `Trigger` for instance). Looking a bit closer, it seems that the computed `drfac` in `CarpetRegrid2/src/regrid.cc` is `nan`, and thus `do_recompose` is not set to `true`. In particular, it means it *is* possible to change the radii if something else triggers a regridding (for instance, changing the number of active levels). ### ... revealed a deeper issue (race condition? Memory or compiler issue?) To figure out why `drfac` is `nan`, I added manual debugging information prints in the code. Depending on what information I ask, and in what order, I don't get consistent nor sensible results. *I haven't tried different compilers (I have gcc 11.4.0 locally), but this is happening even with a debug build (see attached make.config.defn file).* More precisely, printing `rad`, `oldrad`, `rad - oldrad`, their values are fine (done through `std::cout`). Printing (`CCTK_VINFO`) the numerator and denominator of `drfac` separately gives the right values for them, but the quotient `drfac` is wrong (it is `0`, and not `nan` anymore, even when it shouldn't). If I create new local variables ``` CCTK_REAL const num = sqrt(sum(ipow(rad - oldrad, 2))); CCTK_REAL const den = sqrt(sum(ipow(oldrad, 2))); ``` and print them, they both contain the same value. It looks like the values are as if it uses `rad=0` and whatever `oldrad` used to have before (which can be thus changed, depending on the order of the print lines). Finally, if I do print a lot of other info (in particular the intermediate computation steps), it seems it finally gets `drfac` right. I had a look at `CarpetLib`'s `vect.hh` and `defs.hh` too, but I can't seem to understand what is going wrong. ### Minimal example It would be helpful if someone could try to replicate the issue. To that effect, I'm attaching a minimal parfile (`regrid2_steer_radius.par`) adapted from `CarpetRegrid2/test/regrid2_granularity.par`, as well as a modified `regrid.cc` file with the extra `VINFO` that should allow you to quickly reproduce the situation. I'm attaching two output files generated from these simulations, one that gets `drfac` right, and one that gets it wrong. The difference is in the extra information I'm printing from `regrid.cc` (commented lines 840-849). ### Additional note I stumbled upon another possible desirable correction in the thorn, although it didn't seem to affect that matter so far. Hence, I also don't know how correct it actually is. I'm attaching the relevant `regrid.cc`, `initialise.cc` and `schedule.ccl` files in `fix__old_radius.zip`. attachment: CarpetRegrid2_bug.zip (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2960/attachments/CarpetRegrid2_bug.zip) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2960/carpetregrid2-failure-to-regrid-on -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jul 9 15:45:04 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 09 Jul 2026 20:45:04 +0000 Subject: [ET Trac] #1881: Unclear error message for parameter file error Message-ID: #1881: Unclear error message for parameter file error Reporter: Erik Schnetter Status: open Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): ping -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1881/unclear-error-message-for-parameter-file -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jul 9 15:45:22 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 09 Jul 2026 20:45:22 +0000 Subject: [ET Trac] #1523: Use Piraha to Parse all CCL files Message-ID: #1523: Use Piraha to Parse all CCL files Reporter: Steven R. Brandt Status: open Milestone: ET_2020_11 Version: development version Type: enhancement Priority: minor Component: Cactus Comment (by Roland Haas): ping -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1523/use-piraha-to-parse-all-ccl-files -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jul 9 15:45:34 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 09 Jul 2026 20:45:34 +0000 Subject: [ET Trac] #1520: src/piraha does not adhere to Cactus coding style Message-ID: #1520: src/piraha does not adhere to Cactus coding style Reporter: Roland Haas Status: open Milestone: Version: development version Type: bug Priority: minor Component: Other Comment (by Roland Haas): ping -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1520/src-piraha-does-not-adhere-to-cactus -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jul 9 15:48:56 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 09 Jul 2026 20:48:56 +0000 Subject: [ET Trac] #1077: evaluate steered value as formula in AEIThorns::Trigger Message-ID: #1077: evaluate steered value as formula in AEIThorns::Trigger Reporter: Roland Haas Status: open Milestone: Version: Type: enhancement Priority: minor Component: Other Comment (by Roland Haas): Here's a pull request: https://bitbucket.org/cactuscode/cactusutils/pull-requests/48 Though it exposes a bug in Piaraha's `CCTK_UtilExpressionEvaluate` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1077/evaluate-steered-value-as-formula-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jul 9 16:43:13 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 09 Jul 2026 21:43:13 +0000 Subject: [ET Trac] #2961: util_ExpressionEvaluate fails with custom evaluator Message-ID: #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_expressionevaluate-fails-with-custom -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jul 9 16:43:35 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 09 Jul 2026 21:43:35 +0000 Subject: [ET Trac] #2961: util_ExpressionEvaluate fails with custom evaluator Message-ID: #2961: util_ExpressionEvaluate fails with custom evaluator Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Cactus Changes (by Roland Haas): responsible: [] (was ) assignee: Steven R. Brandt (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2961/util_expressionevaluate-fails-with-custom -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jul 9 16:47:34 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 09 Jul 2026 21:47:34 +0000 Subject: [ET Trac] #2961: util_ExpressionEvaluate fails with custom evaluator Message-ID: #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_expressionevaluate-fails-with-custom -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jul 9 16:50:22 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 09 Jul 2026 21:50:22 +0000 Subject: [ET Trac] #2961: util_ExpressionEvaluate fails with custom evaluator Message-ID: #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_expressionevaluate-fails-with-custom -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Sat Jul 11 04:25:50 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Sat, 11 Jul 2026 09:25:50 +0000 Subject: [ET Trac] #2962: Split the ET Message-ID: #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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jul 15 06:04:06 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Wed, 15 Jul 2026 11:04:06 +0000 Subject: [ET Trac] #2963: ET website inconsistency on Kuibit version for ET_2026_05 Message-ID: #2963: ET website inconsistency on Kuibit version for ET_2026_05 Reporter: Jordan Nicoules Status: new Milestone: ET_2026_05 Version: Type: bug Priority: trivial Component: EinsteinToolkit website The [download page](https://einsteintoolkit.org/download.html) shows > ```pip install --user -U kuibit==1.5.0 # requires Python3 version 3.7 or greater``` while the [ET_2026_05 announcement](https://einsteintoolkit.org/about/releases/ET_2026_05_announcement.html) rightfully indicates > pip install --user -U kuibit==1.6.1 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2963/et-website-inconsistency-on-kuibit-version -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jul 15 09:03:31 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 15 Jul 2026 14:03:31 +0000 Subject: [ET Trac] #2963: ET website inconsistency on Kuibit version for ET_2026_05 Message-ID: #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-inconsistency-on-kuibit-version -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jul 15 09:04:58 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 15 Jul 2026 14:04:58 +0000 Subject: [ET Trac] #2963: ET website inconsistency on Kuibit version for ET_2026_05 Message-ID: #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 Comment (by Roland Haas): on the other hand, the downloads page says "# requires Python3 version 3.7 or greater" while the release description file on Zenodo (https://zenodo.org/records/21298233) says "assumes Python3 version 3.6.1 or greater". -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2963/et-website-inconsistency-on-kuibit-version -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jul 15 09:07:05 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 15 Jul 2026 14:07:05 +0000 Subject: [ET Trac] #2963: ET website inconsistency on Kuibit version for ET_2026_05 Message-ID: #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 Comment (by Roland Haas): The kuibit docs https://sbozzolo.github.io/kuibit/1.6.1/index.html say "The minimum version of Python required is 3.9." -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2963/et-website-inconsistency-on-kuibit-version -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jul 15 09:07:37 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 15 Jul 2026 14:07:37 +0000 Subject: [ET Trac] #2963: ET website inconsistency on Kuibit version for ET_2026_05 Message-ID: #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 Comment (by Roland Haas): I will remove the minimum Python version clause as this seems to not be consistently maintainable. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2963/et-website-inconsistency-on-kuibit-version -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jul 15 09:09:03 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 15 Jul 2026 14:09:03 +0000 Subject: [ET Trac] #2963: ET website inconsistency on Kuibit version for ET_2026_05 Message-ID: #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 Comment (by Roland Haas): Corrected in git hash [ef67aaa](https://bitbucket.org/einsteintoolkit/www/commits/ef67aaa555a8ac281ade573c40172cdeca95e87d) "download: bump kuibit to 1.6.1, remove Python version notice" of [www](https://bitbucket.org/einsteintoolkit/www) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2963/et-website-inconsistency-on-kuibit-version -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jul 15 09:09:45 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 15 Jul 2026 14:09:45 +0000 Subject: [ET Trac] #2963: ET website inconsistency on Kuibit version for ET_2026_05 Message-ID: #2963: ET website inconsistency on Kuibit version for ET_2026_05 Reporter: Jordan Nicoules Status: resolved Milestone: ET_2026_05 Version: Type: bug Priority: trivial Component: EinsteinToolkit website Changes (by Roland Haas): status: resolved (was open) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2963/et-website-inconsistency-on-kuibit-version -------------- next part -------------- An HTML attachment was scrubbed... URL: