Trac July 2026

trac@lists.einsteintoolkit.org

1 participants
59 discussions

#2959: Include BHNSTracker
by Beyhan Karakaş 07 Jul '26

07 Jul '26

#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-bhnstrack…

1 0

#2958: Regression in TwoPuncturesX
by Roland Haas 07 Jul '26

07 Jul '26

#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. ``` <NameOfThorn>:<SingleSpace><One line, short, active mode, present tense description> <OneEmptyLine> <stuff I (or git) does not care about> ``` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2958/regression-in-two…

1 0

#2958: Regression in TwoPuncturesX
by Roland Haas 07 Jul '26

07 Jul '26

#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-two…

1 0

#2958: Regression in TwoPuncturesX
by Roland Haas 07 Jul '26

07 Jul '26

#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-two…

1 0

#2958: Regression in TwoPuncturesX
by Roland Haas 07 Jul '26

07 Jul '26

#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-two…

1 0

#2958: Regression in TwoPuncturesX
by Steven R. Brandt 07 Jul '26

07 Jul '26

#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-two…

1 0

#2957: Discussion: Support multiple centering options for Cactus/CarpetX Grid Functions
by Maxwell Rizzo 02 Jul '26

02 Jul '26

#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-suppor…

1 0

#2956: CarpetX: Allow conditional expressions after SCHEDULE declarations in schedule.ccl
by Maxwell Rizzo 02 Jul '26

02 Jul '26

#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-con…

1 0

#2956: CarpetX: Allow conditional expressions after SCHEDULE declarations
by Maxwell Rizzo 02 Jul '26

02 Jul '26

#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-con…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac July 2026