From trac-noreply at einsteintoolkit.org Sun Jan 18 16:23:18 2026 From: trac-noreply at einsteintoolkit.org (Lucas Timotheo Sanches) Date: Sun, 18 Jan 2026 22:23:18 +0000 Subject: [ET Trac] #2911: CarpetX: Check timers before changing their state Message-ID: #2911: CarpetX: Check timers before changing their state Reporter: Lucas Timotheo Sanches Status: new Milestone: Version: Type: bug Priority: major Component: Pull request is [here](https://github.com/EinsteinToolkit/CarpetX/pull/374) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2911/carpetx-check-timers-before-changing-their -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Sun Jan 18 16:23:26 2026 From: trac-noreply at einsteintoolkit.org (Lucas Timotheo Sanches) Date: Sun, 18 Jan 2026 22:23:26 +0000 Subject: [ET Trac] #2911: CarpetX: Check timers before changing their state Message-ID: #2911: CarpetX: Check timers before changing their state Reporter: Lucas Timotheo Sanches Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Lucas Timotheo Sanches): Please review -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2911/carpetx-check-timers-before-changing-their -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jan 20 03:14:33 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Tue, 20 Jan 2026 09:14:33 +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: submitted Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn For reference, thread on the users mailing list: [https://lists.einsteintoolkit.org/pipermail/users/2026-January/009852.html](https://lists.einsteintoolkit.org/pipermail/users/2026-January/009852.html) The issue originates in trying to compute volume integrals in an analysis thorn, by using the volume form computed by Coordinates in a Llama grid. ? In simulations using Llama, different patch systems don?t compute the volume\_form grid function in the same way \(when requested by parameter store\_volume\_form. More precisely, the default behavior is \(inverse-jacobian.F90\): ``` volume_form(i,j,k) = detJ ``` ? Meanwhile, patch system Thornburg04 has a dedicated routine because it needs to compute weights to account for overlapping patches. But even in the non-overlapping spherical part of the grid, it computes the volume form as \(thornburg04.cc\): ``` // set volume form to deterimant of Jacobian const CCTK_REAL det = fabs(( J11[ijk] * J22[ijk] * J33[ijk] + J12[ijk] * J23[ijk] * J31[ijk] + J13[ijk] * J21[ijk] * J32[ijk] - J11[ijk] * J23[ijk] * J32[ijk] - J12[ijk] * J21[ijk] * J33[ijk] - J13[ijk] * J22[ijk] * J31[ijk])); volume_form[ijk] = h[0]*h[1]*h[2]/det; ``` where h is the spacing computed before in the function. ? This leads to, in particular, different behaviors for the volume form between Thornburg04 and Thornburg04nc. ? For consistency of treatment and agnosticity of thorns that would rely on the volume form \(assuming they know Llama is being used\), I would suggest to homogenize the computation of volume form. Here are a few suggestions, given that my tests were limited only to Thornburg04 and Thornburg04nc. * Leave it to each patch system to compute the volume form, and have an error/warning as default \(but they should still be somehow consistent, to avoid having to check for the patch system in a user thorn. * \(preferred, but not tested on my side with other patch systems\) Replace the default computation by something similar to Thornburg04: ```fortran CCTK_INT map, ierr CCTK_INT, PARAMETER :: dimensions = 3 CCTK_REAL, dimension(dimensions) :: physical_min, physical_max, interior_min, interior_max, exterior_min, exterior_max, h map = MultiPatch_GetMap(cctkGH) ierr = MultiPatch_GetDomainSpecification( map, dimensions, & physical_min, physical_max, & interior_min, interior_max, & exterior_min, exterior_max, & h ) ``` ```fortran volume_form(i,j,k) = h(1)*h(2)*h(3) / abs(detJ) ``` Also note the absolute value here, as I?ve encountered negative values of the determinant in tests. -- 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 Tue Jan 20 10:39:26 2026 From: trac-noreply at einsteintoolkit.org (Jordan Nicoules) Date: Tue, 20 Jan 2026 16:39:26 +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: submitted Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Jordan Nicoules): For reference, thread on the users mailing list: [https://lists.einsteintoolkit.org/pipermail/users/2026-January/009852.html](https://lists.einsteintoolkit.org/pipermail/users/2026-January/009852.html) The issue originates in trying to compute volume integrals in an analysis thorn, by using the volume form computed by Coordinates in a Llama grid. ? In simulations using Llama, different patch systems don?t compute the volume\_form grid function in the same way \(when requested by parameter store\_volume\_form. More precisely, the default behavior is \(inverse-jacobian.F90\): ``` volume_form(i,j,k) = detJ ``` ? Meanwhile, patch system Thornburg04 has a dedicated routine because it needs to compute weights to account for overlapping patches. But even in the non-overlapping spherical part of the grid, it computes the volume form as \(thornburg04.cc\): ``` // set volume form to deterimant of Jacobian const CCTK_REAL det = fabs(( J11[ijk] * J22[ijk] * J33[ijk] + J12[ijk] * J23[ijk] * J31[ijk] + J13[ijk] * J21[ijk] * J32[ijk] - J11[ijk] * J23[ijk] * J32[ijk] - J12[ijk] * J21[ijk] * J33[ijk] - J13[ijk] * J22[ijk] * J31[ijk])); volume_form[ijk] = h[0]*h[1]*h[2]/det; ``` where h is the spacing computed before in the function. ? This leads to, in particular, different behaviors for the volume form between Thornburg04 and Thornburg04nc. ? For consistency of treatment and agnosticity of thorns that would rely on the volume form \(assuming they know Llama is being used\), I would suggest to homogenize the computation of volume form. Here are a few suggestions, given that my tests were limited only to Thornburg04 and Thornburg04nc. * Leave it to each patch system to compute the volume form, and have an error/warning as default \(but they should still be somehow consistent, to avoid having to check for the patch system in a user thorn. * \(preferred, but not tested on my side with other patch systems\) Replace the default computation by something similar to Thornburg04: ``` CCTK_INT map, ierr CCTK_INT, PARAMETER :: dimensions = 3 CCTK_REAL, dimension(dimensions) :: physical_min, physical_max, interior_min, interior_max, exterior_min, exterior_max, h map = MultiPatch_GetMap(cctkGH) ierr = MultiPatch_GetDomainSpecification( map, dimensions, & physical_min, physical_max, & interior_min, interior_max, & exterior_min, exterior_max, & h ) ``` ``` volume_form(i,j,k) = h(1)*h(2)*h(3) / abs(detJ) ``` Also note the absolute value here, as I?ve encountered negative values of the determinant in tests. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2912/inconsistent-computation-of-the-volume -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jan 22 11:25:10 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 22 Jan 2026 17:25:10 +0000 Subject: [ET Trac] #2906: Cactus: New cGH field cctk_patch_is_cartesian Message-ID: #2906: Cactus: New cGH field cctk_patch_is_cartesian Reporter: Roland Haas Status: open Milestone: Version: Type: enhancement Priority: major Component: Cactus Comment (by Roland Haas): This was discussed in the last CarpetX call \(@{557058:1671c5c3-29cc-4e83-9850-a152d33a6235} , @{5f2f18c8e8c45600229698f5} , @{557058:56049c54-f8c2-4b6c-9b88-ab697c967495} , @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} \) and approved. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2906/cactus-new-cgh-field -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jan 22 12:54:35 2026 From: trac-noreply at einsteintoolkit.org (Erik Schnetter) Date: Thu, 22 Jan 2026 18:54:35 +0000 Subject: [ET Trac] #2906: Cactus: New cGH field cctk_patch_is_cartesian Message-ID: #2906: Cactus: New cGH field cctk_patch_is_cartesian Reporter: Roland Haas Status: open Milestone: Version: Type: enhancement Priority: major Component: Cactus Comment (by Erik Schnetter): Merged via [https://bitbucket.org/cactuscode/cactus/commits/7081ec6a0b60a9fe9abdf72b1916e9d843d4b2b4](https://bitbucket.org/cactuscode/cactus/commits/7081ec6a0b60a9fe9abdf72b1916e9d843d4b2b4). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2906/cactus-new-cgh-field -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jan 22 12:54:45 2026 From: trac-noreply at einsteintoolkit.org (Erik Schnetter) Date: Thu, 22 Jan 2026 18:54:45 +0000 Subject: [ET Trac] #2906: Cactus: New cGH field cctk_patch_is_cartesian Message-ID: #2906: Cactus: New cGH field cctk_patch_is_cartesian Reporter: Roland Haas Status: resolved Milestone: Version: Type: enhancement Priority: major Component: Cactus Changes (by Erik Schnetter): status: resolved (was open) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2906/cactus-new-cgh-field -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jan 22 16:29:57 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 22 Jan 2026 22:29:57 +0000 Subject: [ET Trac] #2911: CarpetX: Check timers before changing their state Message-ID: #2911: CarpetX: Check timers before changing their state Reporter: Lucas Timotheo Sanches Status: wontfix Milestone: Version: Type: bug Priority: major Component: Changes (by Roland Haas): status: wontfix (was new) Comment (by Roland Haas): Is a multi-threading issue, which cannot be addressed this way. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2911/carpetx-check-timers-before-changing-their -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jan 22 16:32:56 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 22 Jan 2026 22:32:56 +0000 Subject: [ET Trac] #2899: BHNS with Elliptica: Assertion `all(offset == other.offset)' failed Message-ID: #2899: BHNS with Elliptica: Assertion `all(offset == other.offset)' failed Reporter: Alejandra Gonzalez Status: open Milestone: Version: Type: bug Priority: major Component: Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2899/bhns-with-elliptica-assertion-all-offset -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jan 23 13:44:59 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 23 Jan 2026 19:44:59 +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): The key line in the proposed change is ``` OBJS-bytes := $(shell (echo -n $(OBJS) | wc --bytes) 2>/dev/null || echo -1) ``` However making a small dummy Makefile: ``` # make a long set of arguments >2million OBJS=$(shell awk 'BEGIN{for(i=0;i<200000;i++) print "01234567890";exit'}) OBJS-bytes := $(shell (echo -n $(OBJS) | wc --bytes) 2>/dev/null || echo -1) $(info $(OBJS-bytes)) ``` and running via ``` make -f Makefile ``` on my Debian based Linux box I get: ``` haengie2: ~/tmp$ make -f Makefile make: /bin/sh: Argument list too long make: *** No targets. Stop. ``` ie not the expected output of either `-1`or the length of `OBJS`. So this does not seem to work for me. -- 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 Jan 23 14:04:56 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 23 Jan 2026 20:04: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): Something like this however may kind of work, by checking for failure: ``` $(shell : $(OBJS)) ifeq ($(.SHELLSTATUS),0) OBJS-too-long := 0 else OBJS-too-long := 1 endif ``` which just tries to execute the `:` \(true\) command. -- 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 Mon Jan 26 11:05:46 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Mon, 26 Jan 2026 17:05:46 +0000 Subject: [ET Trac] #2913: support enabling / disabling storage in CarpetX Message-ID: #2913: support enabling / disabling storage in CarpetX Reporter: Roland Haas Status: new Milestone: Version: Type: task Priority: major Component: CarpetX Right now all grid variables declared in `interface.ccl` in CarpetX always have storage turned on. To reduce memory footprint for codes \(and just b/c this is the expected behaviour\) CarpetX shoud support Cactus' `CCTK_StoarageIncrease` and `CCTK_StorageDecrease` and `STORAGE: foo`statements. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2913/support-enabling-disabling-storage-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Jan 26 11:05:53 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Mon, 26 Jan 2026 17:05:53 +0000 Subject: [ET Trac] #2913: support enabling / disabling storage in CarpetX Message-ID: #2913: support enabling / disabling storage in CarpetX Reporter: Roland Haas Status: open Milestone: Version: Type: task Priority: major Component: CarpetX Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2913/support-enabling-disabling-storage-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Jan 26 11:06:14 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Mon, 26 Jan 2026 17:06:14 +0000 Subject: [ET Trac] #2913: support enabling / disabling storage in CarpetX Message-ID: #2913: support enabling / disabling storage in CarpetX Reporter: Roland Haas Status: open Milestone: Version: Type: task Priority: major Component: CarpetX Changes (by Roland Haas): Right now all grid variables declared in `interface.ccl` in CarpetX always have storage turned on. To reduce memory footprint for codes \(and just b/c this is the expected behaviour\) CarpetX shoud support Cactus' `CCTK_StorageIncrease` and `CCTK_StorageDecrease` and `STORAGE: foo`statements. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2913/support-enabling-disabling-storage-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jan 28 09:59:59 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 28 Jan 2026 15:59:59 +0000 Subject: [ET Trac] #2673: provide (historical) tar archives for each ET release Message-ID: #2673: provide (historical) tar archives for each ET release Reporter: Roland Haas Status: new Milestone: Version: Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): responsible: [] (was ) assignee: Roland Haas (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2673/provide-historical-tar-archives-for-each -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jan 28 11:14:59 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 28 Jan 2026 17:14:59 +0000 Subject: [ET Trac] #2673: provide (historical) tar archives for each ET release Message-ID: #2673: provide (historical) tar archives for each ET release Reporter: Roland Haas Status: new Milestone: Version: Type: task Priority: major Component: EinsteinToolkit website Comment (by Roland Haas): I have checkouts of: * ET\_2025\_05 "Martin D. Kruskal", released 2025-05-29 * ET\_2024\_11 "Annie Jump Cannon", released 2024-12-02 * ET\_2024\_05 "Lev Landau", released 2024-06-28 * ET\_2023\_11 "Lise Meitner", released 2023-12-06 * ET\_2023\_05 "Karl Schwarzschild", released 2023-05-24 * ET\_2022\_11 "Sophie Kowalevski", released 2022-11-29 * ET\_2022\_05 "Bernhard Riemann", released 2022-05-31 * ET\_2021\_11 "Katherine Johnson", released 2021-12-08 * ET\_2021\_05 "Lorentz", released 2021-05-31 * ET\_2020\_11 "DeWitt-Morette", released 2020-11-30 * ET\_2020\_05 "Turing", released 2020-05-31 * ET\_2019\_10 "Mayer", released 2019-10-25 * ET\_2019\_03 "Proca", released 2019-03-29 * ET\_2018\_09 "Chien-Shiung Wu", released 2018-09-17 * ET\_2018\_02 "Tesla", released 2018-02-09 * ET\_2017\_06 "Hack", released 2017-07-17 * ET\_2016\_11 "Payne-Gaposchkin", released 2016-12-16 * ET\_2016\_05 "Brahe", released 2016-06-15 * ET\_2015\_11 "Somerville", released 2015-11-11 * ET\_2015\_05 "Hilbert", released 2015-05-18 * ET\_2014\_11 "Herschel", released 2014-11-19 * ET\_2014\_05 "Wheeler", released 2014-05-21 * ET\_2013\_11 "Noether", released 2013-11-26 * ET\_2013\_05 "Gauss", released 2013-05-22 * ET\_2012\_11 "?rsted", released 2012-11-08 * ET\_2012\_05 "Lovelace", released 2012-05-28 * ET\_2011\_10 "Maxwell", released 2011-10-25 * ET\_2011\_05 "Curie", released 2011-04-21 but am missing the first two releases * ET\_2010\_11 "Chandrasekhar", released 2010-11-23 * ET\_2010\_06 "Bohr", released 2010-06-17 my copy of `ET_Lovelace` has corrupted svn metadata \(at least\) so may not be trustworthy. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2673/provide-historical-tar-archives-for-each -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jan 29 09:18:14 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 29 Jan 2026 15:18:14 +0000 Subject: [ET Trac] #2898: CarpetX: Interpolator caches Message-ID: #2898: CarpetX: Interpolator caches Reporter: Lucas Timotheo Sanches Status: open Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): @{557058:56049c54-f8c2-4b6c-9b88-ab697c967495} poke -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2898/carpetx-interpolator-caches -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jan 29 10:47:50 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 29 Jan 2026 16:47:50 +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 Changes (by Roland Haas): status: open (was submitted) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2912/inconsistent-computation-of-the-volume -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jan 29 15:56:03 2026 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 29 Jan 2026 21:56:03 +0000 Subject: [ET Trac] #2914: update cover photo for ET facebook page Message-ID: #2914: update cover photo for ET facebook page Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: trivial Component: EinsteinToolkit website The cover photo for the ET facebook page [https://www.facebook.com/einsteintoolkithttps://www.facebook.com/einsteintoolkit](https://www.facebook.com/einsteintoolkit) is outdated \(shows an ET meeting from a couple of years ago\). It should be upated. ![](https://scontent-sea1-1.xx.fbcdn.net/v/t39.30808-6/474151325_982735423760493_799754265918431392_n.jpg?stp=dst-jpg_s960x960_tt6&_nc_cat=100&ccb=1-7&_nc_sid=cc71e4&_nc_ohc=b3Sq6A26T3sQ7kNvwHWOYtN&_nc_oc=Adlfh1f5ZaE-AOgcfhxryu8C7YFnKuw7s5xJIy-e1w_aQ0NdXqgub00aGNEC9yNN1fg&_nc_zt=23&_nc_ht=scontent-sea1-1.xx&_nc_gid=plETQ2uBQrjRcCOsLdZ35A&oh=00_AfrsXb_bWIhL-7XvI8ZprkGv052CnyTScRWph-R5f4oTgA&oe=69816261){: data-layout='center' } \(current photo\) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2914/update-cover-photo-for-et-facebook-page -------------- next part -------------- An HTML attachment was scrubbed... URL: