From trac-noreply at einsteintoolkit.org Wed Apr 1 09:55:56 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Wed, 01 Apr 2026 14:55:56 +0000 Subject: [ET Trac] #2927: gcc-version-dependent error: Range error setting parameter Message-ID: #2927: gcc-version-dependent error: Range error setting parameter Reporter: Jordan Nicoules Status: new Milestone: Version: Type: bug Priority: major Component: Cactus For reference, thread on the mailing list: https://lists.einsteintoolkit.org/pipermail/users/2026-March/009901.html # TLDR # With certain versions of gcc, having a (real) parameter defined with a range only consisting of ``*`` causes a range error at the start of the simulation. # Description # With certain versions of gcc (13.3.0, 14.3.0), having a real parameter defined with a range only consisting of ``*`` causes a range error at the start of the simulation, right after thorn activation: ``` WARNING[L2,P0] (Cactus): ParameterSetReal: Unable to set real 'Coordinates::h_radial_1' = '0.40000000000000002' not in any active range WARNING[L1,P0] (Cactus): Major error in parameter file '/home/jnicoules/Work/ET_test/Simus/parfiles/Gallery/Kerr-Schild_Multipole_stretch.par' line 46: Range error setting parameter 'Coordinates::h_radial_1' to '0.40000000000000002' WARNING level 0 from host cnx001.deucalion.macc.fccn.pt process 0 in thorn Cactus, file /projects/F202407872CPCAA2/jnicoules/ET_test/Cactus/configs/ET_test__x86__GCC-13.3.0/build/Cactus/main/ProcessParameterDatabase.c:201: -> CCTKi_SetParameterSetMask: 1 major error in parameter file ``` The issue was encountered with a specific parameter, ``Coordinates::h_radial_1``, from the ``llama`` repo. I didn't experiment with other parameters from different thorns. Most of the experimentation was performed on x86 nodes of the Deucalion cluster (https://docs.macc.fccn.pt/deucalion/). Three different versions of gcc and available related modules were tested: 12.3.0, 13.3.0, 14.3.0. # Minimal (non)working example # The issue can be seen with the attached parameter file, based on the Multipatch wave equation Gallery example, tweaked to include parameter ``Coordinates::h_radial_1``. The used ET version for the MWE is 2025-05 and the thornlist is a shaved off version of the one on the ET website (https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2025_05/einsteintoolkit.th), to ease configuration and compilation. The outputs are attached, for each of the three versions mentioned above. Additionally, it contains the output for a configuration using GCC-13.3.0, but changing, in ``Cactus/repos/llama/Coordinates/param.ccl``, ``` real h_radial_1 "Intended radial resolution of the first stretched domain" { * :: "negative turns off stretching" } -1 ``` by ``` real h_radial_1 "Intended radial resolution of the first stretched domain" { *:* :: "negative turns off stretching" } -1 ``` which is enough to have the simulation work properly. # Other notes # As mentioned in https://lists.einsteintoolkit.org/pipermail/users/2026-March/009901.html, gcc 15 might work just well. Testing on my other setups (workstation and other clusters), where I have various older versions of gcc, the issue did not occur. I'm not attaching the respective files here, as the MWE shows both working and non-working situations. # Attachments # ``` range_error_MWE/ |__ einstein_toolkit.th # Thornlist |__ Kerr-Schild_Multipole_stretch.par # Parameter file |__ Kerr-Schild_Multipole_stretch/ # Contains the output for the various cases, without .h5 files for size reasons |__ README |__ output-*/ |__ GCC-*/ # contains compilation information in each case |__ *.cfg # option file |__ config_*.log # output of make config |__ make_*.log # output of make |__ make.config.defn # file found in Cactus/configs/*/config-data ``` attachment: range_error_MWE.zip (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2927/attachments/range_error_MWE.zip) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2927/gcc-version-dependent-error-range-error -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Apr 1 10:50:13 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Wed, 01 Apr 2026 15:50:13 +0000 Subject: [ET Trac] =?utf-8?q?=232923=3A_ADIOS2_compilation_fails_due_to_u?= =?utf-8?b?bmtub3duIHR5cGUgbmFtZSDigJhJTlQ0PSAg4oCZ?= Message-ID: #2923: ADIOS2 compilation fails due to unknown type name ?INT4? Reporter: Cheng-Hsin Cheng Status: new Milestone: Version: ET_2025_05 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Steven R. Brandt): OK, my mistake. I didn't read this carefully enough. This is an ADIOS2 issue. Not sure what to do about that. Here's what the Grok clanker has to say: https://grok.com/share/c2hhcmQtMw_c753302c-29b1-4ccd-a483-6ca95174b4ad -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2923/adios2-compilation-fails-due-to-unknown -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Apr 1 11:51:52 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 01 Apr 2026 16:51:52 +0000 Subject: [ET Trac] #1775: Add Boost to ET Message-ID: #1775: Add Boost to ET Reporter: Erik Schnetter Status: new Milestone: ET_2026_05 Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): It is possible to interact with make's parallel build system (somewhat): https://www.gnu.org/software/make/manual/html_node/POSIX-Jobserver.html (note that Cactus requires GNU make). ``` #!/bin/bash # fail on errors, error on unset variable reference set -u -e # verobse output? if [ ${VERBOSE-no} = yes ]; then set -x fi # handle -n option to make (do nothing), since make thinks we are a sub-make set -- $MAKEFLAGS if [[ ${#*} -ge 1 ]] && [[ $1 = *n* ]]; then # -n flag passed to make, do nothing exit 0 fi # parse remaining make arguments MAX_JOBS=1 JOBSERVER_AUTH= for o in "$@"; do case $o in ( --jobserver-auth=* ) JOBSERVER_AUTH=${o#--jobserver-auth=} ;; ( -j* ) MAX_JOBS=${o#-j*} ;; ( -- ) break ;; esac done # functions to get some job tokens from make function return_tokens() { local JOBSERVER_FILE= if [ -n "$JOBSERVER_AUTH" ] && [ -n "$JOBSERVER_TOKENS" ]; then case $JOBSERVER_AUTH in ( fifo:* ) JOBSERVER_FILE=${JOBSERVER_AUTH#fifo:} ;; ( *,* ) # /dev/fd/ emulated by bash (if not by the OS) JOBSERVER_FILE=/dev/fd/${JOBSERVER_AUTH#*,} # read handle of pipe ;; esac if [ -n "$JOBSERVER_FILE" ]; then echo -n $JOBSERVER_TOKENS >$JOBSERVER_FILE fi fi } function maybe_get_tokens() { local JOBSERVER_FILE= if [ -n "$JOBSERVER_AUTH" ]; then case $JOBSERVER_AUTH in ( fifo:* ) JOBSERVER_FILE=${JOBSERVER_AUTH#fifo:} ;; ( *,* ) # /dev/fd/ emulated by bash (if not by the OS) JOBSERVER_FILE=/dev/fd/${JOBSERVER_AUTH#%,*} # write handle of pipe ;; esac if [ -n "$JOBSERVER_FILE" ]; then set +e # read sets error code on timeout, which is not an error read -r -N $MAX_JOBS -t 5 JOBSERVER_TOKENS <$JOBSERVER_FILE set -e fi fi } if [ -n "$MAX_JOBS" ]; then JOBSERVER_TOKENS= # wait for 5 seconds to get up MAX_JOBS tokens (or 1024 if MAX_JOBS is empty) trap return_tokens EXIT maybe_get_tokens # one job is for "free" since it represents this process JOBS_OPT=-j$(( ${#JOBSERVER_TOKENS} + 1 )) else # no maximum JOBS_OPT=-j fi echo $JOBS_OPT tokens: ${JOBSERVER_TOKENS:-} ``` when declaring the script above a sub-make to make using: ``` all: + at ./bjam-test.sh ``` which then produces: ``` haengie2: ~/.../Boost/dist$ make -j5 -f GNUMakefile all -j5 tokens: ++++ haengie2: ~/.../Boost/dist$ make -j1 -f GNUMakefile all -j1 tokens: haengie2: ~/.../Boost/dist$ make -j -f GNUMakefile all -j tokens: haengie2: ~/.../Boost/dist$ make -f GNUMakefile all -j1 tokens: ``` ie constructs a `-j` option for bjam reflection (a subset of) the jobs available to make. As for tar file size, the best I can do right now is to remove Boost examples, docs, tests etc. then re-compress with `gzip`'s `--rsyncable` option for a ~30MB file size which git can hopefully diff: ``` #!/bin/bash # this script removes "extra" files from Boost distribution archive to try and # reduce its size. It creates a new zipped archive that may be diff-able for git. if [ ${#@} -ne 1 ]; then echo >&2 "usage: $0 " exit 1 fi set -e FN="$1" TEMPDIR=`mktemp -d` function cleanup() { rm -r $TEMPDIR } trap cleanup EXIT tar -xf "$FN" -C $TEMPDIR find $TEMPDIR -depth '(' -name examples -or -name doc -or -name test ')' -print0 | xargs --null rm -r # use gzip's --rsyncable option in hopes that this will let git diff versions # of the tar archive ( cd $TEMPDIR ; tar -c * ) | gzip --rsyncable >${FN%.tar*}-stripped.tar.gz ``` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Apr 6 15:07:59 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Mon, 06 Apr 2026 20:07:59 +0000 Subject: [ET Trac] #2928: New Simfactory Option Message-ID: #2928: New Simfactory Option Reporter: Steven R. Brandt Status: new Milestone: Version: Type: enhancement Priority: major Component: SimFactory The options to simfactory reflect usage on older hardware. We used to be more concerned with how many cores we wanted to use and how many to allocate to each process. Now we are often more concerned with how many gpus we want. It would be much more convenient to say something like: ``` ./simfactory/bin/sim create-run --gpus=4 --queue=gpu2 ... ``` Than to figure out that nodes in the gpu2 queue we have 64 cores and 2 gpus per node, and thus the way to invoke simfactory is as follows: ``` ./simfactory/bin/sim create-run --procs=128 --num-threads=32 ... ``` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2928/new-simfactory-option -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Apr 6 16:33:50 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Mon, 06 Apr 2026 21:33:50 +0000 Subject: [ET Trac] #1775: Add Boost to ET Message-ID: #1775: Add Boost to ET Reporter: Erik Schnetter Status: new Milestone: ET_2026_05 Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): @{557058:f7fd5133-6eee-4385-a5e5-3e03342a0b24} here's a repository: https://github.com/EinsteinToolkit/ExternalLibraries-Boost -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Apr 6 16:37:03 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Mon, 06 Apr 2026 21:37:03 +0000 Subject: [ET Trac] #1775: Add Boost to ET Message-ID: #1775: Add Boost to ET Reporter: Erik Schnetter Status: new Milestone: ET_2026_05 Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): I note that while this builds a whole lot of libraries, it only, matching David's old library, links in `system` and `filesystem`. So we could likely speed up the build process by passing `--with-system` and `--with-filesystem` to `b2`. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Apr 7 13:46:12 2026 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Tue, 07 Apr 2026 18:46:12 +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): ET_BHaHAHA (the Einstein Toolkit implementation of BHaHAHA) can be found here: https://bitbucket.org/einsteintoolkit/einsteinanalysis/src/master/ET_BHaHAHA/ -- 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 Tue Apr 7 15:08:43 2026 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Tue, 07 Apr 2026 20:08:43 +0000 Subject: [ET Trac] #2916: Include Cottonmouth Message-ID: #2916: Include Cottonmouth Reporter: Beyhan Karaka? Status: open Milestone: ET_2026_05 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Zach Etienne): The Cottonmouth thorn can be found in this repo: https://github.com/EinsteinToolkit/Cottonmouth The code that generates Cottonmouth (EinsteinEngine) can be found in this repo: git clone https://github.com/max-morris/EinsteinEngine.git -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2916/include-cottonmouth -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Apr 7 15:57:02 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Tue, 07 Apr 2026 20:57:02 +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 In GRHayLET/IllinoisGRMHD/schedule.ccl, starting at line 220, it appears that the Convert_to_Hydrobase is scheduled before the wrong thorn VolumeIntegral_* schedule group. ``` if(Convert_to_HydroBase_every) { schedule convert_IllinoisGRMHD_to_HydroBase at CCTK_ANALYSIS before (compute_bi_b2_Poyn_fluxET convert_to_MHD_3velocity particle_tracerET VolumeIntegralGroup) after ML_BSSN_evolCalcGroup { LANG: C OPTIONS: GLOBAL-EARLY,LOOP-LOCAL READS: ADMBase::metric, ADMBase::lapse, ADMBase::shift, grmhd_velocities, grmhd_B_center WRITES: HydroBase::vel(everywhere), HydroBase::w_lorentz(everywhere), HydroBase::Bvec(everywhere) } "Convert IllinoisGRMHD-native variables to HydroBase" } ``` VolumeIntegralGroup, appearing above in the ```before``` list, is the schedule group for thorn VolumeIntegrals_vacuum which does not inherit HydroBase. VI_GRMHD_VolumeIntegralGroup is the schedule group for thorn VolumeIntegrals_GRMHD which does inherit and use HydroBase. The above schedule does not ensure conversion to HydroBase occurs before VolumeIntegrals_GRMHD runs its main scheduled group. -- 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 Apr 7 16:11:16 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 07 Apr 2026 21:11:16 +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 Changes (by Roland Haas): responsible: [] (was ) assignee: Zach Etienne (was ) -- 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 Apr 9 09:47:14 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Thu, 09 Apr 2026 14:47:14 +0000 Subject: [ET Trac] #2909: Remove TAGS from interface.ccl Message-ID: #2909: Remove TAGS from interface.ccl Reporter: Steven R. Brandt Status: open Milestone: ET_2025_05 Version: ET_2025_05 Type: enhancement Priority: major Component: Cactus Comment (by Steven R. Brandt): Discussed on today's ET call. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2909/remove-tags-from-interfaceccl -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Apr 9 09:53:31 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Thu, 09 Apr 2026 14:53:31 +0000 Subject: [ET Trac] =?utf-8?q?=232923=3A_ADIOS2_compilation_fails_due_to_u?= =?utf-8?b?bmtub3duIHR5cGUgbmFtZSDigJhJTlQ0PSAg4oCZ?= Message-ID: #2923: ADIOS2 compilation fails due to unknown type name ?INT4? Reporter: Cheng-Hsin Cheng Status: new Milestone: Version: ET_2025_05 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Steven R. Brandt): Discussed on the ET call. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2923/adios2-compilation-fails-due-to-unknown -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Apr 9 11:28:45 2026 From: trac-noreply at einsteintoolkit.org (Leonardo Rosa Werneck) Date: Thu, 09 Apr 2026 16:28:45 +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): Thanks for pointing this out! I created [PR #15](https://github.com/GRHayL/GRHayLET/pull/15) to address this issue. Will post an update once it's reviewed and merged. -- 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 Apr 9 11:42:35 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 09 Apr 2026 16:42:35 +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): As a suggestion: there is a Cactus parameter ``` Cactus::schedule_sort_mode = "descending" ``` also "non", the default, or "ascending". Which can be used to willfully change the ordering of scheduled functions without any explicit `AFTER` or `BEFORE` relation. A correctly written `schedule.ccl` should be unaffected. While one that relies on accidental order would fail. -- 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 Apr 9 18:48:59 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Thu, 09 Apr 2026 23:48:59 +0000 Subject: [ET Trac] #2910: CarpetX: Add option to exclude boundaries in 1D tsv output Message-ID: #2910: CarpetX: Add option to exclude boundaries in 1D tsv output Reporter: Lucas Timotheo Sanches Status: resolved Milestone: Version: Type: enhancement Priority: trivial Component: Changes (by Steven R. Brandt): status: resolved (was open) Comment (by Steven R. Brandt): Applied. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2910/carpetx-add-option-to-exclude-boundaries -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Apr 10 05:10:16 2026 From: trac-noreply at einsteintoolkit.org (Marco Brito) Date: Fri, 10 Apr 2026 10:10:16 +0000 Subject: [ET Trac] #2930: Bug in QuasiLocalMeasures Message-ID: #2930: Bug in QuasiLocalMeasures Reporter: Marco Brito Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn I found a bug in the QuasiLocalMeasures thorn, in the computation of the ADM momentum. In the source code file qlm_analyse.F90, in line 361 there is a plus sign instead of a minus sign, contradicting the ADM momentum formula: P^i_{ADM} = \frac{1}{8\pi}\lim_{r\to\infty} \oint_S (K^i_j - \delta^i_j K)dS^j [1] As expected for slices where K \neq 0 one was getting a wrong result. The correction is easy, just replace the plus sign by a minus sign. You can find the corrected file in attachment. [1] M. Alcubierre, Introduction to 3+1 Numerical Relativity, International Series of Monographs on Physics (Oxford University Press, Oxford, 2008). attachment: qlm_analyse.F90 (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2930/attachments/qlm_analyse.F90) -- 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 Fri Apr 10 05:21:37 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Fri, 10 Apr 2026 10:21:37 +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: See ticket: https://bitbucket.org/einsteintoolkit/tickets/issues/2912/inconsistent-computation-of-the-volume **IMPORTANT WARNING: THIS IS A BEHAVIOR CHANGE AND MAY BREAK BACKWARD COMPATIBILITY FOR NON-THORNBURG04/13 RUNS!** # Modifications to implement: # ## Coordinates/src/inverse_jacobian.F90 ## See attached file. ### WARNING ### This was tested only on Thornburg04 and Thornburg04nc. Thornburg13 works like Thornburg04 and redefines its volume form, so it should be fine. For other patch systems, I'm not sure if this is safe for each subpatch, but I think that shouldn't be more wrong than the current implementation. ### NOTE ### Feel free to change the comments I made, and/or adapt the existing TODO in comment (lines 59-61) if it's relevant. ## Coordinates/src/thornburg04.cc Fix typo in comment line 1439: `// set volume form to determinant of Jacobian` ## Coordinates/src/thornburg13.cc Fix typo in comment line 2237: `// set volume form to determinant of Jacobian` attachment: inverse_jacobian.F90 (https://api.bitbucket.org/2.0/repositories/llamacode/llama/issues/6/attachments/inverse_jacobian.F90) -- 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 Fri Apr 10 05:23:44 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Fri, 10 Apr 2026 10:23:44 +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): Llama ticket submitted: https://bitbucket.org/llamacode/llama/issues/6/inconsistent-computation-of-the-volume (due to the impossibility of forking to own workspace https://community.atlassian.com/forums/Bitbucket-articles/Deprecation-of-Forked-Repositories-Outside-the-Parent-Workspace/ba-p/3155743) -- 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 Apr 10 08:54:14 2026 From: trac-noreply at einsteintoolkit.org (Peter Diener) Date: Fri, 10 Apr 2026 13:54:14 +0000 Subject: [ET Trac] #1775: Add Boost to ET Message-ID: #1775: Add Boost to ET Reporter: Erik Schnetter Status: new Milestone: ET_2026_05 Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Peter Diener): When trying the thorn in the repository, I got this output: Boost: Configuring... Building B2 engine.. ### ### ### Using 'gcc' toolset. ### ### g++ (GCC) 13.2.0 Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ### ### > g++ -x c++ -std=c++11 -O2 -s -DNDEBUG builtins.cpp class.cpp command.cpp compile.cpp constants.cpp cwd.cpp debug.cpp debugger.cpp execcmd.cpp execnt.cpp execunix.cpp filesys.cpp filent.cpp fileunix.cpp frames.cpp function.cpp glob.cpp hash.cpp hcache.cpp hdrmacro.cpp headers.cpp jam_strings.cpp jam.cpp jamgram.cpp lists.cpp make.cpp make1.cpp md5.cpp mem.cpp modules.cpp native.cpp object.cpp option.cpp output.cpp parse.cpp pathnt.cpp pathsys.cpp pathunix.cpp regexp.cpp rules.cpp scan.cpp search.cpp startup.cpp subst.cpp sysinfo.cpp timestamp.cpp variable.cpp w32_getreg.cpp modules/order.cpp modules/path.cpp modules/property-set.cpp modules/regex.cpp modules/sequence.cpp modules/set.cpp -o b2 tools/build/src/engine/b2 Detecting Python version... 2.7 Detecting Python root... /usr Unicode/ICU support for Boost.Regex?... /usr Generating B2 configuration in project-config.jam for gcc... Bootstrapping is done. To build, run: ./b2 To generate header files, run: ./b2 headers The configuration generated uses gcc to build by default. If that is unintended either use the --with-toolset option or adjust configuration, by editing 'project-config.jam'. Further information: - Command line help: ./b2 --help - Getting started guide: http://www.boost.org/more/getting_started/unix-variants.html - B2 documentation: http://www.boost.org/build/ Boost: Building... Invalid value for the '-j' option. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Apr 10 10:15:08 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 10 Apr 2026 15:15:08 +0000 Subject: [ET Trac] #1775: Add Boost to ET Message-ID: #1775: Add Boost to ET Reporter: Erik Schnetter Status: new Milestone: ET_2026_05 Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): hmm, would be nice if it told me what that invalid value was. Could you re-run with `export VERBOSE=yes`, please? That should show you the shell command that the build script tries to execute and thus the bad option value as well. it really only ever should be 1. a number (incl. 1), 2. nothing (if make was called with `-j` without any options). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Apr 10 10:23:11 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 10 Apr 2026 15:23:11 +0000 Subject: [ET Trac] #1775: Add Boost to ET Message-ID: #1775: Add Boost to ET Reporter: Erik Schnetter Status: new Milestone: ET_2026_05 Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): oh, it does not like `-j` alone. Grr. Apparently I coded for this (there's special code) but never tested it. Fixed. Also removed the check for a `system` linker library. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Apr 10 10:39:45 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 10 Apr 2026 15:39:45 +0000 Subject: [ET Trac] #1775: Add Boost to ET Message-ID: #1775: Add Boost to ET Reporter: Erik Schnetter Status: new Milestone: ET_2026_05 Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): In the ET call we collected some boost sub-libraries that are used in the ET: * system and filesystem (since in David's original code) * math (or so) by CarpetX's Algo library * ptree (FUKA), Python (FUKA) -- won't provide this since it opens up a can of worms trying to build for Python * optional, format, math, odeint, (RrPrimAnd, just says "Boost", but this is what is actually required to compile it) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Apr 10 11:10:18 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 10 Apr 2026 16:10:18 +0000 Subject: [ET Trac] #1775: Add Boost to ET Message-ID: #1775: Add Boost to ET Reporter: Erik Schnetter Status: new Milestone: ET_2026_05 Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): Note that my Debian box (and self-compiled Boost) do have a libboost_system: ``` /usr/lib/x86_64-linux-gnu/libboost_system.a libboost-system1.83-dev [amd64], libboost-system1.88-dev [amd64] /usr/lib/x86_64-linux-gnu/libboost_system.so libboost-system1.83-dev [amd64], libboost-system1.88-dev [amd64] ``` where did you encounter that file not being present? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Apr 10 11:18:45 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 10 Apr 2026 16:18:45 +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): Unless object I will apply this after April 24th -- 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 Fri Apr 10 11:18:56 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 10 Apr 2026 16:18:56 +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): Is there a ticket for this? -- 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 Fri Apr 10 11:19:57 2026 From: trac-noreply at einsteintoolkit.org (Peter Diener) Date: Fri, 10 Apr 2026 16:19:57 +0000 Subject: [ET Trac] #1775: Add Boost to ET Message-ID: #1775: Add Boost to ET Reporter: Erik Schnetter Status: new Milestone: ET_2026_05 Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Peter Diener): The compile of boost started and finished on Sunrise after your fix. I encountered the missing libboost_system on Sunrise. I have my own compiled boost version 1.89 there. When I removed the check for the library I was able to compile and link the current development version of Cactus. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Apr 10 11:39:10 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 10 Apr 2026 16:39:10 +0000 Subject: [ET Trac] #1775: Add Boost to ET Message-ID: #1775: Add Boost to ET Reporter: Erik Schnetter Status: new Milestone: ET_2026_05 Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): Great. Thanks of the feedback. if it is a self-build one that is lacking `libboost_system` could this have been caused by options passed to `b2` while building? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Apr 10 11:41:10 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 10 Apr 2026 16:41:10 +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): I note that Formaline contains the same workaround and the same fix is proposed in https://bitbucket.org/cactuscode/cactusutils/pull-requests/45 -- 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 Fri Apr 10 11:41:28 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 10 Apr 2026 16:41:28 +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): Please review -- 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 Fri Apr 10 11:57:46 2026 From: trac-noreply at einsteintoolkit.org (Peter Diener) Date: Fri, 10 Apr 2026 16:57:46 +0000 Subject: [ET Trac] #1775: Add Boost to ET Message-ID: #1775: Add Boost to ET Reporter: Erik Schnetter Status: new Milestone: ET_2026_05 Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Peter Diener): No. According to what I was able to find out Boost version 1.89 was the first version they didn't build the stub for backward compability. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Apr 10 14:23:08 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 10 Apr 2026 19:23:08 +0000 Subject: [ET Trac] #1775: Add Boost to ET Message-ID: #1775: Add Boost to ET Reporter: Erik Schnetter Status: new Milestone: ET_2026_05 Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): ah, that's why. Version 1.89 (I had misremembered 1.69). Should not be able to use that one anyway (at least Steve says versions newer than 1.84 fail). My self-compiled one was the one in Externallibraries which is 1.84. And indeed the file is last present in Debian's Boost 1.88 package. Since we cannot (though apparently things worked of for you) use that new version yet, the extra check does no harm. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Apr 14 09:18:38 2026 From: trac-noreply at einsteintoolkit.org (Beyhan Karakaş) Date: Tue, 14 Apr 2026 14:18:38 +0000 Subject: [ET Trac] #2919: Include black hole-neutron star merger gallery example Message-ID: #2919: Include black hole-neutron star merger gallery example Reporter: Beyhan Karaka? Status: open Milestone: ET_2026_05 Version: development version Type: enhancement Priority: major Component: EinsteinToolkit website Comment (by Beyhan Karaka?): Can we close the ticket as this has already been included? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2919/include-black-hole-neutron-star-merger -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Apr 14 09:36:48 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 14 Apr 2026 14:36:48 +0000 Subject: [ET Trac] #2919: Include black hole-neutron star merger gallery example Message-ID: #2919: Include black hole-neutron star merger gallery example Reporter: Beyhan Karaka? Status: open Milestone: ET_2026_05 Version: development version Type: enhancement Priority: major Component: EinsteinToolkit website Comment (by Roland Haas): usually I kept them around until after the release. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2919/include-black-hole-neutron-star-merger -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Apr 16 10:53:14 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Thu, 16 Apr 2026 15:53:14 +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: Version: Type: bug Priority: major Component: I ran Claude AI on the TwoPuncturesX thorn and it found errors which I believe to be legitimate. I am attaching Claude's report along with a PR implementing what it asks for. attachment: TwoPuncturesX_bug_report.md (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2931/attachments/TwoPuncturesX_bug_report.md) -- 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 Apr 16 11:24:52 2026 From: trac-noreply at einsteintoolkit.org (Erik Schnetter) Date: Thu, 16 Apr 2026 16:24:52 +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: 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-to-twopuncturesx -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Apr 17 08:27:22 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Fri, 17 Apr 2026 13:27:22 +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 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-0d-and-1d-files-generated -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Apr 17 15:58:09 2026 From: trac-noreply at einsteintoolkit.org (Bing-Jyun Tsao) Date: Fri, 17 Apr 2026 20:58:09 +0000 Subject: [ET Trac] #2173: Test "Poisson equation" example Message-ID: #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-equation-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Apr 17 21:50:15 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Sat, 18 Apr 2026 02:50:15 +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: 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-to-twopuncturesx -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Apr 17 21:50:44 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Sat, 18 Apr 2026 02:50:44 +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: 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-to-twopuncturesx -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Sat Apr 18 11:25:44 2026 From: trac-noreply at einsteintoolkit.org (Erik Schnetter) Date: Sat, 18 Apr 2026 16:25:44 +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: 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-to-twopuncturesx -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Sat Apr 18 11:34:03 2026 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Sat, 18 Apr 2026 16:34:03 +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: 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-to-twopuncturesx -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Sat Apr 18 11:41:57 2026 From: trac-noreply at einsteintoolkit.org (Erik Schnetter) Date: Sat, 18 Apr 2026 16:41:57 +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: 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-to-twopuncturesx -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Apr 21 11:41:50 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 21 Apr 2026 16:41:50 +0000 Subject: [ET Trac] #2933: CarpetX's reduction.hxx is not self-contained Message-ID: #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; ``` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2933/carpetxs-reductionhxx-is-not-self -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Apr 21 11:45:46 2026 From: trac-noreply at einsteintoolkit.org (Erik Schnetter) Date: Tue, 21 Apr 2026 16:45:46 +0000 Subject: [ET Trac] #2933: CarpetX's reduction.hxx is not self-contained Message-ID: #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-reductionhxx-is-not-self -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Apr 21 11:47:39 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 21 Apr 2026 16:47:39 +0000 Subject: [ET Trac] #2933: CarpetX's reduction.hxx is not self-contained Message-ID: #2933: CarpetX's reduction.hxx is not self-contained Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: CarpetX Changes (by Roland Haas): 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; ``` making amrex available (by including `loop_device.hxx` first, which seems wrong) I then get: ``` In file included from /home/rhaas/postdoc/gr/cactus/ET_trunk/configs/sim/bindings/include/reduction.hxx:4, from /home/rhaas/postdoc/gr/cactus/ET_trunk/configs/sim/build/CenterOfMass/centerofmass.cc:6: /home/rhaas/postdoc/gr/cactus/ET_trunk/arrangements/CarpetX/CarpetX/src/reduction.hxx:123:30: error: ?dim? was not declared in this scope; did you mean ?Loop::dim?? 123 | typedef reduction reduction_CCTK_REAL; | ^~~ | Loop::dim ``` which also seem wrong. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2933/carpetxs-reductionhxx-is-not-self -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Apr 21 11:55:08 2026 From: trac-noreply at einsteintoolkit.org (Erik Schnetter) Date: Tue, 21 Apr 2026 16:55:08 +0000 Subject: [ET Trac] #2933: CarpetX's reduction.hxx is not self-contained Message-ID: #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): I might have misread the error message. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2933/carpetxs-reductionhxx-is-not-self -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Apr 21 11:55:22 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 21 Apr 2026 16:55:22 +0000 Subject: [ET Trac] #2933: CarpetX's reduction.hxx is not self-contained Message-ID: #2933: CarpetX's reduction.hxx is not self-contained Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: CarpetX Comment (by Roland Haas): I have the dependency, that does unfortuantely not fix it: ``` REQUIRES CarpetX Loop ``` It would not affect what include files I see though, since Cactus has no notion of any thorn "owning" an include file declared in `interface.ccl` since they all actually just append to the include file, ie multiple thorns can have `INCLUDE HEADER: foo.hxx IN foo.hpp`. I think this is just an oversight since all other users of `reduction.hxx` (well `io_norms.cxx`) include `loop.hxx` first, before including `reduction.hxx` and they do have a global `dim` in their namespace (from `CarpetX` I guess. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2933/carpetxs-reductionhxx-is-not-self -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Apr 21 12:12:16 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 21 Apr 2026 17:12:16 +0000 Subject: [ET Trac] #2934: CarpetX's norms output ignores `IO::truncate_files` Message-ID: #2934: CarpetX's norms output ignores `IO::truncate_files` Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: CarpetX running the same parameter file that has: ``` IO::out_dir = $parfile IO::out_every = 1 IO::truncate_files = yes CarpetX::out_metadata = no CarpetX::out_norm_vars = "CenterOfMass::rho CenterOfMass::x_rho" ``` twice results in results in output being appended to the output file: ``` # 1:iteration 2:time 3:centerofmass::x_rho.min 4:centerofmass::x_rho.max 5:centerofmass::x_rho.sum 6:centerofmass::x_rho.avg 7:centerofmass::x_rho.stddev 8:centerofmass::x_rho.volume 9:centerofmass::x_rho.L1norm 10:centerofmass::x_rho.L2norm 11:centerofmass::x_rho.maxabs 0 0.0000000000000000e+00 -0.0000000000000000e+00 6.9999999999999996e-01 1.0000000000000007e+00 1.2500000000000000e-01 2.2776083947860748e-01 8.0000000000000053e+00 1.2500000000000000e-01 2.5980762113533162e-01 6.9999999999999996e-01 1 5.0000000000000003e-02 -0.0000000000000000e+00 6.9999999999999996e-01 8.8000000000000056e-01 1.1000000000000000e-01 2.2561028345356948e-01 8.0000000000000053e+00 1.1000000000000000e-01 2.5099800796022259e-01 6.9999999999999996e-01 2 1.0000000000000001e-01 -0.0000000000000000e+00 8.0000000000000004e-01 1.2000000000000008e+00 1.4999999999999999e-01 2.6925824035672508e-01 8.0000000000000053e+00 1.4999999999999999e-01 3.0822070014844871e-01 8.0000000000000004e-01 3 1.5000000000000002e-01 -0.0000000000000000e+00 8.0000000000000004e-01 1.2000000000000008e+00 1.4999999999999999e-01 2.6925824035672508e-01 8.0000000000000053e+00 1.4999999999999999e-01 3.0822070014844871e-01 8.0000000000000004e-01 4 2.0000000000000001e-01 -0.0000000000000000e+00 9.0000000000000013e-01 1.4000000000000010e+00 1.7500000000000002e-01 3.1124748994971835e-01 8.0000000000000053e+00 1.7500000000000002e-01 3.5707142142714254e-01 9.0000000000000013e-01 5 2.5000000000000000e-01 -0.0000000000000000e+00 9.0000000000000013e-01 1.2000000000000008e+00 1.4999999999999999e-01 3.0413812651491096e-01 8.0000000000000053e+00 1.4999999999999999e-01 3.3911649915626341e-01 9.0000000000000013e-01 6 2.9999999999999999e-01 -0.0000000000000000e+00 1.0000000000000002e+00 1.4000000000000010e+00 1.7500000000000002e-01 3.3071891388307384e-01 8.0000000000000053e+00 1.7500000000000002e-01 3.7416573867739417e-01 1.0000000000000002e+00 7 3.4999999999999998e-01 -0.0000000000000000e+00 1.0000000000000002e+00 1.4000000000000010e+00 1.7500000000000002e-01 3.3071891388307384e-01 8.0000000000000053e+00 1.7500000000000002e-01 3.7416573867739417e-01 1.0000000000000002e+00 8 3.9999999999999997e-01 -0.0000000000000000e+00 1.0000000000000002e+00 1.1600000000000004e+00 1.4499999999999996e-01 3.1776563690871273e-01 8.0000000000000053e+00 1.4499999999999996e-01 3.4928498393145940e-01 1.0000000000000002e+00 9 4.4999999999999996e-01 -0.0000000000000000e+00 1.0000000000000002e+00 8.8000000000000056e-01 1.1000000000000000e-01 2.9223278392404911e-01 8.0000000000000053e+00 1.1000000000000000e-01 3.1224989991991992e-01 1.0000000000000002e+00 10 4.9999999999999994e-01 -0.0000000000000000e+00 1.0000000000000002e+00 8.8000000000000056e-01 1.1000000000000000e-01 2.9223278392404911e-01 8.0000000000000053e+00 1.1000000000000000e-01 3.1224989991991992e-01 1.0000000000000002e+00 # 1:iteration 2:time 3:centerofmass::x_rho.min 4:centerofmass::x_rho.max 5:centerofmass::x_rho.sum 6:centerofmass::x_rho.avg 7:centerofmass::x_rho.stddev 8:centerofmass::x_rho.volume 9:centerofmass::x_rho.L1norm 10:centerofmass::x_rho.L2norm 11:centerofmass::x_rho.maxabs 0 0.0000000000000000e+00 -0.0000000000000000e+00 6.9999999999999996e-01 1.0000000000000007e+00 1.2500000000000000e-01 2.2776083947860748e-01 8.0000000000000053e+00 1.2500000000000000e-01 2.5980762113533162e-01 6.9999999999999996e-01 1 5.0000000000000003e-02 -0.0000000000000000e+00 6.9999999999999996e-01 8.8000000000000056e-01 1.1000000000000000e-01 2.2561028345356948e-01 8.0000000000000053e+00 1.1000000000000000e-01 2.5099800796022259e-01 6.9999999999999996e-01 2 1.0000000000000001e-01 -0.0000000000000000e+00 8.0000000000000004e-01 1.2000000000000008e+00 1.4999999999999999e-01 2.6925824035672508e-01 8.0000000000000053e+00 1.4999999999999999e-01 3.0822070014844871e-01 8.0000000000000004e-01 3 1.5000000000000002e-01 -0.0000000000000000e+00 8.0000000000000004e-01 1.2000000000000008e+00 1.4999999999999999e-01 2.6925824035672508e-01 8.0000000000000053e+00 1.4999999999999999e-01 3.0822070014844871e-01 8.0000000000000004e-01 4 2.0000000000000001e-01 -0.0000000000000000e+00 9.0000000000000013e-01 1.4000000000000010e+00 1.7500000000000002e-01 3.1124748994971835e-01 8.0000000000000053e+00 1.7500000000000002e-01 3.5707142142714254e-01 9.0000000000000013e-01 5 ``` instead of truncating as expected. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2934/carpetxs-norms-output-ignores-io -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Apr 21 12:13:02 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 21 Apr 2026 17:13:02 +0000 Subject: [ET Trac] #2934: CarpetX's norms output ignores `IO::truncate_files` Message-ID: #2934: CarpetX's norms output ignores `IO::truncate_files` Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: CarpetX Changes (by Roland Haas): running the same parameter file that has: ``` IO::out_dir = $parfile IO::out_every = 1 IO::truncate_files = yes CarpetX::out_metadata = no CarpetX::out_norm_vars = "CenterOfMass::rho CenterOfMass::x_rho" ``` twice results in results in output being appended to the output file: ``` # 1:iteration 2:time 3:centerofmass::x_rho.min 4:centerofmass::x_rho.max 5:centerofmass::x_rho.sum 6:centerofmass::x_rho.avg 7:centerofmass::x_rho.stddev 8:centerofmass::x_rho.volume 9:centerofmass::x_rho.L1norm 10:centerofmass::x_rho.L2norm 11:centerofmass::x_rho.maxabs 0 0.0000000000000000e+00 -0.0000000000000000e+00 6.9999999999999996e-01 1.0000000000000007e+00 1.2500000000000000e-01 2.2776083947860748e-01 8.0000000000000053e+00 1.2500000000000000e-01 2.5980762113533162e-01 6.9999999999999996e-01 1 5.0000000000000003e-02 -0.0000000000000000e+00 6.9999999999999996e-01 8.8000000000000056e-01 1.1000000000000000e-01 2.2561028345356948e-01 8.0000000000000053e+00 1.1000000000000000e-01 2.5099800796022259e-01 6.9999999999999996e-01 2 1.0000000000000001e-01 -0.0000000000000000e+00 8.0000000000000004e-01 1.2000000000000008e+00 1.4999999999999999e-01 2.6925824035672508e-01 8.0000000000000053e+00 1.4999999999999999e-01 3.0822070014844871e-01 8.0000000000000004e-01 3 1.5000000000000002e-01 -0.0000000000000000e+00 8.0000000000000004e-01 1.2000000000000008e+00 1.4999999999999999e-01 2.6925824035672508e-01 8.0000000000000053e+00 1.4999999999999999e-01 3.0822070014844871e-01 8.0000000000000004e-01 4 2.0000000000000001e-01 -0.0000000000000000e+00 9.0000000000000013e-01 1.4000000000000010e+00 1.7500000000000002e-01 3.1124748994971835e-01 8.0000000000000053e+00 1.7500000000000002e-01 3.5707142142714254e-01 9.0000000000000013e-01 5 2.5000000000000000e-01 -0.0000000000000000e+00 9.0000000000000013e-01 1.2000000000000008e+00 1.4999999999999999e-01 3.0413812651491096e-01 8.0000000000000053e+00 1.4999999999999999e-01 3.3911649915626341e-01 9.0000000000000013e-01 6 2.9999999999999999e-01 -0.0000000000000000e+00 1.0000000000000002e+00 1.4000000000000010e+00 1.7500000000000002e-01 3.3071891388307384e-01 8.0000000000000053e+00 1.7500000000000002e-01 3.7416573867739417e-01 1.0000000000000002e+00 7 3.4999999999999998e-01 -0.0000000000000000e+00 1.0000000000000002e+00 1.4000000000000010e+00 1.7500000000000002e-01 3.3071891388307384e-01 8.0000000000000053e+00 1.7500000000000002e-01 3.7416573867739417e-01 1.0000000000000002e+00 8 3.9999999999999997e-01 -0.0000000000000000e+00 1.0000000000000002e+00 1.1600000000000004e+00 1.4499999999999996e-01 3.1776563690871273e-01 8.0000000000000053e+00 1.4499999999999996e-01 3.4928498393145940e-01 1.0000000000000002e+00 9 4.4999999999999996e-01 -0.0000000000000000e+00 1.0000000000000002e+00 8.8000000000000056e-01 1.1000000000000000e-01 2.9223278392404911e-01 8.0000000000000053e+00 1.1000000000000000e-01 3.1224989991991992e-01 1.0000000000000002e+00 10 4.9999999999999994e-01 -0.0000000000000000e+00 1.0000000000000002e+00 8.8000000000000056e-01 1.1000000000000000e-01 2.9223278392404911e-01 8.0000000000000053e+00 1.1000000000000000e-01 3.1224989991991992e-01 1.0000000000000002e+00 # 1:iteration 2:time 3:centerofmass::x_rho.min 4:centerofmass::x_rho.max 5:centerofmass::x_rho.sum 6:centerofmass::x_rho.avg 7:centerofmass::x_rho.stddev 8:centerofmass::x_rho.volume 9:centerofmass::x_rho.L1norm 10:centerofmass::x_rho.L2norm 11:centerofmass::x_rho.maxabs 0 0.0000000000000000e+00 -0.0000000000000000e+00 6.9999999999999996e-01 1.0000000000000007e+00 1.2500000000000000e-01 2.2776083947860748e-01 8.0000000000000053e+00 1.2500000000000000e-01 2.5980762113533162e-01 6.9999999999999996e-01 1 5.0000000000000003e-02 -0.0000000000000000e+00 6.9999999999999996e-01 8.8000000000000056e-01 1.1000000000000000e-01 2.2561028345356948e-01 8.0000000000000053e+00 1.1000000000000000e-01 2.5099800796022259e-01 6.9999999999999996e-01 2 1.0000000000000001e-01 -0.0000000000000000e+00 8.0000000000000004e-01 1.2000000000000008e+00 1.4999999999999999e-01 2.6925824035672508e-01 8.0000000000000053e+00 1.4999999999999999e-01 3.0822070014844871e-01 8.0000000000000004e-01 3 1.5000000000000002e-01 -0.0000000000000000e+00 8.0000000000000004e-01 1.2000000000000008e+00 1.4999999999999999e-01 2.6925824035672508e-01 8.0000000000000053e+00 1.4999999999999999e-01 3.0822070014844871e-01 8.0000000000000004e-01 4 2.0000000000000001e-01 -0.0000000000000000e+00 9.0000000000000013e-01 1.4000000000000010e+00 1.7500000000000002e-01 3.1124748994971835e-01 8.0000000000000053e+00 1.7500000000000002e-01 3.5707142142714254e-01 9.0000000000000013e-01 5 ``` instead of truncating as expected. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2934/carpetxs-norms-output-ignores-io -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Apr 21 12:20:13 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 21 Apr 2026 17:20:13 +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 Wed Apr 22 12:59:00 2026 From: trac-noreply at einsteintoolkit.org (Beyhan Karakaş) Date: Wed, 22 Apr 2026 17:59:00 +0000 Subject: [ET Trac] #2172: Test "Binary black hole GW150914" example Message-ID: #2172: Test "Binary black hole GW150914" example Reporter: Roland Haas Status: open Milestone: ET_2026_05 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Beyhan Karaka?): responsible: (was []) assignee: (was Deborah Ferguson) Comment (by Beyhan Karaka?): Yuvraj Sharma (Deborah's student) will handle this for the release. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2172/test-binary-black-hole-gw150914-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Apr 22 13:24:43 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 22 Apr 2026 18:24:43 +0000 Subject: [ET Trac] #2172: Test "Binary black hole GW150914" example Message-ID: #2172: Test "Binary black hole GW150914" example Reporter: Roland Haas Status: open Milestone: ET_2026_05 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): responsible: [] (was ) assignee: Yuvraj Sharma (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2172/test-binary-black-hole-gw150914-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Apr 23 05:31:54 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Thu, 23 Apr 2026 10:31:54 +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 is there: https://github.com/Sbozzolo/kuibit/pull/48 -- 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 Thu Apr 23 05:32:31 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Thu, 23 Apr 2026 10:32:31 +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): Please review (at least the rationale explain in the issue https://github.com/Sbozzolo/kuibit/issues/47) -- 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 Thu Apr 23 08:18:27 2026 From: trac-noreply at einsteintoolkit.org (Beyhan Karakaş) Date: Thu, 23 Apr 2026 13:18:27 +0000 Subject: [ET Trac] #2175: Test "Single, stable neutron star" example Message-ID: #2175: Test "Single, stable neutron star" example Reporter: Roland Haas Status: open Milestone: ET_2026_05 Version: development version Type: task Priority: major Component: EinsteinToolkit website Comment (by Beyhan Karaka?): For the testing in future please check the "tov_20260325.tar.gz" and upload only the required files for each run which are less than a MB in total. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2175/test-single-stable-neutron-star-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Apr 23 08:19:07 2026 From: trac-noreply at einsteintoolkit.org (Beyhan Karakaş) Date: Thu, 23 Apr 2026 13:19:07 +0000 Subject: [ET Trac] #2175: Test "Single, stable neutron star" example Message-ID: #2175: Test "Single, stable neutron star" example Reporter: Roland Haas Status: resolved Milestone: ET_2026_05 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Beyhan Karaka?): status: resolved (was open) Comment (by Beyhan Karaka?): Closed for Hypatia release. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2175/test-single-stable-neutron-star-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Apr 23 09:35:21 2026 From: trac-noreply at einsteintoolkit.org (Beyhan Karakaş) Date: Thu, 23 Apr 2026 14:35:21 +0000 Subject: [ET Trac] #2173: Test "Poisson equation" example Message-ID: #2173: Test "Poisson equation" example Reporter: Roland Haas Status: resolved Milestone: ET_2026_05 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Beyhan Karaka?): status: resolved (was open) Comment (by Beyhan Karaka?): Thank you. Closed for Hypatia release. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2173/test-poisson-equation-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Apr 23 09:41:03 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Thu, 23 Apr 2026 14:41:03 +0000 Subject: [ET Trac] #2935: Kuibit: Support CarpetX tsv output (1D GF/Array, Norm/Scalar) Message-ID: #2935: Kuibit: Support CarpetX tsv output (1D GF/Array, Norm/Scalar) Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: proposal Priority: minor Component: See issue on Kuibit's repository: https://github.com/Sbozzolo/kuibit/issues/49 To summarize the file output differences: Carpet text output was either per variable or per group `.asc` ASCII files. CarpetX text output currently is only per group `.tsv` TSV files. CarpetX only appends the output to the `norms/` files, all other output files (scalars, GFs, Arrays) get their own file per group per iteration (per axis where applicable). Lastly, the headers have changed, the CarpetX headers are a single line, as opposed to the multi-line Carpet headers. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2935/kuibit-support-carpetx-tsv-output-1d-gf -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Apr 23 09:41:33 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Thu, 23 Apr 2026 14:41:33 +0000 Subject: [ET Trac] #2935: Kuibit: Support CarpetX tsv output (1D GF/Array, Norm/Scalar) Message-ID: #2935: Kuibit: Support CarpetX tsv output (1D GF/Array, Norm/Scalar) Reporter: Maxwell Rizzo Status: new Milestone: Version: Type: proposal Priority: minor Component: Changes (by Maxwell Rizzo): See issue on Kuibit's repository: https://github.com/Sbozzolo/kuibit/issues/49 To summarize the file output differences: Carpet text output was either per variable or per group `.asc` ASCII files. CarpetX text output currently is only per group `.tsv` TSV files. CarpetX only appends the output to the `norms/` files, all other output files (scalars, GFs, Arrays) get their own file per group per iteration (per axis where applicable). Lastly, the headers have changed, the CarpetX headers are a single line, as opposed to the multi-line Carpet headers. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2935/kuibit-support-carpetx-tsv-output-1d-gf -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Apr 23 09:49:09 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 23 Apr 2026 14:49:09 +0000 Subject: [ET Trac] #2928: New Simfactory Option Message-ID: #2928: New Simfactory Option Reporter: Steven R. Brandt Status: new Milestone: Version: Type: enhancement Priority: major Component: SimFactory Changes (by Roland Haas): responsible: [] (was ) assignee: Steven R. Brandt (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2928/new-simfactory-option -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Apr 23 09:55:53 2026 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Thu, 23 Apr 2026 14:55:53 +0000 Subject: [ET Trac] #2916: Include Cottonmouth Message-ID: #2916: Include Cottonmouth Reporter: Beyhan Karaka? Status: open Milestone: ET_2026_05 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Zach Etienne): Issues found (sorry for the uneven formatting): ``` Issue 1: Missing symmetrization in the conformal Ricci tensor inside the constraints/analysis block. Where the bug is In `fun_bssn_cons`, the code uses + Delta[uc] * Gammat[la, lb, lc] but in the BSSN Ricci decomposition the corresponding term is the symmetrized object Delta^c * Gammat_(ab)c which means (1/2) * Delta^c * Gammat_abc + (1/2) * Delta^c * Gammat_bac. Minimal fix Replace + Delta[uc] * Gammat[la, lb, lc] by + Rational(1, 2) * Delta[uc] * Gammat[la, lb, lc] + Rational(1, 2) * Delta[uc] * Gammat[lb, la, lc] Note that your own `fun_bssn_rhs` block already contains the correct symmetrized pair and therefore serves as an internal consistency check. ``` 2. bssnok.py ``` * Issue 2 - Severity high - Description of the error - The momentum-constraint matter source carries an extra factor of `w**2`. With `g_{ij} = (1 / w**2) * gt_{ij}`, one has `gamma^{ij} = w**2 * gt^{ij}`, but the conformal BSSN momentum constraint with free upper index uses `gt^{ij} * S_j`, not `gamma^{ij} * S_j`. The current code therefore overweights the source term by a factor of `w**2`. - Filename + line number(s) - Pasted file (filename not provided):638-648 - Original code snippet - fun_bssn_cons.add_eqn( MomCons[ua], + gt[ua, uc] * gt[ub, ud] * ( D(At[lc, ld], lb) - Gammat[uk, lc, lb] * At[lk, ld] - Gammat[uk, ld, lb] * At[lc, lk] ) + 6 * At[ua, ub] * cdphi[lb] - Rational(2, 3) * gt[ua, ub] * D(trK, lb) # Matter - 8 * pi * w**2 * gt[ua, ub] * S[lb] ) - Fixed code snippet. - fun_bssn_cons.add_eqn( MomCons[ua], + gt[ua, uc] * gt[ub, ud] * ( D(At[lc, ld], lb) - Gammat[uk, lc, lb] * At[lk, ld] - Gammat[uk, ld, lb] * At[lc, lk] ) + 6 * At[ua, ub] * cdphi[lb] - Rational(2, 3) * gt[ua, ub] * D(trK, lb) # Matter - 8 * pi * gt[ua, ub] * S[lb] ) - Confidence - 96% * Issue 3 - Severity low - Description of the error - The comments defining `Delta` are mathematically malformed. They describe the contraction with the wrong index pattern, which can mislead a reader into thinking `Delta^i` is built from `tilde gamma^{i,j} tilde Gamma^a_{ab}` or `tilde gamma^{ij} tilde Gamma^i_{jk}`. The correct definition is `Delta^i = tilde gamma^{jk} tilde Gamma^i_{jk}`. The executable code below the comments is correct; only the comments are wrong. - Filename + line number(s) - Pasted file (filename not provided):273-275 - Original code snippet - # \tilde{\gamma}^{i, j} \tilde{\Gamma}^a_{a b} # When \tilde{\Gamma}^{i} when it appears and its derivative are not needed, # the substitution \tilde{\Gamma}^{i} \rightarrow \tilde{gamma}^{ij} \tilde{\Gamma}^{i}_{jk} = \Delta^i - Fixed code snippet. - # \Delta^i = \tilde{\gamma}^{jk} \tilde{\Gamma}^i_{jk} # When \tilde{\Gamma}^{i} appears without derivatives, we replace it by # \Delta^i = \tilde{\gamma}^{jk} \tilde{\Gamma}^{i}_{jk} - Confidence - 99% ``` ``` Issue 4: linear_wave.py: File sets an unphysical default amplitude for the wave: amplitude = cottonmouth_linear_wave_id.add_param( "amplitude", default=1.0, desc="Linear wave amplitude" ) A << 1 for a valid linearized wave. ``` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2916/include-cottonmouth -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Apr 23 12:05:21 2026 From: trac-noreply at einsteintoolkit.org (Maxwell Rizzo) Date: Thu, 23 Apr 2026 17:05:21 +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 CarpetX?s TSV output, excluding the norms/ files, does not append to a single file per group in the way Carpet?s ASCII output does. Instead, it creates one file per group per iteration: `.it000000..tsv` for grid functions and arrays, and `.it000000.tsv` for scalars. Appending subsequent iterations to the same file would make analysis and post-processing easier, while also reducing the amount of output files. -- 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 Fri Apr 24 18:20:43 2026 From: trac-noreply at einsteintoolkit.org (Leonardo Rosa Werneck) Date: Fri, 24 Apr 2026 23:20:43 +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): [PR #15](https://github.com/GRHayL/GRHayLET/pull/15) was merged. Please close this ticket if in fact issue was resolved. -- 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 Mon Apr 27 11:24:58 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Mon, 27 Apr 2026 16:24:58 +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: Version: Type: bug Priority: major Component: Comment (by Steven R. Brandt): I say we leave it as is and wait for the clankers to become smart enough to figure it out. -- 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 Mon Apr 27 11:27:57 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Mon, 27 Apr 2026 16:27:57 +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: Version: Type: bug Priority: major Component: Comment (by Steven R. Brandt): I think all clanker issues are now addressed. While there never was a passing test in this thorn, it still passes the test Lucas added in feature/TwoPuncturesX-tests. -- 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 Mon Apr 27 16:04:15 2026 From: trac-noreply at einsteintoolkit.org (Lucas Timotheo Sanches) Date: Mon, 27 Apr 2026 21:04:15 +0000 Subject: [ET Trac] #2916: Include Cottonmouth Message-ID: #2916: Include Cottonmouth Reporter: Beyhan Karaka? Status: open Milestone: ET_2026_05 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Lucas Timotheo Sanches): Hey Zach, Thanks for the comments! I have addressed all the issues pointed out so far. They are already in the `master` branch of EinsteinEngine. Please recheck and see if the changes are adequate -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2916/include-cottonmouth -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Apr 30 09:14:04 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 30 Apr 2026 14:14:04 +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: Changes (by Roland Haas): milestone: ET_2026_05 (was ) -- 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 Apr 30 09:17:10 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 30 Apr 2026 14:17:10 +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: Changes (by Roland Haas): milestone: ET_2026_05 (was ) -- 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 Thu Apr 30 09:18:21 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 30 Apr 2026 14:18:21 +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 Changes (by Roland Haas): responsible: [] (was ) milestone: ET_2026_05 (was ) assignee: Roland Haas (was ) -- 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 Thu Apr 30 09:51:05 2026 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Thu, 30 Apr 2026 14:51:05 +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: TwoPuncturesX inclusion ticket: #2926 While `TwoPuncturesX` ( is an essential thorn for CarpetX, it currently exists largely as a line-by-line copy of `TwoPunctures`, with more than 90% of the lines of code duplicated. This approach creates a maintenance burden: any updates to the core logic of either `TwoPunctures` or `TwoPuncturesX` must be manually replicated in the other thorn. This increases the risk that the two implementations will diverge over time, leading to inconsistent behavior, duplicated bugs, or fixes being applied in one thorn but accidentally omitted from the other. Duplicated code is not acceptable here for several reasons. First, it makes long-term maintenance more error-prone, because developers must remember to update two nearly identical code paths whenever a change is made. Second, it makes review and testing more difficult, since reviewers and maintainers must determine whether differences between the two thorns are intentional, accidental, or simply the result of one copy being out of date. More broadly, this duplication increases the cost of future development and makes it harder to ensure correctness across both `TwoPunctures` and `TwoPuncturesX`. During the April 30, 2026 ET telecon, several possible approaches were discussed for addressing this issue: 1. **Make `TwoPuncturesX` require `TwoPunctures`.** This would reduce duplication by allowing `TwoPuncturesX` to reuse functionality from `TwoPunctures`. However, this may be difficult because `TwoPuncturesX` requires `ADMBaseX`, while `TwoPunctures` requires `ADMBase`. 2. **Create symbolic links for files that are identical between the two thorns.** For files that are exactly the same in both thorns, symbolic links could ensure that updates to one file are automatically reflected in the other. This would reduce the risk of the two copies drifting apart, though care would be needed to ensure this works reliably across development environments and version-control workflows. 3. **Create a shared `TwoPuncturesGuts` thorn.** A new thorn, tentatively named `TwoPuncturesGuts`, could contain header files or shared source components comprising the core utilities used by both `TwoPunctures` and `TwoPuncturesX`. This would provide a cleaner long-term solution by centralizing the common implementation while allowing the two thorns to retain their separate interfaces and dependencies where necessary. The goal of this ticket is to identify and implement a maintainable structure that avoids unnecessary code duplication while preserving the functionality required by both `TwoPunctures` and `TwoPuncturesX`. -- 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 Apr 30 09:51:52 2026 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Thu, 30 Apr 2026 14:51:52 +0000 Subject: [ET Trac] #2926: Include TwoPuncturesX Message-ID: #2926: Include TwoPuncturesX Reporter: Beyhan Karaka? Status: new Milestone: ET_2026_05 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Zach Etienne): Related ticket "TwoPuncturesX largely duplicates TwoPunctures (#2937)" -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2926/include-twopuncturesx -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Apr 30 11:07:33 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 30 Apr 2026 16:07:33 +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 New versions of HDF5 support a single-writer, multiple reader (SWMR) mode that keeps files intact while appending to existing datasets. This can be helpful for CarpetIOHDF5 since it reduces the window in time during which files would be corrupted if Cactus is terminated while writing to a file. A high-level description of the functionality is found on: https://support.hdfgroup.org/documentation/hdf5/latest/_s_w_m_r_t_n.html Unfortunately, even for the reader, the functionality is not fully transparent it seems (namely the reader must pass flags to `H5Fopen`), so this may require a "fix-files" step to make partially written files readable with standard utilities (eg VisIt). But at least the files themselves would be mostly intact. -- 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 Thu Apr 30 13:54:58 2026 From: trac-noreply at einsteintoolkit.org (Lucas Timotheo Sanches) Date: Thu, 30 Apr 2026 18:54:58 +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): Superseded by [this PR](https://github.com/EinsteinToolkit/CarpetX/pull/379) -- 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 Thu Apr 30 14:57:02 2026 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Thu, 30 Apr 2026 19:57:02 +0000 Subject: [ET Trac] #2928: New Simfactory Option Message-ID: #2928: New Simfactory Option Reporter: Steven R. Brandt Status: new Milestone: Version: Type: enhancement Priority: major Component: SimFactory Comment (by Steven R. Brandt): Currently, this is how I run on qbd. I have a script where I set the number of gpus and the queue I want to run in, then I use these few lines to call simfactory. I set the gpus and queue, then the script handles the math. This could be absorbed into simfactory. ``` gpus=4 queue=gpu2 if [ $queue = gpu2 ] then cpus_per_gpu=32 else cpus_per_gpu=16 fi if [ $gpus = 1 ] then ppn=32 else ppn=64 fi set -x ./simfactory/bin/sim create-submit $sim --queue $queue --config bssn --parfile benchpars/bench_$sim.par --procs $(($gpus*$cpus_per_gpu)) --num-threads $cpus_per_gpu --ppn-used $ppn ``` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2928/new-simfactory-option -------------- next part -------------- An HTML attachment was scrubbed... URL: