From trac-noreply at einsteintoolkit.org Sun May 3 14:23:51 2026 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Sun, 03 May 2026 19:23:51 +0000 Subject: [ET Trac] #2918: Include BHaHAHA Message-ID: #2918: Include BHaHAHA Reporter: Beyhan Karaka? Status: open Milestone: ET_2026_05 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Zach Etienne): @{557058:f7fd5133-6eee-4385-a5e5-3e03342a0b24} : I have added the required code test to ET_BHaHAHA - it is a horizon find on a Kerr BH with spin parameter 0.6. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2918/include-bhahaha -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon May 4 14:10:10 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Mon, 04 May 2026 19:10:10 +0000 Subject: [ET Trac] #2938: use SWMR mode for HDF5 output in CarpetIOHDF5 Message-ID: #2938: use SWMR mode for HDF5 output in CarpetIOHDF5 Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: minor Component: Carpet Comment (by Roland Haas): This would fix the issue in #1283 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2938/use-swmr-mode-for-hdf5-output-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 5 00:07:09 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Tue, 05 May 2026 05:07:09 +0000 Subject: [ET Trac] #2932: Kuibit: detecting 0D and 1D files generated during Llama runs Message-ID: #2932: Kuibit: detecting 0D and 1D files generated during Llama runs Reporter: Jordan Nicoules Status: new Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Maxwell Rizzo): Changes look good to support patch 0 llama files, I left a comment on the kuibit pull request with some comments about non-zero patch output, but perhaps its best to start with just patch 0 support for now. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2932/kuibit-detecting-0d-and-1d-files-generated -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 5 12:22:05 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Tue, 05 May 2026 17:22:05 +0000 Subject: [ET Trac] #2932: Kuibit: detecting 0D and 1D files generated during Llama runs Message-ID: #2932: Kuibit: detecting 0D and 1D files generated during Llama runs Reporter: Jordan Nicoules Status: new Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Jordan Nicoules): Thank you for the review! I agree that the scope of that ticket/PR is conservatively limited to patch 0 support (specifically for the Thornburg04 system). Maybe proper llama support could deserve its own ticket, but as mentioned there, I'm not even sure how the other output is done and if it's fully reliable. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2932/kuibit-detecting-0d-and-1d-files-generated -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 5 13:12:48 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Tue, 05 May 2026 18:12:48 +0000 Subject: [ET Trac] #2929: GRHayLET/IllinoisGRMHD convert_IllinoisGRMHD_to_HydroBase schedule compatibility with VolumeIntegrals_* Message-ID: #2929: GRHayLET/IllinoisGRMHD convert_IllinoisGRMHD_to_HydroBase schedule compatibility with VolumeIntegrals_* Reporter: Maxwell Rizzo Status: new Milestone: ET_2026_05 Version: ET_2025_05 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Maxwell Rizzo): This fixes the issue, however there is a remaining question whether this is the best location to ensure VolumeIntegrals are scheduled correctly. Given that VolumeIntegrals are analysis thorns, they should probably schedule themselves properly, and not require the evolution thorn to correct things. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2929/grhaylet-illinoisgrmhd -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 5 13:15:09 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Tue, 05 May 2026 18:15:09 +0000 Subject: [ET Trac] #2932: Kuibit: detecting 0D and 1D files generated during Llama runs Message-ID: #2932: Kuibit: detecting 0D and 1D files generated during Llama runs Reporter: Jordan Nicoules Status: new Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Maxwell Rizzo): Thanks for clarifying, in that case the PR looks complete. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2932/kuibit-detecting-0d-and-1d-files-generated -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 5 13:59:30 2026 From: trac-noreply at einsteintoolkit.org (Leonardo Rosa Werneck) Date: Tue, 05 May 2026 18:59:30 +0000 Subject: [ET Trac] #2929: GRHayLET/IllinoisGRMHD convert_IllinoisGRMHD_to_HydroBase schedule compatibility with VolumeIntegrals_* Message-ID: #2929: GRHayLET/IllinoisGRMHD convert_IllinoisGRMHD_to_HydroBase schedule compatibility with VolumeIntegrals_* Reporter: Maxwell Rizzo Status: new Milestone: ET_2026_05 Version: ET_2025_05 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Leonardo Rosa Werneck): In this case, the issue is not with `VolumeIntegrals`, but with `IllinoisGRMHD`. `VolumeIntegrals` expects `HydroBase` variables, and when using `IllinoisGRMHD`, those variables are only set correctly if one explicitly calls the routine that converts from `IllinoisGRMHD`'s native variables to `HydroBase`. This is therefore not a diagnostic issue, but rather a consequence of `IllinoisGRMHD`'s choice of gridfunctions. For that reason, I think it is reasonable to expect `IllinoisGRMHD` to handle this conversion, rather than placing that responsibility on the diagnostic thorn. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2929/grhaylet-illinoisgrmhd -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 5 14:39:29 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 May 2026 19:39:29 +0000 Subject: [ET Trac] #2929: GRHayLET/IllinoisGRMHD convert_IllinoisGRMHD_to_HydroBase schedule compatibility with VolumeIntegrals_* Message-ID: #2929: GRHayLET/IllinoisGRMHD convert_IllinoisGRMHD_to_HydroBase schedule compatibility with VolumeIntegrals_* Reporter: Maxwell Rizzo Status: new Milestone: ET_2026_05 Version: ET_2025_05 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): :thumbsup: -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2929/grhaylet-illinoisgrmhd -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 5 22:12:00 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 May 2026 03:12:00 +0000 Subject: [ET Trac] #2930: Bug in QuasiLocalMeasures Message-ID: #2930: Bug in QuasiLocalMeasures Reporter: Marco Brito Status: new Milestone: ET_2026_05 Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Applied as git hash [9998ca49](https://bitbucket.org/einsteintoolkit/einsteinanalysis/commits/9998ca499bd6db490905d986d2fc228be58e1f62) "QuasiLocalMeasures: correct sign in ADM linear momentum" of [einsteinanalysis](https://bitbucket.org/einsteintoolkit/einsteinanalysis) Thank you! -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2930/bug-in-quasilocalmeasures -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 5 22:12:08 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 May 2026 03:12:08 +0000 Subject: [ET Trac] #2930: Bug in QuasiLocalMeasures Message-ID: #2930: Bug in QuasiLocalMeasures Reporter: Marco Brito Status: resolved Milestone: ET_2026_05 Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2930/bug-in-quasilocalmeasures -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 5 22:16:58 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 May 2026 03:16:58 +0000 Subject: [ET Trac] #2915: Include CapyrX: a GPU-accelerated multipatch infrastructure Message-ID: #2915: Include CapyrX: a GPU-accelerated multipatch infrastructure Reporter: Beyhan Karaka? Status: open Milestone: ET_2026_05 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Is there a pull request for manifest with thorns to include? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2915/include-capyrx-a-gpu-accelerated -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 5 22:56:40 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 May 2026 03:56:40 +0000 Subject: [ET Trac] #2921: Multipatch support in NewRadX Message-ID: #2921: Multipatch support in NewRadX Reporter: Lucas Timotheo Sanches Status: open Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): Applied as git hash [e89fe1d3](https://github.com/EinsteinToolkit/SpacetimeX/commits/e89fe1d3ee47adaf881f051c502fac61e4a4c0f9) "NewRadX: Added the ability to use CapyrX Multipatch" of [SpacetimeX](https://github.com/EinsteinToolkit/SpacetimeX) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2921/multipatch-support-in-newradx -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 5 22:56:46 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 May 2026 03:56:46 +0000 Subject: [ET Trac] #2921: Multipatch support in NewRadX Message-ID: #2921: Multipatch support in NewRadX Reporter: Lucas Timotheo Sanches Status: resolved Milestone: Version: Type: enhancement Priority: major Component: Changes (by Roland Haas): status: resolved (was open) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2921/multipatch-support-in-newradx -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 5 23:04:41 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 May 2026 04:04:41 +0000 Subject: [ET Trac] #2915: Include CapyrX: a GPU-accelerated multipatch infrastructure Message-ID: #2915: Include CapyrX: a GPU-accelerated multipatch infrastructure Reporter: Beyhan Karaka? Status: open Milestone: ET_2026_05 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Adding all present thorns (and applying the NewRadX patch for multipatch support) I get a test failure: ``` multipole (from CapyrX_WaveToy) ``` with error message: ``` Error: Implementation 'COORDBASE' not activated. This implementation is required by activated thorn(s): Multipole (implementing multipole) This implementation is provided by compiled thorn(s): CoordBase Add a thorn providing this implementation to the ActiveThorns parameter. Error: Implementation 'GRID' not activated. This implementation is required by activated thorn(s): Multipole (implementing multipole) This implementation is provided by compiled thorn(s): CartGrid3D Add a thorn providing this implementation to the ActiveThorns parameter. Activation failed - 2 errors in activation sequence WARNING level 0 from host haengie2.phas.ubc.ca process 0 in thorn Cactus, file /home/rhaas/postdoc/gr/cactus/ET_trunk/configs/sim/build/Cactus/main/SetParams.c:93: -> CCTKi_SetParameter: Error at line 1 in parameter file /home/rhaas/postdoc/gr/cactus/ET_trunk/arrangements/CapyrX/CapyrX_WaveToy/test/multipole.par while activating thorns ``` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2915/include-capyrx-a-gpu-accelerated -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 5 23:58:43 2026 From: trac-noreply at einsteintoolkit.org (Lucas Timotheo Sanches) Date: Wed, 06 May 2026 04:58:43 +0000 Subject: [ET Trac] #2915: Include CapyrX: a GPU-accelerated multipatch infrastructure Message-ID: #2915: Include CapyrX: a GPU-accelerated multipatch infrastructure Reporter: Beyhan Karaka? Status: open Milestone: ET_2026_05 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Lucas Timotheo Sanches): The [latest commit to master](https://github.com/lucass-carneiro/CapyrX/commit/7e59d2ee3c155d1320b30d7efb72d42362ede5a2) should fix this. The issue is that that specific test case relied on `Multipole` from `SpacetimeX`. The ETK master thorn list has "vanilla" `Multipole`, which does not jive with the rest of the infrastructure. Removing this test case should solve this For the manifest, I'm not sure what the procedure is. Should I just edit the master thornlist [here](https://bitbucket.org/einsteintoolkit/manifest/src/master/) and create a PR for this repo? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2915/include-capyrx-a-gpu-accelerated -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 7 09:38:48 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Thu, 07 May 2026 14:38:48 +0000 Subject: [ET Trac] #2929: GRHayLET/IllinoisGRMHD convert_IllinoisGRMHD_to_HydroBase schedule compatibility with VolumeIntegrals_* Message-ID: #2929: GRHayLET/IllinoisGRMHD convert_IllinoisGRMHD_to_HydroBase schedule compatibility with VolumeIntegrals_* Reporter: Maxwell Rizzo Status: resolved Milestone: ET_2026_05 Version: ET_2025_05 Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Maxwell Rizzo): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2929/grhaylet-illinoisgrmhd -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 7 10:02:17 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 May 2026 15:02:17 +0000 Subject: [ET Trac] #2936: CarpetX tsv output does not append files Message-ID: #2936: CarpetX tsv output does not append files Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: enhancement Priority: minor Component: CarpetX Comment (by Roland Haas): Pull request is here: https://github.com/EinsteinToolkit/CarpetX/pull/380 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2936/carpetx-tsv-output-does-not-append-files -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 7 15:02:09 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Thu, 07 May 2026 20:02:09 +0000 Subject: [ET Trac] #2937: TwoPuncturesX largely duplicates TwoPunctures Message-ID: #2937: TwoPuncturesX largely duplicates TwoPunctures Reporter: Zach Etienne Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Steven R. Brandt): This PR addresses the issue: https://bitbucket.org/einsteintoolkit/einsteininitialdata/pull-requests/22 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2937/twopuncturesx-largely-duplicates -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 7 15:02:29 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Thu, 07 May 2026 20:02:29 +0000 Subject: [ET Trac] #2733: TwoPunctures contains globally visible symbols not prefixed by thorn name Message-ID: #2733: TwoPunctures contains globally visible symbols not prefixed by thorn name Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: Comment (by Steven R. Brandt): This PR addresses the issue: https://bitbucket.org/einsteintoolkit/einsteininitialdata/pull-requests/22 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2733/twopunctures-contains-globally-visible -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 7 15:02:59 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Thu, 07 May 2026 20:02:59 +0000 Subject: [ET Trac] #2931: Claude AI edits to TwoPuncturesX Message-ID: #2931: Claude AI edits to TwoPuncturesX Reporter: Steven R. Brandt Status: new Milestone: ET_2026_05 Version: Type: bug Priority: major Component: Comment (by Steven R. Brandt): This PR addresses the issue: https://bitbucket.org/einsteintoolkit/einsteininitialdata/pull-requests/22 But through a new thorn, not SpacetimeX/TwoPuncturesX. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2931/claude-ai-edits-to-twopuncturesx -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri May 8 13:35:41 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Fri, 08 May 2026 18:35:41 +0000 Subject: [ET Trac] #2939: AHFinderDirect: range options for track_origin_source_x/y/z Message-ID: #2939: AHFinderDirect: range options for track_origin_source_x/y/z Reporter: Jordan Nicoules Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn In `AHFinderDirect` param.ccl there is (same for y, z): ``` string track_origin_source_x[101] "grid scalar containing the x component of the origin estimate" STEERABLE=recover { "" :: "don't use this feature" "[a-zA-Z_][a-zA-Z0-9_]*[:][:][a-zA-Z_][a-zA-Z0-9_]*(\[0-9+\])" :: "name of a grid scalar" } "" ``` While mimicking this and testing in a thorn of my own, I realized that `""` matches everything, so the second range is basically useless. **Is it what is meant by** `"don't use this feature"`? I think I rather understand it as "do not put nothing". If this is not the intention, first something should be done about the empty string and default value. What's more, the range is actually incorrect (see explanation from GPT-5.4 in Copilot below; I'll let you judge the validity of the explanation, you know that better than me). Possible fixes: 1. For the default: for example use a `"None"` value, with some catch in `AHFinderDirect_setup()` that checks the variable name and returns an error. With a quick test, an unknown/wrong variable name would trigger an error somewhere in the execution of `AHFinderDirect_find_horizons()` anyway. 2. For the actual range: * `^.*[:][:].*$` is used in `NSTracker` for example. * to keep a strict pattern, ``` "[a-zA-Z_][a-zA-Z0-9_]*[:][:][a-zA-Z_][a-zA-Z0-9_]*" :: "name of a grid scalar without index" "[a-zA-Z_][a-zA-Z0-9_]*[:][:][a-zA-Z_][a-zA-Z0-9_]*\[[0-9][0-9]*\]" :: "name of a grid scalar with index" ``` (GPT's recommendation to separate the two patterns for clarity and portability, instead of trying to match both at the same time). # Conclusion # I don't know if there are risks of breaking internal mechanics of AHFinderDirect by changing this. I would say that the current harm is mostly about false, or misleading, pretenses, as well as a bad template for other people like me. The possible harm of fixing is to break something else in AHFinderDirect by introducing a different default (this needs verification, but it doesn't look like it from a quick test). There may also be some backwards-compatibility issues if some people managed to use grid scalars that don't match the new pattern. ## GPT's explanation >Yes. The old regex from param.ccl is not actually matching PunctureTracker::pt_loc_y[0] as written. > >The key point is that Cactus string ranges use POSIX regexes, and the docs explicitly say extended regex support is not portable. In practice, you should write these as portable POSIX-BRE-style patterns, not PCRE-ish ones. > >Your old pattern is: > > `[a-zA-Z_][a-zA-Z0-9_]*[:][:][a-zA-Z_][a-zA-Z0-9_]*(\[0-9+\])` > >Why it fails: > >`\[` and `\]` correctly mean literal [ and ]. >But 0-9+ is outside a character class, so it means the literal characters 0, -, 9, +, not ?one or more digits?. >The surrounding ( ) are also suspicious, because in POSIX basic regex they are literals unless escaped as`\(` and `\)`. So they are not doing grouping in the portable interpretation. So that pattern is effectively trying to match something like: > > `thorn::var([0-9+])` > >or at best a very literal bracket payload, not `thorn::var[0]`. > >That is why `""` made it ?work?: per the Cactus docs, the empty regex matches anything. So before, validation was effectively bypassed. > >What you want, portably, is something like: > > `[a-zA-Z_][a-zA-Z0-9_]*[:][:][a-zA-Z_][a-zA-Z0-9_]*\[[0-9][0-9]*\]` > >That matches: > > * implementation name > * :: > * variable name > * [ digits ] > >including `PunctureTracker::pt_loc_y[0]`. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2939/ahfinderdirect-range-options-for -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 12 18:04:31 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 12 May 2026 23:04:31 +0000 Subject: [ET Trac] #2940: CCE_Export: allow for changing array_size Message-ID: #2940: CCE_Export: allow for changing array_size Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: remove static variable whose size depends on a function argument -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2940/cce_export-allow-for-changing-array_size -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 12 18:04:43 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 12 May 2026 23:04:43 +0000 Subject: [ET Trac] #2940: CCE_Export: allow for changing array_size Message-ID: #2940: CCE_Export: allow for changing array_size Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: Comment (by Roland Haas): Pull request is here: https://github.com/deborahferguson/CCE_Export/pull/16 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2940/cce_export-allow-for-changing-array_size -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 12 18:20:32 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Tue, 12 May 2026 23:20:32 +0000 Subject: [ET Trac] #2941: CCE_Export uses `setiosflags` unqualified without an explicit using-declaration Message-ID: #2941: CCE_Export uses `setiosflags` unqualified without an explicit using-declaration Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn In line 169-170 of `h5_export.cc` ```cpp basename << base_file_name << "R" << setiosflags(ios::fixed) << setprecision(2) << rad << "." << extension; ``` and the only using statement on line 13 ```cpp using std::string, std::ostringstream, std::map, std::ios, std::setprecision; ``` `std::setiosflags` is missing from the using-declaration if will be used unqualified. Corresponding [PR](https://github.com/deborahferguson/CCE_Export/pull/17) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2941/cce_export-uses-setiosflags-unqualified -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 12 18:21:04 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Tue, 12 May 2026 23:21:04 +0000 Subject: [ET Trac] #2941: CCE_Export uses `setiosflags` unqualified without an explicit using-declaration Message-ID: #2941: CCE_Export uses `setiosflags` unqualified without an explicit using-declaration Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Changes (by Maxwell Rizzo): In line 169-170 of `h5_export.cc` ```cpp basename << base_file_name << "R" << setiosflags(ios::fixed) << setprecision(2) << rad << "." << extension; ``` and the only using statement on line 13 ```cpp using std::string, std::ostringstream, std::map, std::ios, std::setprecision; ``` `std::setiosflags` is missing from the using-declaration in order to be used unqualified. Corresponding [PR](https://github.com/deborahferguson/CCE_Export/pull/17) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2941/cce_export-uses-setiosflags-unqualified -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 12 18:30:04 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 12 May 2026 23:30:04 +0000 Subject: [ET Trac] #2941: CCE_Export uses `setiosflags` unqualified without an explicit using-declaration Message-ID: #2941: CCE_Export uses `setiosflags` unqualified without an explicit using-declaration Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): Please review -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2941/cce_export-uses-setiosflags-unqualified -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 12 18:30:24 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 12 May 2026 23:30:24 +0000 Subject: [ET Trac] #2940: CCE_Export: allow for changing array_size Message-ID: #2940: CCE_Export: allow for changing array_size Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: Comment (by Roland Haas): Please review -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2940/cce_export-allow-for-changing-array_size -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 14 10:40:21 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Thu, 14 May 2026 15:40:21 +0000 Subject: [ET Trac] #2939: AHFinderDirect: range options for track_origin_source_x/y/z Message-ID: #2939: AHFinderDirect: range options for track_origin_source_x/y/z Reporter: Jordan Nicoules Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Steven R. Brandt): https://bitbucket.org/einsteintoolkit/einsteinanalysis/pull-requests/26 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2939/ahfinderdirect-range-options-for -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 14 11:02:53 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Thu, 14 May 2026 16:02:53 +0000 Subject: [ET Trac] #2939: AHFinderDirect: range options for track_origin_source_x/y/z Message-ID: #2939: AHFinderDirect: range options for track_origin_source_x/y/z Reporter: Jordan Nicoules Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Jordan Nicoules): The PR doesn't change the default value being `""` and matching anything, is that intended? Maybe I wasn't clear, what I meant was ``` string track_origin_source_x[101] "grid scalar containing the x component of the origin estimate" STEERABLE=recover { "None" :: "None" "[a-zA-Z_][a-zA-Z0-9_]*[:][:][a-zA-Z_][a-zA-Z0-9_]*(\[0-9+\])" :: "name of a grid scalar" } "None" ``` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2939/ahfinderdirect-range-options-for -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 14 11:16:18 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Thu, 14 May 2026 16:16:18 +0000 Subject: [ET Trac] #6: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior Message-ID: #6: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior Reporter: Jordan Nicoules Status: submitted Milestone: Version: Type: bug Priority: major Component: Comment (by Steven R. Brandt): https://bitbucket.org/llamacode/llama/pull-requests/10 -- Ticket URL: https://bitbucket.org/llamacode/llama/issues/6/inconsistent-computation-of-the-volume -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 14 11:42:37 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Thu, 14 May 2026 16:42:37 +0000 Subject: [ET Trac] #7: Add test of the volume form in Coordinates Message-ID: #7: Add test of the volume form in Coordinates Reporter: Jordan Nicoules Status: submitted Milestone: Version: Type: enhancement Priority: major Component: I'm adding here suggestions of tests, to add to `Coordinates`, regarding the modification to the volume form https://bitbucket.org/llamacode/llama/pull-requests/10. I basically added the sum reduction of the volume form to the existing test, and made a second similar one for `Thornburg04nc`. There might be the need for a tolerance for the results. attachment: test.zip (https://api.bitbucket.org/2.0/repositories/llamacode/llama/issues/7/attachments/test.zip) -- Ticket URL: https://bitbucket.org/llamacode/llama/issues/7/add-test-of-the-volume-form-in-coordinates -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 14 11:44:39 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Thu, 14 May 2026 16:44:39 +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 Jordan Nicoules): Submitted another Llama ticket to add/update tests in `Coordinates` : https://bitbucket.org/llamacode/llama/issues/7/add-test-of-the-volume-form-in-coordinates -- 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 May 14 12:44:34 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 14 May 2026 17:44:34 +0000 Subject: [ET Trac] #2942: Formaline: preserve symlinks in git source snapshots Message-ID: #2942: Formaline: preserve symlinks in git source snapshots Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: @{557058:8bc23f2a-45c0-477d-8ac4-a5a16c734278} reports: Formaline currently warns and skips symbolic links when updating its git source snapshot because update-git-repo.pl only accepts regular files. This causes valid symlinks, including symlinks to directories, to be omitted from the stored source tree. Allow symbolic links through the existing file-type check. When the temporary hard-link staging tree can represent the symlink, the existing bulk git add path continues to handle it. If hard-link staging fails, add a symlink-specific fallback that writes the link target as a Git blob and stages it with mode 120000, which is Git's native representation for symbolic links. Broken symlinks are still refused with a warning and removed from the desired tracked set, matching the existing behavior for missing files while making the broken-link case explicit. The fallback path also avoids shell-quoting the Cactus filename directly by passing paths and link targets through environment variables before feeding them to `git hash-object / git update-index`. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2942/formaline-preserve-symlinks-in-git-source -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 14 12:44:43 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 14 May 2026 17:44:43 +0000 Subject: [ET Trac] #2942: Formaline: preserve symlinks in git source snapshots Message-ID: #2942: Formaline: preserve symlinks in git source snapshots Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Pull request is here: https://bitbucket.org/cactuscode/cactusutils/pull-requests/46 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2942/formaline-preserve-symlinks-in-git-source -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 14 12:45:02 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 14 May 2026 17:45:02 +0000 Subject: [ET Trac] #2942: Formaline: preserve symlinks in git source snapshots Message-ID: #2942: Formaline: preserve symlinks in git source snapshots Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2942/formaline-preserve-symlinks-in-git-source -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 14 12:47:12 2026 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Thu, 14 May 2026 17:47:12 +0000 Subject: [ET Trac] #2943: Formaline rejects valid symlinks in GRHayLib Message-ID: #2943: Formaline rejects valid symlinks in GRHayLib Reporter: Zach Etienne Status: new Milestone: Version: Type: bug Priority: major Component: Formaline emits warnings while creating/updating the configuration git repository when a thorn contains symbolic links, for example in `GRHayL/GRHayLib/src`: ```text Formaline: Creating configuration git repository... Formaline: Updating files in git repository... WARNING: Refusing to add "arrangements/GRHayL/GRHayLib/src/Neutrinos" as it is not a regular file at Cactus/configs/etbhahaha/scratch/Formaline/bin/update-git-repo.pl line 202, line 6246. ... fatal: bad revision 'HEAD' Formaline: Committing source tree to git repository... ``` The full set of warnings occurs for the symlinked `GRHayLib/src` entries such as `Neutrinos`, `Induction`, `Flux_Source`, `Reconstruction`, `Atmosphere`, `EOS`, `include`, `GRHayL_Core`, and `Con2Prim`. **Root Cause** `Formaline/src/util/update-git-repo.pl` currently accepts only regular files before adding paths to the Formaline git repository: ```perl if (! -e $file) { push @to_remove, $file; next; } elsif (! -f $file) { warn "WARNING: Refusing to add \"$file\" as it is not a regular file"; next; } ``` This rejects valid symbolic links, including symlinks to directories. The listed `GRHayLib/src/*` entries are symlinks, not broken paths, so they should be represented in the Formaline git snapshot instead of being skipped. Git represents symlinks as mode `120000` blobs containing the link target. Formaline?s fallback path already uses `git update-index --cacheinfo` when hard-link staging fails, so symlinks need corresponding handling there rather than being rejected by the regular-file check. **Fix Available** The issue is fixed by this pull request, which is ready for review: https://bitbucket.org/cactuscode/cactusutils/pull-requests/46 **Expected Behavior** Formaline should preserve valid symbolic links in its git source snapshot. Broken symlinks should still produce a warning. **Suggested Resolution** Review and merge: https://bitbucket.org/cactuscode/cactusutils/pull-requests/46 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2943/formaline-rejects-valid-symlinks-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 14 12:48:56 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 14 May 2026 17:48:56 +0000 Subject: [ET Trac] #2942: Formaline: preserve symlinks in git source snapshots Message-ID: #2942: Formaline: preserve symlinks in git source snapshots Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Looks good to me. But then I was involved in developing this. Please apply. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2942/formaline-preserve-symlinks-in-git-source -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 14 12:50:06 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 14 May 2026 17:50:06 +0000 Subject: [ET Trac] #2942: Formaline: preserve symlinks in git source snapshots Message-ID: #2942: Formaline: preserve symlinks in git source snapshots Reporter: Roland Haas Status: duplicate Milestone: Version: Type: bug Priority: major Component: Changes (by Roland Haas): status: duplicate (was new) Comment (by Roland Haas): Duplicate of #2943. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2942/formaline-preserve-symlinks-in-git-source -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 14 12:50:19 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 14 May 2026 17:50:19 +0000 Subject: [ET Trac] #2943: Formaline rejects valid symlinks in GRHayLib Message-ID: #2943: Formaline rejects valid symlinks in GRHayLib Reporter: Zach Etienne Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2943/formaline-rejects-valid-symlinks-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 14 12:50:28 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 14 May 2026 17:50:28 +0000 Subject: [ET Trac] #2943: Formaline rejects valid symlinks in GRHayLib Message-ID: #2943: Formaline rejects valid symlinks in GRHayLib Reporter: Zach Etienne Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Looks good to me. But then I was involved in developing this. Please apply. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2943/formaline-rejects-valid-symlinks-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri May 15 22:12:26 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Sat, 16 May 2026 03:12:26 +0000 Subject: [ET Trac] #2931: Claude AI edits to TwoPuncturesX Message-ID: #2931: Claude AI edits to TwoPuncturesX Reporter: Steven R. Brandt Status: resolved Milestone: ET_2026_05 Version: Type: bug Priority: major Component: Changes (by Steven R. Brandt): status: resolved (was new) Comment (by Steven R. Brandt): No longer relevant. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2931/claude-ai-edits-to-twopuncturesx -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 14 13:34:53 2026 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Thu, 14 May 2026 18:34:53 +0000 Subject: [ET Trac] #2944: CCE_Export Issues Ticket Message-ID: #2944: CCE_Export Issues Ticket Reporter: Zach Etienne Status: new Milestone: Version: Type: bug Priority: major Component: @{5a73cd832d61371e861f3270} The below review of CCE_Export was the product of a number of LLM worker agents, including Qwen3.6-27b, Claude Sonnet-4.7-XHigh, as well as a supervisor GPT-5.5-XHigh agent. ``` * Issue 1 - Severity high - Description of the error The interpolation helpers ignore too many error/status paths. The ADMBase variable names used here are fixed by the thorn and inherited from ADMBase, so "bad user-supplied variable name" is not the main risk. However, CCTK_VarIndex, CCTK_InterpHandle, Util_TableCreate, the table setters, CCTK_CoordSystemHandle, CCTK_InterpGridArrays, and Util_TableDestroy can all report failure, and the output buffers are consumed immediately afterward. This is especially important for out-of-domain extraction radii and missing or misconfigured interpolation support. - Filename + line number(s) repos/CCE_Export/src/interpolate.cc:11, 33-60, 68, 85-112 repos/einsteinanalysis/Multipole/src/interpolate.cc:13-19, 69-79 repos/einsteinanalysis/ET_BHaHAHA/src/BHaHAHA_interpolate_metric_data.c:142-151 - Original code snippet CCTK_INT variable_index = CCTK_VarIndex(name.c_str()); const int operator_handle = CCTK_InterpHandle("Hermite polynomial interpolation"); int param_table_handle = Util_TableCreate(UTIL_TABLE_FLAGS_DEFAULT); Util_TableSetFromString(param_table_handle, "order=3 ..."); Util_TableSetIntArray(param_table_handle, 4, operand_indices, "operand_indices"); Util_TableSetIntArray(param_table_handle, 4, operation_codes, "operation_codes"); const int coord_system_handle = CCTK_CoordSystemHandle("cart3d"); CCTK_InterpGridArrays(cctkGH, num_dims, operator_handle, param_table_handle, coord_system_handle, CCTK_MyProc(cctkGH) == 0 ? array_size : 0, CCTK_VARIABLE_REAL, interp_coords, num_input_arrays, input_array_indices, num_output_arrays, output_array_types, output_arrays); - Suggested patch Add abort-level checks before any interpolated data are consumed: CCTK_INT variable_index = CCTK_VarIndex(name.c_str()); if (variable_index < 0) CCTK_VWarn(CCTK_WARN_ABORT, __LINE__, __FILE__, CCTK_THORNSTRING, "Could not find variable '%s'", name.c_str()); const int operator_handle = CCTK_InterpHandle("Hermite polynomial interpolation"); if (operator_handle < 0) CCTK_WARN(CCTK_WARN_ABORT, "Could not find Hermite interpolator"); int param_table_handle = Util_TableCreate(UTIL_TABLE_FLAGS_DEFAULT); if (param_table_handle < 0) CCTK_WARN(CCTK_WARN_ABORT, "Could not create interpolation table"); int ierr = Util_TableSetFromString(param_table_handle, "order=3 ..."); if (ierr < 0) CCTK_WARN(CCTK_WARN_ABORT, "Could not populate interpolation table"); ierr = Util_TableSetIntArray(param_table_handle, 4, operand_indices, "operand_indices"); if (ierr < 0) CCTK_WARN(CCTK_WARN_ABORT, "Could not set operand_indices"); ierr = Util_TableSetIntArray(param_table_handle, 4, operation_codes, "operation_codes"); if (ierr < 0) CCTK_WARN(CCTK_WARN_ABORT, "Could not set operation_codes"); const int coord_system_handle = CCTK_CoordSystemHandle("cart3d"); if (coord_system_handle < 0) CCTK_WARN(CCTK_WARN_ABORT, "Could not find cart3d coordinate system"); ierr = CCTK_InterpGridArrays(...); if (ierr < 0) CCTK_VWarn(CCTK_WARN_ABORT, __LINE__, __FILE__, CCTK_THORNSTRING, "Interpolation failed for '%s' with status %d", name.c_str(), ierr); ierr = Util_TableDestroy(param_table_handle); if (ierr < 0) CCTK_WARN(CCTK_WARN_ABORT, "Could not destroy interpolation table"); * Issue 2 - Severity medium - Description of the error The interpolation call must remain collective, but the spherical-harmonic work after interpolation is only useful on rank 0. Cactus schedule option GLOBAL means once per grid hierarchy/component scheduling level, not only on MPI rank 0. The existing rank-0 guard around output confirms that all ranks enter the routine. Nonzero ranks request zero interpolation points and then perform decomposition work whose results are discarded. - Filename + line number(s) repos/CCE_Export/schedule.ccl:3-8 repos/CCE_Export/src/cce_export.cc:135-183 repos/flesh/doc/UsersGuide/Appendices.tex:1034-1085 - Original code snippet Extract_Metric_Shift_Lapse_On_Sphere(...); Compute_Ylms(th, ph, re_ylms, im_ylms, lmax, array_size); for (int i = 0; i < 3; i++) { for (int j = i; j < 3; j++) { Decompose_Spherical_Harmonics(...); } } ... if (CCTK_MyProc(cctkGH) == 0) { Output_Decomposed_Metric_Data(...); } - Suggested patch Keep the collective interpolation outside the rank guard, then perform mode decomposition and output only on rank 0: Extract_Metric_Shift_Lapse_On_Sphere(...); if (CCTK_MyProc(cctkGH) == 0) { Compute_Ylms(th, ph, re_ylms, im_ylms, lmax, array_size); for (int i = 0; i < 3; i++) { for (int j = i; j < 3; j++) { Decompose_Spherical_Harmonics(...); } } for (int i = 0; i < 3; i++) { Decompose_Spherical_Harmonics(... beta ...); Decompose_Spherical_Harmonics(... dr_beta ...); Decompose_Spherical_Harmonics(... dt_beta ...); } Decompose_Spherical_Harmonics(... alpha ...); Decompose_Spherical_Harmonics(... dr_alpha ...); Decompose_Spherical_Harmonics(... dt_alpha ...); Output_Decomposed_Metric_Data(...); } * Issue 3 - Severity high - Description of the error CCTK_REAL precision is configurable in Cactus/ET. The writer stores data in vector but tells HDF5 that the memory buffer is H5T_NATIVE_DOUBLE. This is only safe for CCTK_REAL_PRECISION_8. CarpetIOHDF5 maps CCTK_REAL to H5T_NATIVE_FLOAT, H5T_NATIVE_DOUBLE, or H5T_NATIVE_LDOUBLE according to the configured precision, which is the relevant ET convention. The utility reader also needs a deliberate memory datatype if the on-disk datatype changes. - Filename + line number(s) repos/CCE_Export/src/h5_export.cc:65, 132 repos/CCE_Export/src/util/cce_export_hdf5_to_ascii.c:50, 76-77 repos/Carpet/CarpetIOHDF5/src/CarpetIOHDF5.hh:22-27 repos/Carpet/CarpetIOHDF5/src/CarpetIOHDF5.cc:249-302 - Original code snippet dataset = H5Dcreate(file, datasetname.c_str(), H5T_NATIVE_DOUBLE, dataspace, cparms); ... HDF5_ERROR(H5Dwrite(dataset, H5T_NATIVE_DOUBLE, memdataspace, filespace, H5P_DEFAULT, data)); - Suggested patch Use a CCTK_REAL-aware memory datatype for writes. If SpECTRE compatibility requires double-precision datasets on disk, keep the dataset datatype double and let HDF5 convert from the correct memory datatype: #if defined(CCTK_REAL_PRECISION_16) #define CCE_HDF5_REAL_MEMORY H5T_NATIVE_LDOUBLE #elif defined(CCTK_REAL_PRECISION_8) #define CCE_HDF5_REAL_MEMORY H5T_NATIVE_DOUBLE #elif defined(CCTK_REAL_PRECISION_4) #define CCE_HDF5_REAL_MEMORY H5T_NATIVE_FLOAT #else #error "Unsupported CCTK_REAL precision" #endif const hid_t file_real_type = H5T_NATIVE_DOUBLE; HDF5_ERROR(dataset = H5Dcreate(file, datasetname.c_str(), file_real_type, dataspace, cparms)); HDF5_ERROR(H5Dwrite(dataset, CCE_HDF5_REAL_MEMORY, memdataspace, filespace, H5P_DEFAULT, data)); In the utility reader, allocate the requested output type deliberately and pass the matching HDF5 memory datatype, for example: double *data = NULL; status = H5Dread(dataset_id, H5T_NATIVE_DOUBLE, H5S_ALL, H5S_ALL, H5P_DEFAULT, data); * Issue 4 - Severity medium - Description of the error This thorn has C++14/C++17 dependencies without an explicit local contract. Full ET context does not make this disappear: Cactus documentation still says C++11 is required, and several simfactory optionlists still select C++11 or C++14, even though newer generic and machine optionlists commonly use C++17. The code uses std::make_unique, comma-separated using-declarations, and std::filesystem. The filesystem feature-test check is also unreliable because it tests __cpp_lib_filesystem before including a header that would define it. - Filename + line number(s) repos/CCE_Export/src/h5_export.cc:3-8, 13 repos/CCE_Export/src/cce_export.cc:12 repos/CCE_Export/src/cce_export.hh:15 repos/CCE_Export/src/spherical_harmonic_decomposition.cc:5, 81-82 repos/flesh/doc/UsersGuide/Notes.tex:47-49 repos/simfactory2/mdb/optionlists/generic.cfg:30-32 repos/simfactory2/mdb/optionlists/debian-cuda.cfg:44 repos/simfactory2/mdb/optionlists/wheeler.cfg:19 - Original code snippet #if defined __cpp_lib_filesystem && __cpp_lib_filesystem < 201703L #include namespace fs = std::experimental::filesystem; #else #include namespace fs = std::filesystem; #endif using std::string, std::ostringstream, std::map, std::ios, std::setprecision; static auto fr = std::make_unique(array_size); - Suggested patch Either make C++17 an explicit requirement, or remove the C++17-only code. A minimal explicit-contract patch is: #if __cplusplus < 201703L #error "CCE_Export requires C++17 or later" #endif #include namespace fs = std::filesystem; using std::string; using std::ostringstream; using std::map; using std::ios; using std::setprecision; Also document the C++17 requirement in README/ThornGuide and ensure the build configuration used for this thorn selects a C++17-capable compiler mode. If C++11 compatibility is desired instead, replace std::filesystem with Cactus/local path handling and replace comma-separated using-declarations with individual declarations. * Issue 5 - Severity high - Description of the error For gravitational-wave extraction/CCE, r = 0 is not a valid extraction radius or worldtube. The default configuration activates one radius at radius[0] = 0.0, so a user who merely activates the thorn with defaults is requesting mathematically invalid data. The implementation then compounds this by computing radial derivatives through x^i/r partial_i, which divides by radius[rad_index]. Unlike Multipole, CCE_Export explicitly exports radial derivatives of worldtube data, so zero radius must be rejected, not treated as an allowed lower endpoint. - Filename + line number(s) repos/CCE_Export/param.ccl:9-17 repos/CCE_Export/src/interpolate.cc:173-179, 197-202, 215-218 - Original code snippet CCTK_INT nradii "How many radii to export the data on" STEERABLE=recover { 0:100 :: "number of radii" } 1 CCTK_REAL radius[101] "Radii to export the metric data on" STEERABLE=recover { 0.0:* :: "Extraction radius" } 0.0 dr_g.at(i).at(j).at(array_index) = (xs.at(array_index) / radius[rad_index]) * dx_g.at(i).at(j).at(array_index) + (ys.at(array_index) / radius[rad_index]) * dy_g.at(i).at(j).at(array_index) + (zs.at(array_index) / radius[rad_index]) * dz_g.at(i).at(j).at(array_index); - Suggested patch Make the default inactive or positive, and reject every active non-positive extraction radius before interpolation: CCTK_INT nradii "How many radii to export the data on" STEERABLE=recover { 0:100 :: "number of radii" } 0 CCTK_REAL radius[101] "Radii to export the metric data on" STEERABLE=recover { (0.0:* :: "Positive extraction radius" } 1.0 for (int ir = 0; ir < nradii; ++ir) { if (radius[ir] <= 0.0) { CCTK_VWarn(CCTK_WARN_ABORT, __LINE__, __FILE__, CCTK_THORNSTRING, "CCE_Export::radius[%d] = %.17g is invalid: CCE/worldtube " "extraction radii must be strictly positive", ir, static_cast(radius[ir])); } } * Issue 6 - Severity medium - Description of the error Output is documented and implemented as one file per extraction radius, but the filename uses a float argument and fixed two-decimal formatting. Distinct CCTK_REAL radii can therefore collide in the same output filename. The parameter documentation mentions two decimal places, but that does not protect the data from accidental collisions and is inconsistent with "a separate h5 file for each desired extraction radius." - Filename + line number(s) repos/CCE_Export/src/h5_export.hh:25-39 repos/CCE_Export/src/h5_export.cc:154, 168-171 repos/CCE_Export/src/cce_export.cc:178-182 repos/CCE_Export/param.ccl:25-29 repos/CCE_Export/doc/documentation.tex:49-50 - Original code snippet void Output_Decomposed_Metric_Data(..., float rad, int lmax) { ... basename << base_file_name << "R" << setiosflags(ios::fixed) << setprecision(2) << rad << "." << extension; string output_name = (fs::path(my_out_dir) / basename.str()).string(); } - Suggested patch Preserve CCTK_REAL precision through the output path, increase filename precision, and validate that active radii produce unique names: void Output_Decomposed_Metric_Data(..., CCTK_REAL rad, int lmax) { ... basename << base_file_name << "R" << setiosflags(ios::fixed) << setprecision(12) << static_cast(rad) << "." << extension; string output_name = (fs::path(my_out_dir) / basename.str()).string(); } std::set output_names; for (int ir = 0; ir < nradii; ++ir) { std::ostringstream name; name << base_file_name << "R" << std::fixed << std::setprecision(12) << static_cast(radius[ir]) << "." << extension; if (!output_names.insert(name.str()).second) { CCTK_VWarn(CCTK_WARN_ABORT, __LINE__, __FILE__, CCTK_THORNSTRING, "Multiple CCE_Export radii map to output file '%s'", name.str().c_str()); } } * Issue 7 - Severity medium - Description of the error The documentation is wrong in two places. The metric components are interpolated directly from ADMBase; the code uses the ADM extrinsic-curvature relation to compute partial_t gamma_ij, not to compute gamma_ij itself. The spherical-harmonic coefficient integral implemented here is over dOmega using sin(theta) dtheta dphi and does not multiply by r^2. - Filename + line number(s) repos/CCE_Export/doc/documentation.tex:76-84, 93-100 repos/CCE_Export/src/interpolate.cc:166-170, 221-311 repos/CCE_Export/src/spherical_harmonic_decomposition.cc:84-96 - Original code snippet The metric is computed from the extrinsic curvature, lapse, and shift as: \begin{equation} K_{ij} = \frac{1}{2 \alpha} \left ( -\partial_0 \gamma_{ij} + \beta^k \partial_k \gamma_{ij} + \gamma_{ki} \partial_j \beta^k + \gamma_{kj} \partial_i \beta^k \right ) \, . \end{equation} C^{lm}(t, r) = \int {}_0 Y_{lm}^* u(t, r, \theta, \varphi) r^2 d \Omega - Suggested patch Update the ThornGuide to describe the implemented mathematics: The metric components are interpolated directly from ADMBase. The metric time derivative is computed by inverting the ADM definition of extrinsic curvature: \begin{equation} \partial_t \gamma_{ij} = -2\alpha K_{ij} + \beta^k \partial_k \gamma_{ij} + \gamma_{ki} \partial_j \beta^k + \gamma_{kj} \partial_i \beta^k . \end{equation} The spherical-harmonic coefficients are \begin{eqnarray} C^{lm}(t, r) = \int {}_0 Y_{lm}^* u(t, r, \theta, \varphi) d\Omega . \end{eqnarray} * Issue 8 - Severity medium - Description o -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2944/cce_export-issues-ticket -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri May 15 22:12:52 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Sat, 16 May 2026 03:12:52 +0000 Subject: [ET Trac] #2937: TwoPuncturesX largely duplicates TwoPunctures Message-ID: #2937: TwoPuncturesX largely duplicates TwoPunctures Reporter: Zach Etienne Status: resolved Milestone: Version: Type: bug Priority: major Component: Changes (by Steven R. Brandt): status: resolved (was new) Comment (by Steven R. Brandt): Fixed. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2937/twopuncturesx-largely-duplicates -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri May 15 22:11:48 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Sat, 16 May 2026 03:11:48 +0000 Subject: [ET Trac] #2733: TwoPunctures contains globally visible symbols not prefixed by thorn name Message-ID: #2733: TwoPunctures contains globally visible symbols not prefixed by thorn name Reporter: Roland Haas Status: resolved Milestone: Version: Type: bug Priority: minor Component: Changes (by Steven R. Brandt): status: resolved (was new) Comment (by Steven R. Brandt): Fixed. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2733/twopunctures-contains-globally-visible -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 14 13:36:01 2026 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Thu, 14 May 2026 18:36:01 +0000 Subject: [ET Trac] #2944: CCE_Export Issues Ticket Message-ID: #2944: CCE_Export Issues Ticket Reporter: Zach Etienne Status: new Milestone: Version: Type: bug Priority: major Component: Changes (by Zach Etienne): @{5a73cd832d61371e861f3270} The below review of CCE_Export was the product of a number of LLM worker agents, including Qwen3.6-27b, Claude Sonnet-4.7-XHigh, as well as a supervisor GPT-5.5-XHigh agent. ``` * Issue 1 - Severity high - Description of the error The interpolation helpers ignore too many error/status paths. The ADMBase variable names used here are fixed by the thorn and inherited from ADMBase, so "bad user-supplied variable name" is not the main risk. However, CCTK_VarIndex, CCTK_InterpHandle, Util_TableCreate, the table setters, CCTK_CoordSystemHandle, CCTK_InterpGridArrays, and Util_TableDestroy can all report failure, and the output buffers are consumed immediately afterward. This is especially important for out-of-domain extraction radii and missing or misconfigured interpolation support. - Filename + line number(s) repos/CCE_Export/src/interpolate.cc:11, 33-60, 68, 85-112 repos/einsteinanalysis/Multipole/src/interpolate.cc:13-19, 69-79 repos/einsteinanalysis/ET_BHaHAHA/src/BHaHAHA_interpolate_metric_data.c:142-151 - Original code snippet CCTK_INT variable_index = CCTK_VarIndex(name.c_str()); const int operator_handle = CCTK_InterpHandle("Hermite polynomial interpolation"); int param_table_handle = Util_TableCreate(UTIL_TABLE_FLAGS_DEFAULT); Util_TableSetFromString(param_table_handle, "order=3 ..."); Util_TableSetIntArray(param_table_handle, 4, operand_indices, "operand_indices"); Util_TableSetIntArray(param_table_handle, 4, operation_codes, "operation_codes"); const int coord_system_handle = CCTK_CoordSystemHandle("cart3d"); CCTK_InterpGridArrays(cctkGH, num_dims, operator_handle, param_table_handle, coord_system_handle, CCTK_MyProc(cctkGH) == 0 ? array_size : 0, CCTK_VARIABLE_REAL, interp_coords, num_input_arrays, input_array_indices, num_output_arrays, output_array_types, output_arrays); - Suggested patch Add abort-level checks before any interpolated data are consumed: CCTK_INT variable_index = CCTK_VarIndex(name.c_str()); if (variable_index < 0) CCTK_VWarn(CCTK_WARN_ABORT, __LINE__, __FILE__, CCTK_THORNSTRING, "Could not find variable '%s'", name.c_str()); const int operator_handle = CCTK_InterpHandle("Hermite polynomial interpolation"); if (operator_handle < 0) CCTK_WARN(CCTK_WARN_ABORT, "Could not find Hermite interpolator"); int param_table_handle = Util_TableCreate(UTIL_TABLE_FLAGS_DEFAULT); if (param_table_handle < 0) CCTK_WARN(CCTK_WARN_ABORT, "Could not create interpolation table"); int ierr = Util_TableSetFromString(param_table_handle, "order=3 ..."); if (ierr < 0) CCTK_WARN(CCTK_WARN_ABORT, "Could not populate interpolation table"); ierr = Util_TableSetIntArray(param_table_handle, 4, operand_indices, "operand_indices"); if (ierr < 0) CCTK_WARN(CCTK_WARN_ABORT, "Could not set operand_indices"); ierr = Util_TableSetIntArray(param_table_handle, 4, operation_codes, "operation_codes"); if (ierr < 0) CCTK_WARN(CCTK_WARN_ABORT, "Could not set operation_codes"); const int coord_system_handle = CCTK_CoordSystemHandle("cart3d"); if (coord_system_handle < 0) CCTK_WARN(CCTK_WARN_ABORT, "Could not find cart3d coordinate system"); ierr = CCTK_InterpGridArrays(...); if (ierr < 0) CCTK_VWarn(CCTK_WARN_ABORT, __LINE__, __FILE__, CCTK_THORNSTRING, "Interpolation failed for '%s' with status %d", name.c_str(), ierr); ierr = Util_TableDestroy(param_table_handle); if (ierr < 0) CCTK_WARN(CCTK_WARN_ABORT, "Could not destroy interpolation table"); * Issue 2 - Severity medium - Description of the error The interpolation call must remain collective, but the spherical-harmonic work after interpolation is only useful on rank 0. Cactus schedule option GLOBAL means once per grid hierarchy/component scheduling level, not only on MPI rank 0. The existing rank-0 guard around output confirms that all ranks enter the routine. Nonzero ranks request zero interpolation points and then perform decomposition work whose results are discarded. - Filename + line number(s) repos/CCE_Export/schedule.ccl:3-8 repos/CCE_Export/src/cce_export.cc:135-183 repos/flesh/doc/UsersGuide/Appendices.tex:1034-1085 - Original code snippet Extract_Metric_Shift_Lapse_On_Sphere(...); Compute_Ylms(th, ph, re_ylms, im_ylms, lmax, array_size); for (int i = 0; i < 3; i++) { for (int j = i; j < 3; j++) { Decompose_Spherical_Harmonics(...); } } ... if (CCTK_MyProc(cctkGH) == 0) { Output_Decomposed_Metric_Data(...); } - Suggested patch Keep the collective interpolation outside the rank guard, then perform mode decomposition and output only on rank 0: Extract_Metric_Shift_Lapse_On_Sphere(...); if (CCTK_MyProc(cctkGH) == 0) { Compute_Ylms(th, ph, re_ylms, im_ylms, lmax, array_size); for (int i = 0; i < 3; i++) { for (int j = i; j < 3; j++) { Decompose_Spherical_Harmonics(...); } } for (int i = 0; i < 3; i++) { Decompose_Spherical_Harmonics(... beta ...); Decompose_Spherical_Harmonics(... dr_beta ...); Decompose_Spherical_Harmonics(... dt_beta ...); } Decompose_Spherical_Harmonics(... alpha ...); Decompose_Spherical_Harmonics(... dr_alpha ...); Decompose_Spherical_Harmonics(... dt_alpha ...); Output_Decomposed_Metric_Data(...); } * Issue 3 - Severity high - Description of the error CCTK_REAL precision is configurable in Cactus/ET. The writer stores data in vector but tells HDF5 that the memory buffer is H5T_NATIVE_DOUBLE. This is only safe for CCTK_REAL_PRECISION_8. CarpetIOHDF5 maps CCTK_REAL to H5T_NATIVE_FLOAT, H5T_NATIVE_DOUBLE, or H5T_NATIVE_LDOUBLE according to the configured precision, which is the relevant ET convention. The utility reader also needs a deliberate memory datatype if the on-disk datatype changes. - Filename + line number(s) repos/CCE_Export/src/h5_export.cc:65, 132 repos/CCE_Export/src/util/cce_export_hdf5_to_ascii.c:50, 76-77 repos/Carpet/CarpetIOHDF5/src/CarpetIOHDF5.hh:22-27 repos/Carpet/CarpetIOHDF5/src/CarpetIOHDF5.cc:249-302 - Original code snippet dataset = H5Dcreate(file, datasetname.c_str(), H5T_NATIVE_DOUBLE, dataspace, cparms); ... HDF5_ERROR(H5Dwrite(dataset, H5T_NATIVE_DOUBLE, memdataspace, filespace, H5P_DEFAULT, data)); - Suggested patch Use a CCTK_REAL-aware memory datatype for writes. If SpECTRE compatibility requires double-precision datasets on disk, keep the dataset datatype double and let HDF5 convert from the correct memory datatype: #if defined(CCTK_REAL_PRECISION_16) #define CCE_HDF5_REAL_MEMORY H5T_NATIVE_LDOUBLE #elif defined(CCTK_REAL_PRECISION_8) #define CCE_HDF5_REAL_MEMORY H5T_NATIVE_DOUBLE #elif defined(CCTK_REAL_PRECISION_4) #define CCE_HDF5_REAL_MEMORY H5T_NATIVE_FLOAT #else #error "Unsupported CCTK_REAL precision" #endif const hid_t file_real_type = H5T_NATIVE_DOUBLE; HDF5_ERROR(dataset = H5Dcreate(file, datasetname.c_str(), file_real_type, dataspace, cparms)); HDF5_ERROR(H5Dwrite(dataset, CCE_HDF5_REAL_MEMORY, memdataspace, filespace, H5P_DEFAULT, data)); In the utility reader, allocate the requested output type deliberately and pass the matching HDF5 memory datatype, for example: double *data = NULL; status = H5Dread(dataset_id, H5T_NATIVE_DOUBLE, H5S_ALL, H5S_ALL, H5P_DEFAULT, data); * Issue 4 - Severity medium - Description of the error This thorn has C++14/C++17 dependencies without an explicit local contract. Full ET context does not make this disappear: Cactus documentation still says C++11 is required, and several simfactory optionlists still select C++11 or C++14, even though newer generic and machine optionlists commonly use C++17. The code uses std::make_unique, comma-separated using-declarations, and std::filesystem. The filesystem feature-test check is also unreliable because it tests __cpp_lib_filesystem before including a header that would define it. - Filename + line number(s) repos/CCE_Export/src/h5_export.cc:3-8, 13 repos/CCE_Export/src/cce_export.cc:12 repos/CCE_Export/src/cce_export.hh:15 repos/CCE_Export/src/spherical_harmonic_decomposition.cc:5, 81-82 repos/flesh/doc/UsersGuide/Notes.tex:47-49 repos/simfactory2/mdb/optionlists/generic.cfg:30-32 repos/simfactory2/mdb/optionlists/debian-cuda.cfg:44 repos/simfactory2/mdb/optionlists/wheeler.cfg:19 - Original code snippet #if defined __cpp_lib_filesystem && __cpp_lib_filesystem < 201703L #include namespace fs = std::experimental::filesystem; #else #include namespace fs = std::filesystem; #endif using std::string, std::ostringstream, std::map, std::ios, std::setprecision; static auto fr = std::make_unique(array_size); - Suggested patch Either make C++17 an explicit requirement, or remove the C++17-only code. A minimal explicit-contract patch is: #if __cplusplus < 201703L #error "CCE_Export requires C++17 or later" #endif #include namespace fs = std::filesystem; using std::string; using std::ostringstream; using std::map; using std::ios; using std::setprecision; Also document the C++17 requirement in README/ThornGuide and ensure the build configuration used for this thorn selects a C++17-capable compiler mode. If C++11 compatibility is desired instead, replace std::filesystem with Cactus/local path handling and replace comma-separated using-declarations with individual declarations. * Issue 5 - Severity high - Description of the error For gravitational-wave extraction/CCE, r = 0 is not a valid extraction radius or worldtube. The default configuration activates one radius at radius[0] = 0.0, so a user who merely activates the thorn with defaults is requesting mathematically invalid data. The implementation then compounds this by computing radial derivatives through x^i/r partial_i, which divides by radius[rad_index]. Unlike Multipole, CCE_Export explicitly exports radial derivatives of worldtube data, so zero radius must be rejected, not treated as an allowed lower endpoint. - Filename + line number(s) repos/CCE_Export/param.ccl:9-17 repos/CCE_Export/src/interpolate.cc:173-179, 197-202, 215-218 - Original code snippet CCTK_INT nradii "How many radii to export the data on" STEERABLE=recover { 0:100 :: "number of radii" } 1 CCTK_REAL radius[101] "Radii to export the metric data on" STEERABLE=recover { 0.0:* :: "Extraction radius" } 0.0 dr_g.at(i).at(j).at(array_index) = (xs.at(array_index) / radius[rad_index]) * dx_g.at(i).at(j).at(array_index) + (ys.at(array_index) / radius[rad_index]) * dy_g.at(i).at(j).at(array_index) + (zs.at(array_index) / radius[rad_index]) * dz_g.at(i).at(j).at(array_index); - Suggested patch Make the default inactive or positive, and reject every active non-positive extraction radius before interpolation: CCTK_INT nradii "How many radii to export the data on" STEERABLE=recover { 0:100 :: "number of radii" } 0 CCTK_REAL radius[101] "Radii to export the metric data on" STEERABLE=recover { (0.0:* :: "Positive extraction radius" } 1.0 for (int ir = 0; ir < nradii; ++ir) { if (radius[ir] <= 0.0) { CCTK_VWarn(CCTK_WARN_ABORT, __LINE__, __FILE__, CCTK_THORNSTRING, "CCE_Export::radius[%d] = %.17g is invalid: CCE/worldtube " "extraction radii must be strictly positive", ir, static_cast(radius[ir])); } } * Issue 6 - Severity medium - Description of the error Output is documented and implemented as one file per extraction radius, but the filename uses a float argument and fixed two-decimal formatting. Distinct CCTK_REAL radii can therefore collide in the same output filename. The parameter documentation mentions two decimal places, but that does not protect the data from accidental collisions and is inconsistent with "a separate h5 file for each desired extraction radius." - Filename + line number(s) repos/CCE_Export/src/h5_export.hh:25-39 repos/CCE_Export/src/h5_export.cc:154, 168-171 repos/CCE_Export/src/cce_export.cc:178-182 repos/CCE_Export/param.ccl:25-29 repos/CCE_Export/doc/documentation.tex:49-50 - Original code snippet void Output_Decomposed_Metric_Data(..., float rad, int lmax) { ... basename << base_file_name << "R" << setiosflags(ios::fixed) << setprecision(2) << rad << "." << extension; string output_name = (fs::path(my_out_dir) / basename.str()).string(); } - Suggested patch Preserve CCTK_REAL precision through the output path, increase filename precision, and validate that active radii produce unique names: void Output_Decomposed_Metric_Data(..., CCTK_REAL rad, int lmax) { ... basename << base_file_name << "R" << setiosflags(ios::fixed) << setprecision(12) << static_cast(rad) << "." << extension; string output_name = (fs::path(my_out_dir) / basename.str()).string(); } std::set output_names; for (int ir = 0; ir < nradii; ++ir) { std::ostringstream name; name << base_file_name << "R" << std::fixed << std::setprecision(12) << static_cast(radius[ir]) << "." << extension; if (!output_names.insert(name.str()).second) { CCTK_VWarn(CCTK_WARN_ABORT, __LINE__, __FILE__, CCTK_THORNSTRING, "Multiple CCE_Export radii map to output file '%s'", name.str().c_str()); } } * Issue 7 - Severity medium - Description of the error The documentation is wrong in two places. The metric components are interpolated directly from ADMBase; the code uses the ADM extrinsic-curvature relation to compute partial_t gamma_ij, not to compute gamma_ij itself. The spherical-harmonic coefficient integral implemented here is over dOmega using sin(theta) dtheta dphi and does not multiply by r^2. - Filename + line number(s) repos/CCE_Export/doc/documentation.tex:76-84, 93-100 repos/CCE_Export/src/interpolate.cc:166-170, 221-311 repos/CCE_Export/src/spherical_harmonic_decomposition.cc:84-96 - Original code snippet The metric is computed from the extrinsic curvature, lapse, and shift as: \begin{equation} K_{ij} = \frac{1}{2 \alpha} \left ( -\partial_0 \gamma_{ij} + \beta^k \partial_k \gamma_{ij} + \gamma_{ki} \partial_j \beta^k + \gamma_{kj} \partial_i \beta^k \right ) \, . \end{equation} C^{lm}(t, r) = \int {}_0 Y_{lm}^* u(t, r, \theta, \varphi) r^2 d \Omega - Suggested patch Update the ThornGuide to describe the implemented mathematics: The metric components are interpolated directly from ADMBase. The metric time derivative is computed by inverting the ADM definition of extrinsic curvature: \begin{equation} \partial_t \gamma_{ij} = -2\alpha K_{ij} + \beta^k \partial_k \gamma_{ij} + \gamma_{ki} \partial_j \beta^k + \gamma_{kj} \partial_i \beta^k . \end{equation} The spherical-harmonic coefficients are \begin{eqnarray} C^{lm}(t, r) = \int {}_0 Y_{lm}^* u(t, r, \theta, \varphi) d\Omega . \end{eqnarray} * Issue 8 - Severity medium - Description o -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2944/cce_export-issues-ticket -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 19 09:23:12 2026 From: trac-noreply at einsteintoolkit.org (Erik Schnetter) Date: Tue, 19 May 2026 14:23:12 +0000 Subject: [ET Trac] #2945: flesh: Avoid buffer overflows in util/Time.c Message-ID: #2945: flesh: Avoid buffer overflows in util/Time.c Reporter: Erik Schnetter Status: new Milestone: Version: Type: bug Priority: major Component: Cactus https://bitbucket.org/cactuscode/cactus/pull-requests/177 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2945/flesh-avoid-buffer-overflows-in-util-timec -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 19 10:47:16 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 19 May 2026 15:47:16 +0000 Subject: [ET Trac] #2936: CarpetX tsv output does not append files Message-ID: #2936: CarpetX tsv output does not append files Reporter: Maxwell Rizzo Status: open Milestone: Version: Type: enhancement Priority: minor Component: CarpetX Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2936/carpetx-tsv-output-does-not-append-files -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 19 10:47:07 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 19 May 2026 15:47:07 +0000 Subject: [ET Trac] #2936: CarpetX tsv output does not append files Message-ID: #2936: CarpetX tsv output does not append files Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: enhancement Priority: minor Component: CarpetX Changes (by Roland Haas): responsible: [] (was ) assignee: Erik Schnetter (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2936/carpetx-tsv-output-does-not-append-files -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 19 10:46:48 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 19 May 2026 15:46:48 +0000 Subject: [ET Trac] #2936: CarpetX tsv output does not append files Message-ID: #2936: CarpetX tsv output does not append files Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: enhancement Priority: minor Component: CarpetX Comment (by Roland Haas): Please apply. @{557058:1671c5c3-29cc-4e83-9850-a152d33a6235} is this ok to apply with you? There is no feature freeze just yet, but it may be close? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2936/carpetx-tsv-output-does-not-append-files -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 19 09:43:15 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 19 May 2026 14:43:15 +0000 Subject: [ET Trac] #2945: flesh: Avoid buffer overflows in util/Time.c Message-ID: #2945: flesh: Avoid buffer overflows in util/Time.c Reporter: Erik Schnetter Status: open Milestone: Version: Type: bug Priority: major Component: Cactus Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2945/flesh-avoid-buffer-overflows-in-util-timec -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 19 09:43:10 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 19 May 2026 14:43:10 +0000 Subject: [ET Trac] #2945: flesh: Avoid buffer overflows in util/Time.c Message-ID: #2945: flesh: Avoid buffer overflows in util/Time.c Reporter: Erik Schnetter Status: new Milestone: Version: Type: bug Priority: major Component: Cactus Comment (by Roland Haas): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2945/flesh-avoid-buffer-overflows-in-util-timec -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri May 15 11:22:49 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Fri, 15 May 2026 16:22:49 +0000 Subject: [ET Trac] #7: Add test of the volume form in Coordinates Message-ID: #7: Add test of the volume form in Coordinates Reporter: Jordan Nicoules Status: submitted Milestone: Version: Type: enhancement Priority: major Component: Comment (by Steven R. Brandt): PR is here: https://bitbucket.org/llamacode/llama/pull-requests/10?t=1 -- Ticket URL: https://bitbucket.org/llamacode/llama/issues/7/add-test-of-the-volume-form-in-coordinates -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 19 09:48:44 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 19 May 2026 14:48:44 +0000 Subject: [ET Trac] #2945: flesh: Avoid buffer overflows in util/Time.c Message-ID: #2945: flesh: Avoid buffer overflows in util/Time.c Reporter: Erik Schnetter Status: resolved Milestone: Version: Type: bug Priority: major Component: Cactus Changes (by Roland Haas): status: resolved (was open) Comment (by Roland Haas): Thank you! -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2945/flesh-avoid-buffer-overflows-in-util-timec -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 19 09:48:37 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 19 May 2026 14:48:37 +0000 Subject: [ET Trac] #2945: flesh: Avoid buffer overflows in util/Time.c Message-ID: #2945: flesh: Avoid buffer overflows in util/Time.c Reporter: Erik Schnetter Status: open Milestone: Version: Type: bug Priority: major Component: Cactus Comment (by Roland Haas): Applied as git hash [0fbf43ad](https://bitbucket.org/cactuscode/cactus/commits/0fbf43ad166a9b3a5c828564d9251d032db68c5c) "flesh: Avoid buffer overflows in util/Time.c" of [cactus](https://bitbucket.org/cactuscode/cactus) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2945/flesh-avoid-buffer-overflows-in-util-timec -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 14 14:01:41 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 14 May 2026 19:01:41 +0000 Subject: [ET Trac] #2944: CCE_Export Issues Ticket Message-ID: #2944: CCE_Export Issues Ticket Reporter: Zach Etienne Status: new Milestone: Version: Type: bug Priority: major Component: Changes (by Roland Haas): responsible: [] (was []) assignee: Deborah Ferguson (was Zach Etienne) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2944/cce_export-issues-ticket -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 19 18:12:49 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 19 May 2026 23:12:49 +0000 Subject: [ET Trac] #2898: CarpetX: split interpolator calls into setup and evaluate phase Message-ID: #2898: CarpetX: split interpolator calls into setup and evaluate phase Reporter: Lucas Timotheo Sanches Status: open Milestone: ET_2026_05 Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): Looks good to me (have comments on comments). Please make sure that commit history and messages are sensible. Please apply. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2898/carpetx-split-interpolator-calls-into -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 19 19:15:58 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Wed, 20 May 2026 00:15:58 +0000 Subject: [ET Trac] #2939: AHFinderDirect: range options for track_origin_source_x/y/z Message-ID: #2939: AHFinderDirect: range options for track_origin_source_x/y/z Reporter: Jordan Nicoules Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Steven R. Brandt): Roland and I had convinced ourselves that surely there must be an implicit ^ before the pattern and a $ after... but such is not the case. You are right in that "" literally matches anything. I have updated the PR. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2939/ahfinderdirect-range-options-for -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 19 20:21:52 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 20 May 2026 01:21:52 +0000 Subject: [ET Trac] #2939: AHFinderDirect: range options for track_origin_source_x/y/z Message-ID: #2939: AHFinderDirect: range options for track_origin_source_x/y/z Reporter: Jordan Nicoules Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): note that `""` matching anything is as documented, https://einsteintoolkit.org/usersguide/UsersGuide.html#x1-187000D2.3.2 > Allowed values for strings should be specified using regular expressions. To allow any string, the regular expression "" should be used. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2939/ahfinderdirect-range-options-for -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed May 20 03:38:47 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Wed, 20 May 2026 08:38:47 +0000 Subject: [ET Trac] #2932: Kuibit: detecting 0D and 1D files generated during Llama runs Message-ID: #2932: Kuibit: detecting 0D and 1D files generated during Llama runs Reporter: Jordan Nicoules Status: new Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Jordan Nicoules): PR https://github.com/Sbozzolo/kuibit/pull/48 was merged into master branch and issue https://github.com/Sbozzolo/kuibit/issues/47 was closed. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2932/kuibit-detecting-0d-and-1d-files-generated -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed May 20 03:39:09 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Wed, 20 May 2026 08:39:09 +0000 Subject: [ET Trac] #2932: Kuibit: detecting 0D and 1D files generated during Llama runs Message-ID: #2932: Kuibit: detecting 0D and 1D files generated during Llama runs Reporter: Jordan Nicoules Status: resolved Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit thorn Changes (by Jordan Nicoules): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2932/kuibit-detecting-0d-and-1d-files-generated -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed May 20 14:05:17 2026 From: trac-noreply at einsteintoolkit.org (Lucas Timotheo Sanches) Date: Wed, 20 May 2026 19:05:17 +0000 Subject: [ET Trac] #2898: CarpetX: split interpolator calls into setup and evaluate phase Message-ID: #2898: CarpetX: split interpolator calls into setup and evaluate phase Reporter: Lucas Timotheo Sanches Status: open Milestone: ET_2026_05 Version: Type: enhancement Priority: major Component: Comment (by Lucas Timotheo Sanches): Merged into master [here](https://github.com/EinsteinToolkit/CarpetX/commit/8883b4199b26f0f6bd41d41c0ba5b94d46e84b51) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2898/carpetx-split-interpolator-calls-into -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed May 20 14:05:48 2026 From: trac-noreply at einsteintoolkit.org (Lucas Timotheo Sanches) Date: Wed, 20 May 2026 19:05:48 +0000 Subject: [ET Trac] #2898: CarpetX: split interpolator calls into setup and evaluate phase Message-ID: #2898: CarpetX: split interpolator calls into setup and evaluate phase Reporter: Lucas Timotheo Sanches Status: resolved Milestone: ET_2026_05 Version: Type: enhancement Priority: major Component: Changes (by Lucas Timotheo Sanches): status: resolved (was open) Comment (by Lucas Timotheo Sanches): Merged into master [here](https://github.com/EinsteinToolkit/CarpetX/commit/8883b4199b26f0f6bd41d41c0ba5b94d46e84b51) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2898/carpetx-split-interpolator-calls-into -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed May 20 17:35:30 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Wed, 20 May 2026 22:35:30 +0000 Subject: [ET Trac] #2946: CarpetX includes `` when OpenMP is not enabled Message-ID: #2946: CarpetX includes `` when OpenMP is not enabled Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: bug Priority: minor Component: CarpetX Two files, `CarpetX/src/driver.cxx` at [L22](https://github.com/EinsteinToolkit/CarpetX/blob/8883b4199b26f0f6bd41d41c0ba5b94d46e84b51/CarpetX/src/driver.cxx#L22) and `.../boundaries.cxx` at [L9](https://github.com/EinsteinToolkit/CarpetX/blob/8883b4199b26f0f6bd41d41c0ba5b94d46e84b51/CarpetX/src/boundaries.cxx#L9), include `` without checking whether `_OPENMP` is defined, unlike other CarpetX files such as `CarpetX/src/schedule.cxx` at [L19](https://github.com/EinsteinToolkit/CarpetX/blob/8883b4199b26f0f6bd41d41c0ba5b94d46e84b51/CarpetX/src/schedule.cxx#L19). This always includes OpenMP when compiling CarpetX, which can cause compile time failure for systems that do not provide OpenMP, even with OpenMP disabled. This bug was encountered when compiling CarpetX while OpenMP is not enabled with macOS Clang, which does not provide OpenMP by default. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2946/carpetx-includes-when-openmp-is-not -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed May 20 17:36:21 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 20 May 2026 22:36:21 +0000 Subject: [ET Trac] #2946: CarpetX includes `` when OpenMP is not enabled Message-ID: #2946: CarpetX includes `` when OpenMP is not enabled Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: bug Priority: minor Component: CarpetX Changes (by Roland Haas): responsible: [] (was ) assignee: Roland Haas (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2946/carpetx-includes-when-openmp-is-not -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed May 20 17:42:56 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 20 May 2026 22:42:56 +0000 Subject: [ET Trac] #2946: CarpetX includes `` when OpenMP is not enabled Message-ID: #2946: CarpetX includes `` when OpenMP is not enabled Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: bug Priority: minor Component: CarpetX Comment (by Roland Haas): int `driver.cxx` nothing is actually used that relies on `omp.h` (not `omp_FOO()` function is being called). In `boundaries.cxx` the calls to `omp_FOO()` happen only in commented out timer code. I will remove / comment out the `#include ` line. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2946/carpetx-includes-when-openmp-is-not -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed May 20 17:44:22 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 20 May 2026 22:44:22 +0000 Subject: [ET Trac] #2946: CarpetX includes `` when OpenMP is not enabled Message-ID: #2946: CarpetX includes `` when OpenMP is not enabled Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: bug Priority: minor Component: CarpetX Comment (by Roland Haas): note that this issue will never show up with gcc, since it always has a file `omp.h` in the include search path, but Apple's clang on macOS, which does not support OpenMP at all, does not provide such a file, hence the error shows up. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2946/carpetx-includes-when-openmp-is-not -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed May 20 17:45:17 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 20 May 2026 22:45:17 +0000 Subject: [ET Trac] #2946: CarpetX includes `` when OpenMP is not enabled Message-ID: #2946: CarpetX includes `` when OpenMP is not enabled Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: bug Priority: minor Component: CarpetX Comment (by Roland Haas): ``` diff --git a/CarpetX/src/boundaries.cxx b/CarpetX/src/boundaries.cxx index f76fab13..17e7d492 100644 --- a/CarpetX/src/boundaries.cxx +++ b/CarpetX/src/boundaries.cxx @@ -6,7 +6,7 @@ #include -#include +// #include #include #include diff --git a/CarpetX/src/driver.cxx b/CarpetX/src/driver.cxx index 04ba771b..76f37746 100644 --- a/CarpetX/src/driver.cxx +++ b/CarpetX/src/driver.cxx @@ -19,7 +19,6 @@ #include #include -#include #include #include ``` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2946/carpetx-includes-when-openmp-is-not -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed May 20 17:46:16 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 20 May 2026 22:46:16 +0000 Subject: [ET Trac] #2946: CarpetX includes `` when OpenMP is not enabled Message-ID: #2946: CarpetX includes `` when OpenMP is not enabled Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: bug Priority: minor Component: CarpetX Comment (by Roland Haas): https://github.com/EinsteinToolkit/CarpetX/pull/384 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2946/carpetx-includes-when-openmp-is-not -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed May 20 18:27:47 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 20 May 2026 23:27:47 +0000 Subject: [ET Trac] #2946: CarpetX includes `` when OpenMP is not enabled Message-ID: #2946: CarpetX includes `` when OpenMP is not enabled Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: bug Priority: minor Component: CarpetX Comment (by Roland Haas): Applied as git hash [b0aa1775](https://github.com/EinsteinToolkit/CarpetX/commits/b0aa177566ccf339a3d38a993b9de925b7ecefae) "CarpetX: comment out omp.h used only in commented out code" of [CarpetX](https://github.com/EinsteinToolkit/CarpetX) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2946/carpetx-includes-when-openmp-is-not -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed May 20 18:27:55 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 20 May 2026 23:27:55 +0000 Subject: [ET Trac] #2946: CarpetX includes `` when OpenMP is not enabled Message-ID: #2946: CarpetX includes `` when OpenMP is not enabled Reporter: Maxwell Rizzo Status: resolved Milestone: Version: Type: bug Priority: minor Component: CarpetX Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2946/carpetx-includes-when-openmp-is-not -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 21 09:03:54 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 May 2026 14:03:54 +0000 Subject: [ET Trac] #2943: Formaline rejects valid symlinks in GRHayLib Message-ID: #2943: Formaline rejects valid symlinks in GRHayLib Reporter: Zach Etienne Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Applied as git hash [fddaed6](https://bitbucket.org/cactuscode/cactusutils/commits/fddaed620cf48db1df992298f209222ea794ce7a) "Formaline: preserve symlinks in git source snapshots" of [cactusutils](https://bitbucket.org/cactuscode/cactusutils) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2943/formaline-rejects-valid-symlinks-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 21 09:04:01 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 May 2026 14:04:01 +0000 Subject: [ET Trac] #2943: Formaline rejects valid symlinks in GRHayLib Message-ID: #2943: Formaline rejects valid symlinks in GRHayLib Reporter: Zach Etienne Status: resolved Milestone: Version: Type: bug Priority: major Component: Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2943/formaline-rejects-valid-symlinks-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 21 09:05:59 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 May 2026 14:05:59 +0000 Subject: [ET Trac] #2941: CCE_Export uses `setiosflags` unqualified without an explicit using-declaration Message-ID: #2941: CCE_Export uses `setiosflags` unqualified without an explicit using-declaration Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): Applied as git hash [a5aa4cb](https://github.com/deborahferguson/CCE_Export/commits/a5aa4cb81f1114b5b689a0bd36e7d6a678f82c88) "CCE_Export: Add missing `using std::setiosflags`. (#17)" of [CCE_Export](https://github.com/deborahferguson/CCE_Export) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2941/cce_export-uses-setiosflags-unqualified -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 21 09:06:12 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 May 2026 14:06:12 +0000 Subject: [ET Trac] #2941: CCE_Export uses `setiosflags` unqualified without an explicit using-declaration Message-ID: #2941: CCE_Export uses `setiosflags` unqualified without an explicit using-declaration Reporter: Maxwell Rizzo Status: resolved Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2941/cce_export-uses-setiosflags-unqualified -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 21 09:06:21 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 May 2026 14:06:21 +0000 Subject: [ET Trac] #2940: CCE_Export: allow for changing array_size Message-ID: #2940: CCE_Export: allow for changing array_size Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: Comment (by Roland Haas): Applied as git hash [e02fd63](https://github.com/deborahferguson/CCE_Export/commits/e02fd636307bd9aaae07468706dc4729600c03f1) "CCE_Export: allow for changing array_size (#16)" of [CCE_Export](https://github.com/deborahferguson/CCE_Export) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2940/cce_export-allow-for-changing-array_size -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 21 09:06:40 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 May 2026 14:06:40 +0000 Subject: [ET Trac] #2940: CCE_Export: allow for changing array_size Message-ID: #2940: CCE_Export: allow for changing array_size Reporter: Roland Haas Status: resolved Milestone: Version: Type: bug Priority: minor Component: Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2940/cce_export-allow-for-changing-array_size -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 21 09:06:58 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 May 2026 14:06:58 +0000 Subject: [ET Trac] #2908: Cactus: Fixed arg list too long error. Message-ID: #2908: Cactus: Fixed arg list too long error. Reporter: Max Morris Status: open Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Ping. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2908/cactus-fixed-arg-list-too-long-error -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 21 09:07:16 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 May 2026 14:07:16 +0000 Subject: [ET Trac] #2908: Cactus: Fixed arg list too long error. Message-ID: #2908: Cactus: Fixed arg list too long error. Reporter: Max Morris Status: open Milestone: Version: Type: bug Priority: major Component: Changes (by Roland Haas): responsible: [] (was ) assignee: Roland Haas (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2908/cactus-fixed-arg-list-too-long-error -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 21 10:45:28 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 May 2026 15:45:28 +0000 Subject: [ET Trac] #2936: CarpetX tsv output does not append files Message-ID: #2936: CarpetX tsv output does not append files Reporter: Maxwell Rizzo Status: open Milestone: Version: Type: enhancement Priority: minor Component: CarpetX Comment (by Roland Haas): Applied as git hash [41a00b89](https://github.com/EinsteinToolkit/CarpetX/commits/41a00b89642a375973e237eb9feeeea99f390b54) "CarpetX: Replace some assert by CCTK_ERROR" of [CarpetX](https://github.com/EinsteinToolkit/CarpetX) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2936/carpetx-tsv-output-does-not-append-files -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 21 10:46:26 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 May 2026 15:46:26 +0000 Subject: [ET Trac] #2936: CarpetX tsv output does not append files Message-ID: #2936: CarpetX tsv output does not append files Reporter: Maxwell Rizzo Status: open Milestone: Version: Type: enhancement Priority: minor Component: CarpetX Comment (by Roland Haas): Thank you @{5f2f18c8e8c45600229698f5} & @{557058:56049c54-f8c2-4b6c-9b88-ab697c967495} -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2936/carpetx-tsv-output-does-not-append-files -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 21 10:46:31 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 May 2026 15:46:31 +0000 Subject: [ET Trac] #2936: CarpetX tsv output does not append files Message-ID: #2936: CarpetX tsv output does not append files Reporter: Maxwell Rizzo Status: resolved Milestone: Version: Type: enhancement Priority: minor Component: CarpetX Changes (by Roland Haas): status: resolved (was open) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2936/carpetx-tsv-output-does-not-append-files -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 21 12:09:10 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Thu, 21 May 2026 17:09:10 +0000 Subject: [ET Trac] #2939: AHFinderDirect: range options for track_origin_source_x/y/z Message-ID: #2939: AHFinderDirect: range options for track_origin_source_x/y/z Reporter: Jordan Nicoules Status: resolved Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Changes (by Steven R. Brandt): status: resolved (was new) Comment (by Steven R. Brandt): Fixed. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2939/ahfinderdirect-range-options-for -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 21 12:52:03 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 May 2026 17:52:03 +0000 Subject: [ET Trac] #2939: AHFinderDirect: range options for track_origin_source_x/y/z Message-ID: #2939: AHFinderDirect: range options for track_origin_source_x/y/z Reporter: Jordan Nicoules Status: resolved Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): Still incorrect since will will not accept `puncturetracker::puncture_x` since it requires a `[?]` bit at the end. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2939/ahfinderdirect-range-options-for -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 21 12:52:06 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 May 2026 17:52:06 +0000 Subject: [ET Trac] #2939: AHFinderDirect: range options for track_origin_source_x/y/z Message-ID: #2939: AHFinderDirect: range options for track_origin_source_x/y/z Reporter: Jordan Nicoules Status: open Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Changes (by Roland Haas): status: open (was resolved) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2939/ahfinderdirect-range-options-for -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 21 13:04:04 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Thu, 21 May 2026 18:04:04 +0000 Subject: [ET Trac] #2947: CarpetX: Support 2D output Message-ID: #2947: CarpetX: Support 2D output Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: enhancement Priority: minor Component: Currently 1D slices (x/y/z) and the full 3D output for Grid Functions are both supported output configurations from CarpetX. CarpetX is missing functionality to output 2D planes (xy, xz, yz). There is a sublety for how the slice is chosen, given the different centering options, some variables likely will not contain data along the `x/y/z=0` planes exactly, which is a similar sublety that the 1D output slice must resolve, hopefully these can be resolve consistently. Also from a discussion with Roland, 2D output is inefficient for a Carpet/CarpetX simulation to output, compared to 1D and 3D. A performance test could be useful in gauging if this feature would be worth implementing/using at all in CarpetX. TSV (or another text file format) probably makes sense as the starting point, if functional a compressed format like OpenPMD would also be desirable, bringing the 2D CarpetX output features in-line to what was present in Carpet. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2947/carpetx-support-2d-output -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 21 13:05:22 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Thu, 21 May 2026 18:05:22 +0000 Subject: [ET Trac] #2947: CarpetX: Support 2D output Message-ID: #2947: CarpetX: Support 2D output Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: enhancement Priority: minor Component: Changes (by Maxwell Rizzo): Currently 1D slices (x/y/z) and the full 3D output for Grid Functions are both supported output configurations from CarpetX. CarpetX is missing functionality to output GFs sliced along 2D planes (xy, xz, yz). There is a sublety for how the slice is chosen, given the different centering options, some variables likely will not contain data along the `x/y/z=0` planes exactly, which is a similar sublety that the 1D output slice must resolve, hopefully these can be resolve consistently. Also from a discussion with Roland, 2D output is inefficient for a Carpet/CarpetX simulation to output, compared to 1D and 3D. A performance test could be useful in gauging if this feature would be worth implementing/using at all in CarpetX. TSV (or another text file format) probably makes sense as the starting point, if functional a compressed format like OpenPMD would also be desirable, bringing the 2D CarpetX output features in-line to what was present in Carpet. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2947/carpetx-support-2d-output -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 21 13:05:50 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Thu, 21 May 2026 18:05:50 +0000 Subject: [ET Trac] #2947: CarpetX: Support 2D output Message-ID: #2947: CarpetX: Support 2D output Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: enhancement Priority: minor Component: Changes (by Maxwell Rizzo): Currently 1D slices (x/y/z) and the full 3D output for Grid Functions are both supported output configurations from CarpetX. CarpetX is missing functionality to output GFs sliced along 2D planes (xy, xz, yz). There is a sublety for how the slice is chosen, given the different centering options, some variables likely will not contain data along the `x/y/z=0` planes exactly, which is a similar sublety that the 1D output slice must resolve, hopefully these can be resolved consistently. Also from a discussion with Roland, 2D output is inefficient for a Carpet/CarpetX simulation to output, compared to 1D and 3D. A performance test could be useful in gauging if this feature would be worth implementing/using at all in CarpetX. TSV (or another text file format) probably makes sense as the starting point, if functional a compressed format like OpenPMD would also be desirable, bringing the 2D CarpetX output features in-line to what was present in Carpet. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2947/carpetx-support-2d-output -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri May 22 18:03:10 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Fri, 22 May 2026 23:03:10 +0000 Subject: [ET Trac] #2948: HydroBaseX: Missing HydroBase features (Aphi GF, conditional storage, split init) Message-ID: #2948: HydroBaseX: Missing HydroBase features (Aphi GF, conditional storage, split init) Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: bug Priority: minor Component: CarpetX Current HydroBaseX has a single routine that zeros all the variables it declares, along with a single parameter controlling whether this routine runs: `initial_hydro`. This parameter was used/extended by initial data thorns when they provide hydro quantities. Following the legacy Carpet/HydroBase convention, `initial_hydro` should only control the minimal hydro fields, with other GFs accompanied by corresponding `initial_*` parameters and routines. The current implementation works, but is awkward for initial hydro data thorns to integrate with: they can either avoid using `initial_hydro` themselves and let HydroBaseX zero all fields and place their data ontop of that, or they can manually zero the fields they are not providing, which is unnecessary when HydroBaseX should be able to do it. Additionally, HydroBaseX is missing the `Aphi` GF. This is the electric potential, and adding it would round out the EM support alongside `Bvec` and `Avec`. Lastly, modularizing this initialization should allow conditional storage to be restored, storing optional hydro fields only when the corresponding `initial_*` parameter is not `"none"`, following HydroBase. This should also provide a minor memory/performance improvement. Addressed by already open PR: [#385](https://github.com/EinsteinToolkit/CarpetX/pull/385) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2948/hydrobasex-missing-hydrobase-features-aphi -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon May 25 09:45:30 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Mon, 25 May 2026 14:45:30 +0000 Subject: [ET Trac] #2922: CarpetX does not compile with CUDA 12.9 Message-ID: #2922: CarpetX does not compile with CUDA 12.9 Reporter: Steven R. Brandt Status: new Milestone: ET_2026_05 Version: Type: bug Priority: major Component: CarpetX Comment (by Steven R. Brandt): https://github.com/EinsteinToolkit/CarpetX/pull/387 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2922/carpetx-does-not-compile-with-cuda-129 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon May 25 20:08:28 2026 From: trac-noreply at einsteintoolkit.org (Lucas Timotheo Sanches) Date: Tue, 26 May 2026 01:08:28 +0000 Subject: [ET Trac] #2174: Test "Multi Patch Scalar Wave Equation" example Message-ID: #2174: Test "Multi Patch Scalar Wave Equation" example Reporter: Roland Haas Status: resolved Milestone: ET_2026_05 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Lucas Timotheo Sanches): status: resolved (was open) Comment (by Lucas Timotheo Sanches): Updated gallery example for ET_2026_05 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2174/test-multi-patch-scalar-wave-equation -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 26 10:44:48 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 26 May 2026 15:44:48 +0000 Subject: [ET Trac] #2949: use c99 bool instead of typedefing our own Message-ID: #2949: use c99 bool instead of typedefing our own Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: C23 makes `bool` a reserved keyword and provides the type by default making some thorns (and the flesh) fail to compiled. These three pull requests add the required `#include ` to the respective files. Since this exists in c99, which Cactus requires, this is fine. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2949/use-c99-bool-instead-of-typedefing-our-own -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 26 10:49:24 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 26 May 2026 15:49:24 +0000 Subject: [ET Trac] #2949: use c99 bool instead of typedefing our own Message-ID: #2949: use c99 bool instead of typedefing our own Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: Comment (by Roland Haas): Pull requests are here: * https://bitbucket.org/cactuscode/cactus/pull-requests/178 * https://bitbucket.org/cactuscode/cactustest/pull-requests/6 * https://bitbucket.org/cactuscode/numerical/pull-requests/3 Please review -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2949/use-c99-bool-instead-of-typedefing-our-own -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 26 10:55:15 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 26 May 2026 15:55:15 +0000 Subject: [ET Trac] #2922: CarpetX does not compile with CUDA 12.9 Message-ID: #2922: CarpetX does not compile with CUDA 12.9 Reporter: Steven R. Brandt Status: new Milestone: ET_2026_05 Version: Type: bug Priority: major Component: CarpetX Comment (by Roland Haas): This seems to actually have been due to newer compilers pulling in C++23 stdc++ library files, which push more names into the `std` namespace. Pull request https://github.com/EinsteinToolkit/CarpetX/pull/381 addresses this and resolves this ticket as well. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2922/carpetx-does-not-compile-with-cuda-129 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 26 10:56:03 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 26 May 2026 15:56:03 +0000 Subject: [ET Trac] #2922: CarpetX does not compile with CUDA 12.9 Message-ID: #2922: CarpetX does not compile with CUDA 12.9 Reporter: Steven R. Brandt Status: new Milestone: ET_2026_05 Version: Type: bug Priority: major Component: CarpetX Comment (by Roland Haas): Applied as git hash [2bb7f9bc](https://github.com/EinsteinToolkit/CarpetX/commits/2bb7f9bc10d7e0ba5657fb0e34cf779bbf2cdf81) "CarpetX: add more missing std qualifiers" of [CarpetX](https://github.com/EinsteinToolkit/CarpetX) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2922/carpetx-does-not-compile-with-cuda-129 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 26 10:58:49 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 26 May 2026 15:58:49 +0000 Subject: [ET Trac] #2922: CarpetX does not compile with CUDA 12.9 Message-ID: #2922: CarpetX does not compile with CUDA 12.9 Reporter: Steven R. Brandt Status: resolved Milestone: ET_2026_05 Version: Type: bug Priority: major Component: CarpetX Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2922/carpetx-does-not-compile-with-cuda-129 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 26 10:59:59 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 26 May 2026 15:59:59 +0000 Subject: [ET Trac] #2944: CCE_Export Issues Ticket Message-ID: #2944: CCE_Export Issues Ticket Reporter: Zach Etienne Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Clearly we need a policy on wordy LLM generated reviews. Ideally one ticket per issue would be used, making progress easier to track. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2944/cce_export-issues-ticket -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue May 26 11:24:50 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Tue, 26 May 2026 16:24:50 +0000 Subject: [ET Trac] #2950: CarpetX/ADMBaseX: Missing ADMBase features (Conditional storage, evolution parameters) Message-ID: #2950: CarpetX/ADMBaseX: Missing ADMBase features (Conditional storage, evolution parameters) Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: bug Priority: minor Component: CarpetX Very similar to #2948, but smaller in scope. Mostly consistency and future proofing in mind. All changes are following the previous Carpet ADMBase conventions. 1. Missing conditional storage on the extra fields (shift, dtlapse, dtshift). 2. Missng `*_evolution_method` parameters specifying which thorn evolves which fields. 3. ADMBaseX defaults to an initial dtlapse/dtshift of `zero` instead of `none` (previously in Carpet ADMBase). With conditional storage it probably makes sense to return to the `none` default to only enable the extra fields if the user needs them. Changing this default here may break some test parameter files. Addressed by CarpetX [PR #386](https://github.com/EinsteinToolkit/CarpetX/pull/386) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2950/carpetx-admbasex-missing-admbase-features -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed May 27 12:25:13 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Wed, 27 May 2026 17:25:13 +0000 Subject: [ET Trac] #2951: Cottonmouth uses `max()` unqualified without a using declaration Message-ID: #2951: Cottonmouth uses `max()` unqualified without a using declaration Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn CottonmouthZ4c4m/src/CottonmouthZ4c4m_z4c_enforce_pt1.cpp CottonmouthBSSNOK4m/src/CottonmouthBSSNOK4m_enforce_pt1.cpp both files have unqualified calls of the `max()` function. Both have the same using statement on line 41, ``` using std::cbrt,std::fmax,std::fmin,std::sqrt; ``` `fmax` being unused in both files maybe suggests that this `std::fmax` should be `std::max`, as it is generated code it isn't clear if this is a human error or an issue with the generation. Cottonmouth fails to compile on Anvil with error ``` error: 'max' was not declared in this scope ``` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2951/cottonmouth-uses-max-unqualified-without-a -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed May 27 23:05:12 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Thu, 28 May 2026 04:05:12 +0000 Subject: [ET Trac] #2929: GRHayLET/IllinoisGRMHD convert_IllinoisGRMHD_to_HydroBase schedule compatibility with VolumeIntegrals_* Message-ID: #2929: GRHayLET/IllinoisGRMHD convert_IllinoisGRMHD_to_HydroBase schedule compatibility with VolumeIntegrals_* Reporter: Maxwell Rizzo Status: open Milestone: ET_2026_05 Version: ET_2025_05 Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Maxwell Rizzo): status: open (was resolved) Comment (by Maxwell Rizzo): GRHayLET/GRHayLHD has the same issue, on line [152](https://github.com/GRHayL/GRHayLET/blob/9b01f8839d44db2ba928d2af7d1bc6b5178d54eb/GRHayLHD/schedule.ccl#L152) of `schedule.ccl`, ``` schedule convert_GRHayLHD_to_HydroBase at CCTK_ANALYSIS before (compute_bi_b2_Poyn_fluxET convert_to_MHD_3velocity particle_tracerET VolumeIntegralGroup) after ML_BSSN_evolCalcGroup ``` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2929/grhaylet-illinoisgrmhd -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 28 10:08:18 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Thu, 28 May 2026 15:08:18 +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 Jordan Nicoules): PR is there: https://bitbucket.org/llamacode/llama/pull-requests/10 -- 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 May 28 10:35:31 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Thu, 28 May 2026 15:35:31 +0000 Subject: [ET Trac] #2952: GRHayLET/IllinoisGRMHD convert_*_to_*.c magnetic sector subleties Message-ID: #2952: GRHayLET/IllinoisGRMHD convert_*_to_*.c magnetic sector subleties Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn convert_HydroBase_to_IllinoisGRMHD.c 1. HydroBase Aphi is directly copied into IllinoisGRMHD phitilde on line [29](https://github.com/GRHayL/GRHayLET/blob/9b01f8839d44db2ba928d2af7d1bc6b5178d54eb/IllinoisGRMHD/src/convert_HydroBase_to_IllinoisGRMHD.c#L29). A comment in the interface says "# phitilde (=Phi*psi^6)", and another "sqrt{gamma} Phi", so I believe the direct copy is missing a factor of Psi^6 or sqrt(det gamma). It is also missing a `mag_factor` scaling of 1/4pi when compared to the Avec copying, I am not sure if it is correct without it or it should have it given `mag_factor`/`rescale_magnetics` is on by default. 2. IllinoisGRMHD Ax/Ay/Az are face centered staggered, Aphi is vertex centered. They are populated directly from HydroBase cell centered quantities. This is a bit subtle for Initial Data thorns to interface with properly, it is somewhat documented but could be a bit clearer. convert_IllinoisGRMHD_to_HydroBase.c 1. Only HydroBase Bvec is repopulated. HydroBase Avec and Aphi are not refilled (probably due to centering mismatch). This is probably fine as the magnetic field is the more interesting quantity for diagnostics, but it could be useful for debugging or consistency. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2952/grhaylet-illinoisgrmhd-convert_-_to_-c -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu May 28 11:21:42 2026 From: trac-noreply at einsteintoolkit.org (Lucas Timotheo Sanches) Date: Thu, 28 May 2026 16:21:42 +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: resolved Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Lucas Timotheo Sanches): status: resolved (was open) Comment (by Lucas Timotheo Sanches): [Merged to master](https://bitbucket.org/llamacode/llama/pull-requests/10) -- 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 Fri May 29 04:20:24 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Fri, 29 May 2026 09:20:24 +0000 Subject: [ET Trac] #2939: AHFinderDirect: range options for track_origin_source_x/y/z Message-ID: #2939: AHFinderDirect: range options for track_origin_source_x/y/z Reporter: Jordan Nicoules Status: open Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Jordan Nicoules): PR merged in https://bitbucket.org/einsteintoolkit/einsteinanalysis/commits/30d7c06d1defa768158d472db05aff81a93f4d05 Additional fix (missing `?`) in https://bitbucket.org/einsteintoolkit/einsteinanalysis/commits/f3598be741265848e17ce32de81e60187397bf1d -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2939/ahfinderdirect-range-options-for -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri May 29 04:20:37 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Fri, 29 May 2026 09:20:37 +0000 Subject: [ET Trac] #2939: AHFinderDirect: range options for track_origin_source_x/y/z Message-ID: #2939: AHFinderDirect: range options for track_origin_source_x/y/z Reporter: Jordan Nicoules Status: resolved Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Changes (by Jordan Nicoules): status: resolved (was open) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2939/ahfinderdirect-range-options-for -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri May 29 13:18:24 2026 From: trac-noreply at einsteintoolkit.org (Leonardo Rosa Werneck) Date: Fri, 29 May 2026 18:18:24 +0000 Subject: [ET Trac] #2952: GRHayLET/IllinoisGRMHD convert_*_to_*.c magnetic sector subleties Message-ID: #2952: GRHayLET/IllinoisGRMHD convert_*_to_*.c magnetic sector subleties Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Leonardo Rosa Werneck): Hi Maxwell! Thanks for pointing these out! * Regarding `phitilde = Aphi`, I agree that this is misleading. Although I don't see anything in the `HydroBase` documentation that states that `Aphi` is defined without the `sqrt{gamma}` factor in it, intuitively that's what I would expect. This has been likely not been a problem because most of our ID thorns set `Aphi` to zero initially. This can definitely be fixed. * Regarding the factor of `1/sqrt(4pi)`, I would point to the discussion surrounding Eqs. (A9) and (A10) of the [GRHayL paper](https://arxiv.org/pdf/2512.15846). Since this affects only the definition of the magnetic field itself, I think rescaling only `Avec` is correct, but let me know if you find a reasoning to also rescale `Aphi`. * Regarding `Ax`/`Ay`/`Az` being staggered, I don't know of a way to remedy this. Our initial data thorns (such as `Seed_Magnetic_Fields`) "borrow" `Avec` as auxiliary storage. Although one can argue this is incorrect and that they could initialize `Ax`/`Ay`/`Az` directly instead, doing that would make it difficult for users to utilize our initial data in their own evolution thorns. Our "solution" was to add a parameter to the ID thorns that allows users to initialize `Avec` with either staggered or vertex-centered data. We'd be happy to discuss alternatives, if you'd like to propose any. * Regarding repopulating `Avec`/`Aphi`, this can be added, but the usefulness is less clear to me. While having them in the `HydroBase -> GRHayLET` conversion enables users to more easily utilize our initial data thorns, having them in the `GRHayLET -> HydroBase` seems less useful/redundant, as users can output `Ax`/`Ay`/`Az`/`phitilde` instead of the `HydroBase` quantities. The centering mismatch also makes things a bit trickier, as you pointed out. That being said, we'd be happy to add the copy if folks think it would be useful. Let me know what you think. I'd be happy to create a PR to address issues we agree on. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2952/grhaylet-illinoisgrmhd-convert_-_to_-c -------------- next part -------------- An HTML attachment was scrubbed... URL: