Trac May 2026

trac@lists.einsteintoolkit.org

1 participants
105 discussions

#2952: GRHayLET/IllinoisGRMHD convert_*_to_*.c magnetic sector subleties
by Leonardo Rosa Werneck 29 May '26

29 May '26

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

1 0

#2939: AHFinderDirect: range options for track_origin_source_x/y/z
by Jordan Nicoules 29 May '26

29 May '26

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

1 0

#2939: AHFinderDirect: range options for track_origin_source_x/y/z
by Jordan Nicoules 29 May '26

29 May '26

#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/30d7c06d1def… Additional fix (missing `?`) in https://bitbucket.org/einsteintoolkit/einsteinanalysis/commits/f3598be74126… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2939/ahfinderdirect-ra…

1 0

#2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior
by Lucas Timotheo Sanches 28 May '26

28 May '26

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

1 0

#2952: GRHayLET/IllinoisGRMHD convert_*_to_*.c magnetic sector subleties
by Maxwell Rizzo 28 May '26

28 May '26

#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/9b01f8839d44db2ba928d2af7d1bc6b…. 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-illinois…

1 0

#2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior
by Jordan Nicoules 28 May '26

28 May '26

#2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior Reporter: Jordan Nicoules Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn 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-comp…

1 0

#2929: GRHayLET/IllinoisGRMHD convert_IllinoisGRMHD_to_HydroBase schedule compatibility with VolumeIntegrals_*
by Maxwell Rizzo 27 May '26

27 May '26

#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/9b01f8839d44db2ba928d2af7d1bc6… 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-illinois…

1 0

#2951: Cottonmouth uses `max()` unqualified without a using declaration
by Maxwell Rizzo 27 May '26

27 May '26

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

1 0

#2950: CarpetX/ADMBaseX: Missing ADMBase features (Conditional storage, evolution parameters)
by Maxwell Rizzo 26 May '26

26 May '26

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

1 0

#2944: CCE_Export Issues Ticket
by Roland Haas 26 May '26

26 May '26

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

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac May 2026