Trac July 2026

trac@lists.einsteintoolkit.org

1 participants
59 discussions

#1077: evaluate steered value as formula in AEIThorns::Trigger
by Roland Haas 09 Jul '26

09 Jul '26

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

1 0

#1520: src/piraha does not adhere to Cactus coding style
by Roland Haas 09 Jul '26

09 Jul '26

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

1 0

#1523: Use Piraha to Parse all CCL files
by Roland Haas 09 Jul '26

09 Jul '26

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

1 0

#1881: Unclear error message for parameter file error
by Roland Haas 09 Jul '26

09 Jul '26

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

1 0

#2960: CarpetRegrid2: failure to regrid on relative radius change - possible underlying race condition
by Jordan Nicoules 09 Jul '26

09 Jul '26

#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/2…) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2960/carpetregrid2-fai…

1 0

#2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior
by Roland Haas 08 Jul '26

08 Jul '26

1 0

#2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior
by Roland Haas 08 Jul '26

08 Jul '26

1 0

#2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior
by Roland Haas 08 Jul '26

08 Jul '26

1 0

#2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior
by Roland Haas 08 Jul '26

08 Jul '26

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

1 0

#2959: Include BHNSTracker
by rahime matur 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 Changes (by rahime matur): responsible: [] (was ) assignee: rahime matur (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2959/include-bhnstrack…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac July 2026