Trac

trac@lists.einsteintoolkit.org

8708 discussions

#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

#2908: Cactus: Fixed arg list too long error.
by Steven R. Brandt 18 Dec '25

18 Dec '25

#2908: Cactus: Fixed arg list too long error. Reporter: Max Morris Status: new Milestone: Version: Type: bug Priority: major Component: Changes (by Steven R. Brandt): status: new (was submitted) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2908/cactus-fixed-arg-…

1 0

#2909: Remove TAGS from interface.ccl
by Steven R. Brandt 17 Dec '25

17 Dec '25

#2909: Remove TAGS from interface.ccl Reporter: Steven R. Brandt Status: new Milestone: ET_2025_05 Version: ET_2025_05 Type: enhancement Priority: major Component: Cactus Remove the need for the `TAGS='...'` markup in interface.ccl. Simply remove this from all files and the code will continue to compile and run as before. See PR [https://bitbucket.org/cactuscode/cactus/pull-requests/176](https://bitbucke… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2909/remove-tags-from-…

1 0

#2908: Cactus: Fixed arg list too long error.
by Max Morris 17 Dec '25

17 Dec '25

#2908: Cactus: Fixed arg list too long error. Reporter: Max Morris Status: submitted Milestone: Version: Type: bug Priority: major Component: Comment (by Max Morris): Please review -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2908/cactus-fixed-arg-…

1 0

#2908: Cactus: Fixed arg list too long error.
by Max Morris 17 Dec '25

17 Dec '25

#2908: Cactus: Fixed arg list too long error. Reporter: Max Morris Status: submitted Milestone: Version: Type: bug Priority: major Component: [https://bitbucket.org/cactuscode/cactus/pull-requests/175](https://bitbucke… There is a check in `lib/make/make.thornlib` to ensure that `sh` is not passed an argument string which is too long. However, this check is not robust enough because it counts words instead of characters/bytes and compares against arbitrary magic numbers rather than checking the max argument string length of the system. I am working on a thorn which fails to build as a direct result of the faulty check. This PR replaces the existing check with a more robust one based on `$ getconf ARG_MAX`, with reasonable fallback behavior if the system shell somehow doesn’t support this command. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2908/cactus-fixed-arg-…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac