Trac April 2026

trac@lists.einsteintoolkit.org

1 participants
74 discussions

#2933: CarpetX's reduction.hxx is not self-contained
by Erik Schnetter 21 Apr '26

21 Apr '26

#2933: CarpetX's reduction.hxx is not self-contained Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: CarpetX Comment (by Erik Schnetter): You also need to declare your dependency on CarpetX in your configuration.ccl: `REQUIRES CarpetX`, I think. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2933/carpetxs-reductio…

1 0

#2933: CarpetX's reduction.hxx is not self-contained
by Roland Haas 21 Apr '26

21 Apr '26

#2933: CarpetX's reduction.hxx is not self-contained Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: CarpetX using just `USES INCLUDE HEADER reduction.hxx` in interface.ccl and then: ``` #include "reduction.hxx" ``` I get an error message: ``` /home/rhaas/postdoc/gr/cactus/ET_trunk/arrangements/CarpetX/CarpetX/src/reduction.hxx:24:22: error: ‘amrex’ does not name a type [-Wtemplate-body] 24 | using tuple_type = amrex::GpuTuple<T, T, T, T, T, T, T, T>; ``` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2933/carpetxs-reductio…

1 0

#2931: Claude AI edits to TwoPuncturesX
by Erik Schnetter 18 Apr '26

18 Apr '26

#2931: Claude AI edits to TwoPuncturesX Reporter: Steven R. Brandt Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Erik Schnetter): We clearly need to change our param.ccl syntax. It seems that mismatched parentheses are so uncommon that they are flagged as error. I wonder how many humans make the same mistake. Maybe we can allow square brackets instead of leaving out round parentheses? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2931/claude-ai-edits-t…

1 0

#2931: Claude AI edits to TwoPuncturesX
by Zach Etienne 18 Apr '26

18 Apr '26

