January 2026 - Trac - lists.einsteintoolkit.org

#2914: update cover photo for ET facebook page
by Roland Haas 29 Jan '26

29 Jan '26

#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/einsteinto… 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-phot…

1 0

#2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior
by Roland Haas 29 Jan '26

29 Jan '26

#2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior Reporter: Jordan Nicoules Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: open (was submitted) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2912/inconsistent-comp…

1 0

#2898: CarpetX: Interpolator caches
by Roland Haas 29 Jan '26

29 Jan '26

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

1 0

#2673: provide (historical) tar archives for each ET release
by Roland Haas 28 Jan '26

28 Jan '26

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

1 0

#2673: provide (historical) tar archives for each ET release
by Roland Haas 28 Jan '26

28 Jan '26

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

1 0

#2913: support enabling / disabling storage in CarpetX
by Roland Haas 26 Jan '26

26 Jan '26

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

1 0

#2913: support enabling / disabling storage in CarpetX
by Roland Haas 26 Jan '26

26 Jan '26

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

1 0

#2913: support enabling / disabling storage in CarpetX
by Roland Haas 26 Jan '26

26 Jan '26

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

1 0

#2908: Cactus: Fixed arg list too long error.
by Roland Haas 23 Jan '26

23 Jan '26

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

1 0

#2908: Cactus: Fixed arg list too long error.
by Roland Haas 23 Jan '26

23 Jan '26

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

1 0

#2899: BHNS with Elliptica: Assertion `all(offset == other.offset)' failed
by Roland Haas 22 Jan '26

22 Jan '26

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

1 0

#2911: CarpetX: Check timers before changing their state
by Roland Haas 22 Jan '26

22 Jan '26

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

1 0

#2906: Cactus: New cGH field cctk_patch_is_cartesian
by Erik Schnetter 22 Jan '26

22 Jan '26

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

1 0

#2906: Cactus: New cGH field cctk_patch_is_cartesian
by Erik Schnetter 22 Jan '26

22 Jan '26

#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/7081ec6a0b60a9fe9abdf72b191…. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2906/cactus-new-cgh-fi…

1 0

#2906: Cactus: New cGH field cctk_patch_is_cartesian
by Roland Haas 22 Jan '26

22 Jan '26

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

1 0

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

20 Jan '26

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

1 0

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

20 Jan '26

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

1 0

#2911: CarpetX: Check timers before changing their state
by Lucas Timotheo Sanches 18 Jan '26

18 Jan '26

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

1 0

#2911: CarpetX: Check timers before changing their state
by Lucas Timotheo Sanches 18 Jan '26

18 Jan '26

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

1 0