#2931: Claude AI edits to TwoPuncturesX Reporter: Steven R. Brandt Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Zach Etienne): Here is the report from Codex. It did not have access to Steve's review: * Issue 1 - Severity critical - Description of the error The code advertises a 4-variable momentum-constraint solve via `solve_momentum_constraint=yes`, but the equation kernels still only populate `values[0]`. The extra three variables therefore have no equations, and the resulting nonlinear system is mathematically ill-posed. - Filename + line number(s) `TwoPuncturesX/src/TwoPunctures.cc:40-41, 302-306` `TwoPuncturesX/src/Equations.cc:158-181` - Original code snippet if (solve_momentum_constraint) nvar = 4; values[0] = U.d11[0] + U.d22[0] + U.d33[0] + 0.125 * BY_KKofxyz(x, y, z) / psi7 + 2.0 * Pi / psi2 / psi * rho_adm; values[0] = dU.d11[0] + dU.d22[0] + dU.d33[0] - 0.875 * BY_KKofxyz(x, y, z) / psi8 * dU.d0[0]; SpecCoef(n1, n2, n3, 0, v.d0, cf_v.d0); - Fixed code snippet. if (solve_momentum_constraint) { CCTK_ERROR("solve_momentum_constraint=yes is not implemented in TwoPuncturesX"); } /* Longer-term fix: implement and fill values[0..3] consistently, and generate/store spectral coefficients for all solved variables. */ - Confidence 99% * Issue 2 - Severity critical - Description of the error Turning on sources while leaving the default `rescale_sources=yes` triggers an unconditional `assert(0)`, so the source-enabled branch cannot run successfully. - Filename + line number(s) `TwoPuncturesX/src/TwoPunctures.cc:626-630` `TwoPuncturesX/param.ccl:162-164` - Original code snippet if (use_sources && rescale_sources) { assert(0); // TODO: Implement via critical region #pragma omp single Rescale_Sources(cctkGH, np, vcoordx, vcoordy, vcoordz, NULL, gxx, gyy, gzz, gxy, gxz, gyz); } - Fixed code snippet. if (use_sources && rescale_sources) { Rescale_Sources(cctkGH, np, vcoordx, vcoordy, vcoordz, NULL, gxx, gyy, gzz, gxy, gxz, gyz); } /* If thread-safety is not yet guaranteed, then the safe interim fix is to reject this configuration explicitly in ParamCheck instead of asserting. */ - Confidence 98% * Issue 3 - Severity high - Description of the error Four CCL parameter ranges have malformed syntax (`0.0:*)` instead of `(0.0:*)`), which can prevent correct parameter parsing. - Filename + line number(s) `TwoPuncturesX/param.ccl:100-118` - Original code snippet REAL par_m_plus "mass of the m+ puncture" STEERABLE = ALWAYS { 0.0:*) :: "" } 1.0 REAL par_m_minus "mass of the m- puncture" STEERABLE = ALWAYS { 0.0:*) :: "" } 1.0 REAL target_M_plus "target ADM mass for m+" { 0.0:*) :: "" } 0.5 REAL target_M_minus "target ADM mass for m-" { 0.0:*) :: "" } 0.5 - Fixed code snippet. REAL par_m_plus "mass of the m+ puncture" STEERABLE = ALWAYS { (0.0:*) :: "" } 1.0 REAL par_m_minus "mass of the m- puncture" STEERABLE = ALWAYS { (0.0:*) :: "" } 1.0 REAL target_M_plus "target ADM mass for m+" { (0.0:*) :: "" } 0.5 REAL target_M_minus "target ADM mass for m-" { (0.0:*) :: "" } 0.5 - Confidence 97% * Issue 4 - Severity high - Description of the error In the `r_minus < TP_Extend_Radius` branch of the antisymmetric/averaged lapse, the denominator uses the plus-puncture mass where it should use the minus-puncture mass. - Filename + line number(s) `TwoPuncturesX/src/TwoPunctures.cc:605-607` - Original code snippet if (r_minus < TP_Extend_Radius) { alp[ind] = ((1.0 - 0.5 * EXTEND(*mm, r_minus) - 0.5 * *mp / r_plus) / (1.0 + 0.5 * EXTEND(*mp, r_minus) + 0.5 * *mp / r_plus)); } - Fixed code snippet. if (r_minus < TP_Extend_Radius) { alp[ind] = ((1.0 - 0.5 * EXTEND(*mm, r_minus) - 0.5 * *mp / r_plus) / (1.0 + 0.5 * EXTEND(*mm, r_minus) + 0.5 * *mp / r_plus)); } - Confidence 96% * Issue 5 - Severity high - Description of the error The BiCGStab driver can exit because it exhausted `itmax` iterations, yet still fall through to the success return path because the failure check uses `ii > itmax` instead of `ii >= itmax`. - Filename + line number(s) `TwoPuncturesX/src/Newton.cc:330-435` - Original code snippet for (ii = 0; ii < itmax; ii++) { ... } /* iteration failed */ if (ii > itmax) return -1; - Fixed code snippet. for (ii = 0; ii < itmax; ii++) { ... } /* iteration failed */ if (ii >= itmax && *normres > tol) return -1; - Confidence 95% * Issue 6 - Severity medium - Description of the error The initial-guess debug-output path calls `rx3_To_xyz()` with a stale `i3D` index instead of the current `indx`, which can corrupt the diagnostic coordinates written to `initial.dat`. - Filename + line number(s) `TwoPuncturesX/src/TwoPunctures.cc:101-103` - Original code snippet C_To_c(nvar, X, R, &(s_x[indx]), &r, U); rx3_To_xyz(nvar, s_x[i3D], r, phi, &(s_y[indx]), &(s_z[indx]), U); - Fixed code snippet. C_To_c(nvar, X, R, &(s_x[indx]), &r, U); rx3_To_xyz(nvar, s_x[indx], r, phi, &(s_y[indx]), &(s_z[indx]), U); - Confidence 92% ==== I then gave it Steve's list and asked whether there was any overlap with what it found and Steve's list, and to identify any false positives. Here's what it said: Only **item 5** looks like a likely false positive to me. The others are real findings, though item 6 is phrased a bit more absolutely than I’d prefer. 1. **Stale `i3D` in debug output** Not a false positive. This is real. It is also a **duplicate** of my debug-indexing finding, with one useful addition: you correctly caught **two occurrences**, at lines around `103` and `144`. My report only called out the first site, so this is a duplicate plus an extra instance of the same bug. 2. **Wrong mass in antisymmetric lapse denominator** Not a false positive. This is real. It is a **duplicate** of my lapse-denominator finding. 3. **Syntax errors in `param.ccl`** Not a false positive. This is real. It is a **duplicate** of my `param.ccl` syntax finding. 4. **Off-by-one in `bicgstab` failure check** Not a false positive. This is real. It is a **duplicate** of my `ii > itmax` / `ii >= itmax` finding. 5. **`BY_KKofxyz` missing epsilon regularization** This is the one I would treat as a **false positive**, or at least not established strongly enough to call a confirmed bug. Why: - `BY_KKofxyz()` is used in the **spectral solve** on collocation points. - In this formulation, the punctures sit at the **boundary** of the compactified domain, not at interior collocation points. - The collocation points are generated from `A = -cos(pi/2 * (2i+1)/n1)` and similarly for `B`, so they do not land exactly on the puncture location. - That means the unsmoothed `1/r` behavior in `BY_KKofxyz()` is not automatically a runtime singularity in the Newton solve. So the claim “the nonlinear equation and Jacobian can blow up during solving if any collocation point lands at the puncture” is not supported by the actual collocation layout. It is still fair to note that `BY_KKofxyz()` and `BY_Aijofxyz()` are inconsistent in their regularization choices, but that is weaker than a confirmed bug. It is **not a duplicate** of anything I identified. 6. **`use_sources + rescale_sources` hits `assert(0)`** Not a false positive, but the wording is slightly too absolute. Why: - In a normal assert-enabled build, this is plainly a real bug/unimplemented feature trap. - Since `rescale_sources` defaults to `"yes"`, `use_sources = yes` does indeed walk straight into that branch unless the user overrides it. - The only nuance is that `assert(0)` may disappear in a release build compiled with `NDEBUG`, so “will always abort” is a bit too strong as a universal statement. Still, as a thorn-quality issue this is absolutely valid. It is a **duplicate** of my `assert(0)` / `rescale_sources` finding. **Bottom line** - **Likely false positive:** `#5` - **Real duplicates of my findings:** `#2`, `#3`, `#4`, `#6` - **Real partial duplicate of my findings:** `#1` - I had the same bug, but not the second occurrence at line `144` - **New and likely incorrect as a confirmed bug:** `#5` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2931/claude-ai-edits-t…

1 0

#2931: Claude AI edits to TwoPuncturesX
by Erik Schnetter 18 Apr '26

18 Apr '26

#2931: Claude AI edits to TwoPuncturesX Reporter: Steven R. Brandt Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Erik Schnetter): Didn't you miss a few items? You didn't correct line 144, and you didn't put in a correction for 5 either (I think you shouldn't). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2931/claude-ai-edits-t…

1 0

#2931: Claude AI edits to TwoPuncturesX
by Steven R. Brandt 17 Apr '26

17 Apr '26

#2931: Claude AI edits to TwoPuncturesX Reporter: Steven R. Brandt Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Steven R. Brandt): I put the correction for 5 in, but I can take it out. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2931/claude-ai-edits-t…

1 0

#2931: Claude AI edits to TwoPuncturesX
by Steven R. Brandt 17 Apr '26

17 Apr '26

#2931: Claude AI edits to TwoPuncturesX Reporter: Steven R. Brandt Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Steven R. Brandt): https://github.com/EinsteinToolkit/SpacetimeX/pull/64 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2931/claude-ai-edits-t…

1 0

#2173: Test "Poisson equation" example
by Bing-Jyun Tsao 17 Apr '26

17 Apr '26

#2173: Test "Poisson equation" example Reporter: Roland Haas Status: open Milestone: ET_2026_05 Version: development version Type: task Priority: major Component: EinsteinToolkit website Comment (by Bing-Jyun Tsao): Poisson gallery example updated for 2026_05 release. Previously Steve ran with 8 CPUs and finished the run in 10 minutes. I tried to reproduce the result with --procs 8 --ppn 8 on a local workstation but got a slightly shifted error plot, while if I ran with just --procs 1 --ppn 1 I got the identical plot as the 2025 version, so I chose to upload the latter one. The links on the website are updated but the link to the thornlist should be verified after the einsteintoolkit.th from the new branch is uploaded. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2173/test-poisson-equa…

1 0

#2932: Kuibit: detecting 0D and 1D files generated during Llama runs
by Jordan Nicoules 17 Apr '26

17 Apr '26

#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 See issue created on Kuibit's repository: https://github.com/Sbozzolo/kuibit/issues/47 ### TLDR: Files like `phi1.0.x.h5` or `scalarbase-phi.0..asc` are currently not detected because of the ".0" that comes with multipatch runs. 2D data files are, though. The issue gives a MWE and fix suggestions. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2932/kuibit-detecting-…

1 0

#2931: Claude AI edits to TwoPuncturesX
by Erik Schnetter 16 Apr '26

16 Apr '26

#2931: Claude AI edits to TwoPuncturesX Reporter: Steven R. Brandt Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Erik Schnetter): Most of the reported problems are indeed problems that need correcting. "3. Syntax errors in `param.ccl`" is wrong; this is not a syntax error. "5. `BY_KKofxyz` missing epsilon regularization — `Equations.cc:32–37`" is probably also not an error; the source comment explicitly states that the result can be singular. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2931/claude-ai-edits-t…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac April 2026