From trac-noreply at einsteintoolkit.org Tue Sep 2 12:46:37 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 02 Sep 2025 17:46:37 +0000 Subject: [ET Trac] #2883: ExternalLibraries fail to build with cmake 4.0 Message-ID: #2883: ExternalLibraries fail to build with cmake 4.0 Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Applied as git hash [c6ac85d](https://github.com/EinsteinToolkit/ExternalLibraries-openPMD/commits/c6ac85d8f63ec4521e77d815035c0361c025614f) "openPMD: bump version to 0.16.1" of [ExternalLibraries-openPMD](https://github.com/EinsteinToolkit/ExternalLibraries-openPMD) Applied as git hash [dcbde10](https://github.com/EinsteinToolkit/ExternalLibraries-NSIMD/commits/dcbde10e004889383c5e57fe0837a734fdd4b37a) "NSIMD: update version requirements to support CMake 4.0" of [ExternalLibraries-NSIMD](https://github.com/EinsteinToolkit/ExternalLibraries-NSIMD) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2883/externallibraries-fail-to-build-with-cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 2 12:46:51 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 02 Sep 2025 17:46:51 +0000 Subject: [ET Trac] #2883: ExternalLibraries fail to build with cmake 4.0 Message-ID: #2883: ExternalLibraries fail to build with cmake 4.0 Reporter: Roland Haas Status: resolved Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2883/externallibraries-fail-to-build-with-cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 2 13:00:47 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 02 Sep 2025 18:00:47 +0000 Subject: [ET Trac] #2880: backport ExternalLibraries changes for gcc-15, and RPM-based repos to Kruskal Message-ID: #2880: backport ExternalLibraries changes for gcc-15, and RPM-based repos to Kruskal Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Backported as git hash [c45b71f](https://github.com/EinsteinToolkit/ExternalLibraries-ADIOS2/commits/c45b71f75756a2d4d7d9bf6f8cee3b502dc6fea7) "ADIOS2: make compile with gcc15 by adding stdint" of [ExternalLibraries-ADIOS2](https://github.com/EinsteinToolkit/ExternalLibraries-ADIOS2) Backported as git hash [0bf0d5b](https://github.com/EinsteinToolkit/ExternalLibraries-Silo/commits/0bf0d5b47067b06f95aec94342ef6348c95d1983) "Silo: force libdir when building from source" of [ExternalLibraries-Silo](https://github.com/EinsteinToolkit/ExternalLibraries-Silo) Backported as git hash [5bde5bf](https://github.com/EinsteinToolkit/ExternalLibraries-HDF5/commits/5bde5bfbf02dfb79d460689ee88eb5c9b092cccc) "HDF5: use env variable for --keep-system-libs instead of option" of [ExternalLibraries-HDF5](https://github.com/EinsteinToolkit/ExternalLibraries-HDF5) Backported as git hash [dcbde10](https://github.com/EinsteinToolkit/ExternalLibraries-NSIMD/commits/dcbde10e004889383c5e57fe0837a734fdd4b37a) "NSIMD: update version requirements to support CMake 4.0" of [ExternalLibraries-NSIMD](https://github.com/EinsteinToolkit/ExternalLibraries-NSIMD) Backported as git hash [c6ac85d](https://github.com/EinsteinToolkit/ExternalLibraries-openPMD/commits/c6ac85d8f63ec4521e77d815035c0361c025614f) "openPMD: bump version to 0.16.1" of [ExternalLibraries-openPMD](https://github.com/EinsteinToolkit/ExternalLibraries-openPMD) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2880/backport-externallibraries-changes-for-gcc -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 2 13:01:17 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 02 Sep 2025 18:01:17 +0000 Subject: [ET Trac] #2880: backport ExternalLibraries changes for gcc-15, and RPM-based repos to Kruskal Message-ID: #2880: backport ExternalLibraries changes for gcc-15, and RPM-based repos to Kruskal Reporter: Roland Haas Status: resolved Milestone: Version: Type: bug Priority: major Component: Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2880/backport-externallibraries-changes-for-gcc -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 3 03:00:39 2025 From: trac-noreply at einsteintoolkit.org (Alejandra Gonzalez) Date: Wed, 03 Sep 2025 08:00:39 +0000 Subject: [ET Trac] #2882: Running BBH with CarpetX with CPUs: High memory consumption and low performance Message-ID: #2882: Running BBH with CarpetX with CPUs: High memory consumption and low performance Reporter: Alejandra Gonzalez Status: new Milestone: Version: Type: bug Priority: major Component: CarpetX Comment (by Alejandra Gonzalez): An update on this: CarpetX \(main branch\) CPU without subcycling ? still consumes a lot of memory and the performance keeps being slow CarpetX \(liwei?s branch\) CPU with subcycling ? I keep getting out of memory errors so I still haven?t gotten the chance to check its performance -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2882/running-bbh-with-carpetx-with-cpus-high -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 3 14:22:17 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 03 Sep 2025 19:22:17 +0000 Subject: [ET Trac] #2885: test for std::filesystem availability in Silo output likely broken Message-ID: #2885: test for std::filesystem availability in Silo output likely broken Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: The test ``` #if defined __cpp_lib_filesystem && __cpp_lib_filesystem < 201703L #include namespace fs = std::experimental::filesystem; #else #include namespace fs = std::filesystem; #endif ``` \(or so\) in the Silo output routines is quite likely not performing as intended. Namely 1. `__cpp_lib_filesystem` is defined either in `` \(C\+\+20\) or in `` \(which is what we want to test for\) 2. if defined \(at least in g\+\+12\) it is set to the constant `201703L` anyway References: \* [https://en.cppreference.com/w/cpp/feature\_test.html](https://en.cppreference.com/w/cpp/feature_test.html) \(though g\+\+ does provide a version file even in version of gcc that do not support C\+\+20 and also when C\+\+20 is not the language version used\) \* [https://stackoverflow.com/a/53365539](https://stackoverflow.com/a/53365539) which is somewhat more complex than we?d want, and also would require access to ``. The current workaround exists b/c of old gcc versions \(7 apparently\) and also for some clusters where the \(AMD / clang / hip\) compiler is old. ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2885/test-for-std-filesystem-availability-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 3 17:16:52 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 03 Sep 2025 22:16:52 +0000 Subject: [ET Trac] #2883: ExternalLibraries fail to build with cmake 4.0 Message-ID: #2883: ExternalLibraries fail to build with cmake 4.0 Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: open (was resolved) Comment (by Roland Haas): Also fails in yaml-cpp (which Fedora had a binary package, so this was not noticed before). Reported by Jasper Bos. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2883/externallibraries-fail-to-build-with-cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 3 18:06:11 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 03 Sep 2025 23:06:11 +0000 Subject: [ET Trac] #2883: ExternalLibraries fail to build with cmake 4.0 Message-ID: #2883: ExternalLibraries fail to build with cmake 4.0 Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): CMake fix for yaml-cpp: [https://github.com/EinsteinToolkit/ExternalLibraries-yaml\_cpp/pull/2](https://github.com/EinsteinToolkit/ExternalLibraries-yaml_cpp/pull/2) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2883/externallibraries-fail-to-build-with-cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 3 18:07:23 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 03 Sep 2025 23:07:23 +0000 Subject: [ET Trac] #2883: ExternalLibraries fail to build with cmake 4.0 Message-ID: #2883: ExternalLibraries fail to build with cmake 4.0 Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Applied as git hash [d19a948](https://github.com/EinsteinToolkit/ExternalLibraries-yaml_cpp/commits/d19a9486a154b823446fc0233321bc662d72bd0b) "yaml-cpp: patch minimum CMake requirement" of [ExternalLibraries-yaml\_cpp](https://github.com/EinsteinToolkit/ExternalLibraries-yaml_cpp) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2883/externallibraries-fail-to-build-with-cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 3 18:09:06 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 03 Sep 2025 23:09:06 +0000 Subject: [ET Trac] #2880: backport ExternalLibraries changes for gcc-15, and RPM-based repos to Kruskal Message-ID: #2880: backport ExternalLibraries changes for gcc-15, and RPM-based repos to Kruskal Reporter: Roland Haas Status: resolved Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Backported as git hash [0a4f089](https://github.com/EinsteinToolkit/ExternalLibraries-yaml_cpp/commits/0a4f0895d8b1cf8099fe3a1fb1c6b08131cc58d4) "yaml-cpp: patch minimum CMake requirement" of [ExternalLibraries-yaml\_cpp](https://github.com/EinsteinToolkit/ExternalLibraries-yaml_cpp) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2880/backport-externallibraries-changes-for-gcc -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 3 18:09:26 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 03 Sep 2025 23:09:26 +0000 Subject: [ET Trac] #2883: ExternalLibraries fail to build with cmake 4.0 Message-ID: #2883: ExternalLibraries fail to build with cmake 4.0 Reporter: Roland Haas Status: resolved Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: resolved (was open) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2883/externallibraries-fail-to-build-with-cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 4 09:04:20 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 04 Sep 2025 14:04:20 +0000 Subject: [ET Trac] #2858: SF files for MN5 (was: Compiling CarpetX: issues with PDESolvers) Message-ID: #2858: SF files for MN5 (was: Compiling CarpetX: issues with PDESolvers) Reporter: Alejandra Gonzalez Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): title: SF files for MN5 (was: Compiling CarpetX: issues with PDESolvers) (was Compiling CarpetX: issues with PDESolvers) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2858/sf-files-for-mn5-was-compiling-carpetx -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 4 09:15:40 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 04 Sep 2025 14:15:40 +0000 Subject: [ET Trac] #2866: Problem while building the ET on MN5: OpenCL Message-ID: #2866: Problem while building the ET on MN5: OpenCL Reporter: Samuel G?mez Status: new Milestone: Version: Type: bug Priority: blocker Component: Cactus Changes (by Roland Haas): responsible: (was []) assignee: (was Steven R. Brandt) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2866/problem-while-building-the-et-on-mn5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 4 09:21:14 2025 From: trac-noreply at einsteintoolkit.org (Erik Schnetter) Date: Thu, 04 Sep 2025 14:21:14 +0000 Subject: [ET Trac] #2885: test for std::filesystem availability in Silo output likely broken Message-ID: #2885: test for std::filesystem availability in Silo output likely broken Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: Comment (by Erik Schnetter): I would say that, as long as this code compiles, it is working ?well enough? for us. In modern C\+\+, `` is available, and we are looking for a fall-back for old C\+\+ compilers. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2885/test-for-std-filesystem-availability-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 4 13:25:02 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 04 Sep 2025 18:25:02 +0000 Subject: [ET Trac] #2885: test for std::filesystem availability in Silo output likely broken Message-ID: #2885: test for std::filesystem availability in Silo output likely broken Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: Comment (by Roland Haas): I think the issue was some AMD clang compiler on Frontier that, while accepting `-std=c++17` would only provide `filesystem` in `experimental`. On the other hand just testing this right now, I cannot make it fail. Well, I will see if I can set this ticket to sleep for a bit. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2885/test-for-std-filesystem-availability-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 4 13:25:07 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 04 Sep 2025 18:25:07 +0000 Subject: [ET Trac] #2885: test for std::filesystem availability in Silo output likely broken Message-ID: #2885: test for std::filesystem availability in Silo output likely broken Reporter: Roland Haas Status: on hold Milestone: Version: Type: bug Priority: minor Component: Changes (by Roland Haas): status: on hold (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2885/test-for-std-filesystem-availability-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 4 13:36:23 2025 From: trac-noreply at einsteintoolkit.org (Bill Gabella) Date: Thu, 04 Sep 2025 18:36:23 +0000 Subject: [ET Trac] #2874: NRPyElliptic lacks regeneration instructions Message-ID: #2874: NRPyElliptic lacks regeneration instructions Reporter: Steven R. Brandt Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Bill Gabella): In the meeting today, Zach said he is refactoring NRPyElliptic into a library like BHaHAHA. That may/should fix this problem?or at least the NRPyElliptic will be different. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2874/nrpyelliptic-lacks-regeneration -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 9 09:28:26 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 09 Sep 2025 14:28:26 +0000 Subject: [ET Trac] #2886: support cell centered directions when calling Fortran scheduled functions Message-ID: #2886: support cell centered directions when calling Fortran scheduled functions Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: major Component: Cactus The current code in git hash [eef7e55c](https://bitbucket.org/cactuscode/cactus/commits/eef7e55c0b20c4c31028adb42c6d7d52120343c1) "Cactus: use only group index based functions in Fortran wrappers" of [cactus](https://bitbucket.org/cactuscode/cactus), while removing a potential race condition does not yet correctly set up cell centered arrays for Fortran since it makes all grid functions have shape `cctk_lsh` which is the shape of a vertex centered grid function \(that is one element too large in each direction for a fully cell centered grid function\). This should be corrected in a manner similar to the `DECLARE_CCTK_ARGUMENTSX_FunctionName` macros in C\+\+. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2886/support-cell-centered-directions-when -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 9 09:29:04 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 09 Sep 2025 14:29:04 +0000 Subject: [ET Trac] #2886: support cell centered directions when calling Fortran scheduled functions Message-ID: #2886: support cell centered directions when calling Fortran scheduled functions Reporter: Roland Haas Status: open Milestone: Version: Type: enhancement Priority: major Component: Cactus Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2886/support-cell-centered-directions-when -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 9 09:30:42 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 09 Sep 2025 14:30:42 +0000 Subject: [ET Trac] #2886: support cell centered directions when calling Fortran scheduled functions Message-ID: #2886: support cell centered directions when calling Fortran scheduled functions Reporter: Roland Haas Status: open Milestone: Version: Type: enhancement Priority: major Component: Cactus Comment (by Roland Haas): A somehwat ugly workaround right now would be use of Fortran 2003?s `iso_c_binding` module and using C pointers as intermediate pointers as in [https://gcc.gnu.org/onlinedocs/gfortran/C\_005fF\_005fPOINTER.html](https://gcc.gnu.org/onlinedocs/gfortran/C_005fF_005fPOINTER.html) ```fortran program main use iso_c_binding implicit none interface subroutine my_routine(p) bind(c,name='myC_func') import :: c_ptr type(c_ptr), intent(out) :: p end subroutine end interface type(c_ptr) :: cptr real,pointer :: a(:) call my_routine(cptr) call c_f_pointer(cptr, a, [12]) end program main ``` ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2886/support-cell-centered-directions-when -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 9 14:40:08 2025 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Tue, 09 Sep 2025 19:40:08 +0000 Subject: [ET Trac] #2887: TwoPunctures does not support Slow-Start Lapse. Message-ID: #2887: TwoPunctures does not support Slow-Start Lapse. Reporter: Zach Etienne Status: new Milestone: Version: Type: enhancement Priority: major Component: Currently TwoPunctures offers several options for setting the initial lapse. None of these options are compatible with Slow-Start Lapse \[arXiv:2404.01137, Phys. Rev. D 110, 064045 \(2024\)\], which requires that the initial lapse be set to W=\(psi\+u\)^\{-2\}. Here is the PR that resolves this issue: [https://bitbucket.org/einsteintoolkit/einsteininitialdata/pull-requests/21](https://bitbucket.org/einsteintoolkit/einsteininitialdata/pull-requests/21) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2887/twopunctures-does-not-support-slow-start -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 9 14:40:16 2025 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Tue, 09 Sep 2025 19:40:16 +0000 Subject: [ET Trac] #2887: TwoPunctures does not support Slow-Start Lapse. Message-ID: #2887: TwoPunctures does not support Slow-Start Lapse. Reporter: Zach Etienne Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Zach Etienne): Please review -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2887/twopunctures-does-not-support-slow-start -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 9 16:24:33 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 09 Sep 2025 21:24:33 +0000 Subject: [ET Trac] #2887: TwoPunctures does not support Slow-Start Lapse. Message-ID: #2887: TwoPunctures does not support Slow-Start Lapse. Reporter: Zach Etienne Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): hmm, how about: [https://bitbucket.org/einsteintoolkit/tickets/issues/2706/update-default-twopunctures-parameters-or?iframe=true&spa=0#comment-65802578](https://bitbucket.org/einsteintoolkit/tickets/issues/2706/update-default-twopunctures-parameters-or?iframe=true&spa=0#comment-65802578) > The BBH gallery example has a rather unusual choice of initial lapse, setting it to the average value of 1 - m\_i / \(2r\_i\) for both punctures i. More typically the initial lapse is set to the ?pre-collapsed? value of psi^\{-2\} which goes like 1 - M/r at large radii for total binary mass M. This is the same asymptotic behavior that the will lapse relax to, and so this choice results in less gauge dynamics than the ?averaged lapse? value. TwoPunctures supports `initial_lapse = "psi^n"` and chooses a perfectly fine default value of `n=initial_lapse_psi_exponent=-2` . ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2887/twopunctures-does-not-support-slow-start -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 9 16:24:39 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 09 Sep 2025 21:24:39 +0000 Subject: [ET Trac] #2887: TwoPunctures does not support Slow-Start Lapse. Message-ID: #2887: TwoPunctures does not support Slow-Start Lapse. Reporter: Zach Etienne Status: open Milestone: Version: Type: enhancement Priority: major Component: Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2887/twopunctures-does-not-support-slow-start -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 9 16:25:07 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 09 Sep 2025 21:25:07 +0000 Subject: [ET Trac] #2887: TwoPunctures does not support Slow-Start Lapse. Message-ID: #2887: TwoPunctures does not support Slow-Start Lapse. Reporter: Zach Etienne Status: open Milestone: Version: Type: enhancement Priority: major Component: Changes (by Roland Haas): responsible: [] (was ) assignee: Zach Etienne (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2887/twopunctures-does-not-support-slow-start -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 9 16:28:04 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 09 Sep 2025 21:28:04 +0000 Subject: [ET Trac] #2887: TwoPunctures does not support Slow-Start Lapse. Message-ID: #2887: TwoPunctures does not support Slow-Start Lapse. Reporter: Zach Etienne Status: open Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): uh, looking at the pull request, I notice the difference. So #2706 should not use `initial_lapse = "psi^n"` after all. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2887/twopunctures-does-not-support-slow-start -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 9 16:45:43 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 09 Sep 2025 21:45:43 +0000 Subject: [ET Trac] #2706: Update default TwoPunctures parameters, or at least default parameters in BBH gallery example Message-ID: #2706: Update default TwoPunctures parameters, or at least default parameters in BBH gallery example Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit website Comment (by Roland Haas): Note: #2887 indicated `psi^n` is not quite what one wants it to be \(namely `(psi+u)^n`\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2706/update-default-twopunctures-parameters-or -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 11 08:52:57 2025 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Thu, 11 Sep 2025 13:52:57 +0000 Subject: [ET Trac] #2706: Update default TwoPunctures parameters, or at least default parameters in BBH gallery example Message-ID: #2706: Update default TwoPunctures parameters, or at least default parameters in BBH gallery example Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit website Comment (by Zach Etienne): @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} : I have removed the string comparison in the inner loop. Also it took 12 minutes for Bitbucket to propagate my change from my branch to the PR. Unacceptable, @atlassian. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2706/update-default-twopunctures-parameters-or -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 11 11:43:20 2025 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Thu, 11 Sep 2025 16:43:20 +0000 Subject: [ET Trac] #2887: TwoPunctures does not support Slow-Start Lapse. Message-ID: #2887: TwoPunctures does not support Slow-Start Lapse. Reporter: Zach Etienne Status: open Milestone: Version: Type: enhancement Priority: major Component: Comment (by Zach Etienne): When Slow Start Lapse \(SSL\) is disabled, setting initial\_lapse = psi^n with n = -2 results in evolutions that are nearly indistinguishable from initial\_lapse = W. However, keeping the default as initial\_lapse = W is safer for future compatibility: if SSL is later enabled and the lapse is not initially W, you?ll see a spike in the Einstein constraints. Here?s why: SSL exponentially relaxes the lapse toward \*W\* very early in the wormhole-to-trumpet transition, smoothing the sharp outgoing-lapse feature that accounts for >99.9% of constraint violations in moving-puncture BBH evolutions \(see [https://arxiv.org/abs/2404.01137](https://arxiv.org/abs/2404.01137)\). If the lapse isn?t initially set to W, then ?Slow Start? would be better termed ?Fast and Reckless?, as the initial lapse will be exponentially driven to W from whatever it was set to initially ? leading to the aforementioned _spike_ in Einstein constraints. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2887/twopunctures-does-not-support-slow-start -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 11 14:56:43 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 11 Sep 2025 19:56:43 +0000 Subject: [ET Trac] #2887: TwoPunctures does not support Slow-Start Lapse. Message-ID: #2887: TwoPunctures does not support Slow-Start Lapse. Reporter: Zach Etienne Status: open Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): Please apply. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2887/twopunctures-does-not-support-slow-start -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 11 14:56:48 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 11 Sep 2025 19:56:48 +0000 Subject: [ET Trac] #2887: TwoPunctures does not support Slow-Start Lapse. Message-ID: #2887: TwoPunctures does not support Slow-Start Lapse. Reporter: Zach Etienne Status: open Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): Applied as git hash [3d014938](https://bitbucket.org/einsteintoolkit/einsteininitialdata/commits/3d014938cc6165a80caeb53b66f814452cc34f89) "TwoPunctures: implement W-type precollapsed lapse" of [einsteininitialdata](https://bitbucket.org/einsteintoolkit/einsteininitialdata) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2887/twopunctures-does-not-support-slow-start -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 11 14:57:01 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 11 Sep 2025 19:57:01 +0000 Subject: [ET Trac] #2887: TwoPunctures does not support Slow-Start Lapse. Message-ID: #2887: TwoPunctures does not support Slow-Start Lapse. Reporter: Zach Etienne Status: open Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): Thank you. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2887/twopunctures-does-not-support-slow-start -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 11 14:57:05 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 11 Sep 2025 19:57:05 +0000 Subject: [ET Trac] #2887: TwoPunctures does not support Slow-Start Lapse. Message-ID: #2887: TwoPunctures does not support Slow-Start Lapse. Reporter: Zach Etienne Status: resolved Milestone: Version: Type: enhancement Priority: major Component: Changes (by Roland Haas): status: resolved (was open) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2887/twopunctures-does-not-support-slow-start -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 18 09:34:58 2025 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Thu, 18 Sep 2025 14:34:58 +0000 Subject: [ET Trac] #2706: Update default TwoPunctures parameters, or at least default parameters in BBH gallery example Message-ID: #2706: Update default TwoPunctures parameters, or at least default parameters in BBH gallery example Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit website Comment (by Zach Etienne): Plan is to complete #963 ?improve McLachlan accuracy? as part of the update to the BBH gallery example. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2706/update-default-twopunctures-parameters-or -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 11:08:30 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 16:08:30 +0000 Subject: [ET Trac] #1856: Improve stack backtraces Message-ID: #1856: Improve stack backtraces Reporter: Erik Schnetter Status: new Milestone: Version: development version Type: enhancement Priority: minor Component: Carpet Comment (by Roland Haas): Git hash [98141381](https://bitbucket.org/eschnett/carpet/commits/981413815e8530db76f80c39505a588e070a1df4) "Carpet/CarpetLib: Move stack backtrace code to its own file" of [carpet](https://bitbucket.org/eschnett/carpet) pretty much implements this, using `backtrace_symbols` instead of `backtrace_symbols_fd`. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1856/improve-stack-backtraces -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 11:08:34 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 16:08:34 +0000 Subject: [ET Trac] #1856: Improve stack backtraces Message-ID: #1856: Improve stack backtraces Reporter: Erik Schnetter Status: resolved Milestone: Version: development version Type: enhancement Priority: minor Component: Carpet Changes (by Roland Haas): status: resolved (was new) I found . We should go through the example here, and compare to our code to see whether we can improve it. **Keyword:** -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1856/improve-stack-backtraces -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 11:17:17 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 16:17:17 +0000 Subject: [ET Trac] #1798: add backtrace script to cactus utils Message-ID: #1798: add backtrace script to cactus utils Reporter: Steven R. Brandt Status: new Milestone: Version: development version Type: enhancement Priority: minor Component: Other Comment (by Roland Haas): Is it worthwhile to have and maintain such a script? We already give the `addr2line` command line at the bottom of each `backtrace..txt` file. Plus, often one actually needs to use `gdb` and its `info line *
` command \(and a core dump\) either b/c of address space randomization \(laptops\) or b/c `addr2line` is older than `gdb`. Ie. do the benefits outweigh the effort? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1798/add-backtrace-script-to-cactus-utils -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 11:17:41 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 16:17:41 +0000 Subject: [ET Trac] #1798: add backtrace script to cactus utils Message-ID: #1798: add backtrace script to cactus utils Reporter: Steven R. Brandt Status: new Milestone: Version: development version Type: enhancement Priority: minor Component: Other Changes (by Roland Haas): responsible: [] (was ) assignee: Steven R. Brandt (was ) The script converts backtraces generated by carpet to readable output with file and line number. **Keyword:** -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1798/add-backtrace-script-to-cactus-utils -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 11:25:48 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 16:25:48 +0000 Subject: [ET Trac] #2545: some of simfactory's run scripts use /bin/sh when they really want /bin/bash Message-ID: #2545: some of simfactory's run scripts use /bin/sh when they really want /bin/bash Reporter: Status: new Milestone: Version: development version Type: bug Priority: minor Component: SimFactory Comment (by Roland Haas): `/bin/sh` is no longer used in any \*script as of git hash [96fd1a54](https://bitbucket.org/simfactory/simfactory2/commits/96fd1a54642258c6b62d1b6c791d545ea47d7cb4) "generic-mpi: use bash in runscript" of [simfactory2](https://bitbucket.org/simfactory/simfactory2) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2545/some-of-simfactorys-run-scripts-use-bin-sh -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 11:25:53 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 16:25:53 +0000 Subject: [ET Trac] #2545: some of simfactory's run scripts use /bin/sh when they really want /bin/bash Message-ID: #2545: some of simfactory's run scripts use /bin/sh when they really want /bin/bash Reporter: Status: resolved Milestone: Version: development version Type: bug Priority: minor Component: SimFactory Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2545/some-of-simfactorys-run-scripts-use-bin-sh -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 11:26:42 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 16:26:42 +0000 Subject: [ET Trac] #2335: Switch Simfactory to use Python3 Message-ID: #2335: Switch Simfactory to use Python3 Reporter: Steven R. Brandt Status: open Milestone: ET_2020_11 Version: Type: proposal Priority: major Component: SimFactory Comment (by Roland Haas): Effectively done as of git hash [e258b76e](https://bitbucket.org/simfactory/simfactory2/commits/e258b76ee54b1f50a9e9b549ef2fe95c52c7a9fc) "sim: accept all Python, prefer python3" of [simfactory2](https://bitbucket.org/simfactory/simfactory2) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2335/switch-simfactory-to-use-python3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 11:26:56 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 16:26:56 +0000 Subject: [ET Trac] #2335: Switch Simfactory to use Python3 Message-ID: #2335: Switch Simfactory to use Python3 Reporter: Steven R. Brandt Status: resolved Milestone: ET_2020_11 Version: Type: proposal Priority: major Component: SimFactory Changes (by Roland Haas): status: resolved (was open) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2335/switch-simfactory-to-use-python3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 11:30:14 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 16:30:14 +0000 Subject: [ET Trac] #1335: SimFactory should abort if there are no checkpoint files when submitting an existing configuration Message-ID: #1335: SimFactory should abort if there are no checkpoint files when submitting an existing configuration Reporter: Ian Hinder Status: wontfix Milestone: Version: Type: enhancement Priority: minor Component: SimFactory Changes (by Roland Haas): status: wontfix (was new) When submitting a simulation which already contains at least one restart, simfactory should abort if there are no checkpoint files available. This likely means that something went wrong. Starting the simulation again is always the wrong thing to do in this case, as it will waste CPU time and might go unnoticed. **Keyword:** Comment (by Roland Haas): As Ian stated, there can realistically be no checkpoint files even when one wants to "continue" a simulation. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1335/simfactory-should-abort-if-there-are-no -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 11:31:49 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 16:31:49 +0000 Subject: [ET Trac] #1327: Delay subsequent restarts in the case of certain problems Message-ID: #1327: Delay subsequent restarts in the case of certain problems Reporter: Ian Hinder Status: new Milestone: Version: Type: enhancement Priority: minor Component: SimFactory Comment (by Roland Haas): Mostly a duplicate of #1286 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1327/delay-subsequent-restarts-in-the-case-of -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 11:31:56 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 16:31:56 +0000 Subject: [ET Trac] #1327: Delay subsequent restarts in the case of certain problems Message-ID: #1327: Delay subsequent restarts in the case of certain problems Reporter: Ian Hinder Status: duplicate Milestone: Version: Type: enhancement Priority: minor Component: SimFactory Changes (by Roland Haas): status: duplicate (was new) Comment (by Roland Haas): Duplicate of #1286. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1327/delay-subsequent-restarts-in-the-case-of -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 11:43:13 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 16:43:13 +0000 Subject: [ET Trac] #1321: Collisions in executable cache directory Message-ID: #1321: Collisions in executable cache directory Reporter: Ian Hinder Status: new Milestone: Version: development version Type: bug Priority: minor Component: SimFactory Comment (by Roland Haas): Caching the executable \(currently about 1.1 GB when compiling all thorns and with debug symbols\) in order to reduce disk space usage becomes mostly moot once the first checkpoint is written: even the lowest resolution checkpoint for a vacuum run of mine is 2.0 GB per checkpoint file, and there are 64 checkpoint files per checkpoint. So it really only matters for things like test runs \(or the testsuites\) where no checkpoints are being written. The cache also uses hard-links across directories which not all file systems like / support \(BeeGFS is one of them\). Do we need the cache? Removing it would remove all issues associated with it. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1321/collisions-in-executable-cache-directory -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 11:50:02 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 16:50:02 +0000 Subject: [ET Trac] #1721: Simfactory's test mechanism should use softlinks instead of rsync Message-ID: #1721: Simfactory's test mechanism should use softlinks instead of rsync Reporter: Erik Schnetter Status: open Milestone: Version: development version Type: enhancement Priority: minor Component: SimFactory Comment (by Roland Haas): As pointed out in [https://bitbucket.org/einsteintoolkit/tickets/issues/1721/simfactorys-test-mechanism-should-use?iframe=true&spa=0#comment-50394399](https://bitbucket.org/einsteintoolkit/tickets/issues/1721/simfactorys-test-mechanism-should-use?iframe=true&spa=0#comment-50394399) not all clusters allow access to the file system that contains the source code from a running job. So copies are required there. To avoid the complication of a cache or determining if symbolic links would work, I suggest we keep the copying. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1721/simfactorys-test-mechanism-should-use -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 11:52:58 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 16:52:58 +0000 Subject: [ET Trac] #127: Restarts should have hard link to executable Message-ID: #127: Restarts should have hard link to executable Reporter: Erik Schnetter Status: open Milestone: Version: Type: bug Priority: minor Component: SimFactory Comment (by Roland Haas): Hard links will face the same issues as the executable cache concerning file systems that do not allow hard links across directories \(BeeGFS maybe also some Lustre setups that want to use multiple metadata servers, not sure\). Having a fixed copy of the executable that was used is useful when one updates the executable during a run. Currently this is a manual intervention. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/127/restarts-should-have-hard-link-to -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 11:57:00 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 16:57:00 +0000 Subject: [ET Trac] #2482: Inconsistency in Simfactory submission scripts Message-ID: #2482: Inconsistency in Simfactory submission scripts Reporter: Steven R. Brandt Status: new Milestone: Version: Type: bug Priority: major Component: SimFactory Comment (by Roland Haas): I think this can be closed. Each cluster is too different and usually maintained by different people to really hope for consistent files between clusters. @{557058:1671c5c3-29cc-4e83-9850-a152d33a6235} ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2482/inconsistency-in-simfactory-submission -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 13:33:13 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 18:33:13 +0000 Subject: [ET Trac] #2888: race condition writing properties.ini in simfactory Message-ID: #2888: race condition writing properties.ini in simfactory Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: SimFactory Currently bot the `submit()` as well as the `run()`function in `lib/simrestart.py` write \(update\) the file `output-NNNN/properties.ini`. In particular `submit()` does so _after_ submitting to record the `jobid` field while `run()` does so before running to record the `checkpointing` value. This means that if \(eg on SLURM where jobs start quickly, an particular when the `submit` command contains a `sleep 5` to slow down job submission\) there can be race condition: 1. `submit` writes initial copy of `properties.ini` lacking `jobid` 2. `submit` submits the job to SLURM 3. job starts and run reads `properties.ini` 4. `submit` writes updated `properties.ini` with `jobid` 5. `run` writes `properties.ini` with `checkpointing` at this point `jobid` is lost from `properties.ini` Fixes would be: * add a lock for `properties.ini` which `submit` only release once it has done its final update * submit jobs in ?held? state \(`sbatch --hold`\) and only release them once the final update of properties.ini has happened both will require updates to simfactory?s code. The first option would work without updates to the machine ini files, the second will require extra entries to tell simfactory how to release a job. This could also be used to implement `hold` and `release` commands in simfactory. The first option will require fallback code in case the lock file is left behind \(e.g. wait no longer than 1 minute before assuming a stale lock and going ahead anyway\). The lock file will require at least some level for POSIX conformance from the file system \(namely that file creation and removal is an atomic operation cluster-wide\). This most likely is the reason for occasional strange failures on clusters with jobid being unset. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2888/race-condition-writing-propertiesini-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 13:38:45 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 18:38:45 +0000 Subject: [ET Trac] #2888: race condition writing properties.ini in simfactory Message-ID: #2888: race condition writing properties.ini in simfactory Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: SimFactory Comment (by Roland Haas): Note that not writing `properties.ini` is not a sufficient solution since even without writing there remains the issue that a job could start before `jobid` has been recorded and thus the `@JOB_ID@` replacement is invalid. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2888/race-condition-writing-propertiesini-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 13:39:03 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 18:39:03 +0000 Subject: [ET Trac] #2888: race condition writing properties.ini in simfactory Message-ID: #2888: race condition writing properties.ini in simfactory Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: SimFactory Changes (by Roland Haas): Currently both the `submit()` as well as the `run()`function in `lib/simrestart.py` write \(update\) the file `output-NNNN/properties.ini`. In particular `submit()` does so _after_ submitting to record the `jobid` field while `run()` does so before running to record the `checkpointing` value. This means that if \(eg on SLURM where jobs start quickly, an particular when the `submit` command contains a `sleep 5` to slow down job submission\) there can be race condition: 1. `submit` writes initial copy of `properties.ini` lacking `jobid` 2. `submit` submits the job to SLURM 3. job starts and run reads `properties.ini` 4. `submit` writes updated `properties.ini` with `jobid` 5. `run` writes `properties.ini` with `checkpointing` at this point `jobid` is lost from `properties.ini` Fixes would be: * add a lock for `properties.ini` which `submit` only release once it has done its final update * submit jobs in ?held? state \(`sbatch --hold`\) and only release them once the final update of properties.ini has happened both will require updates to simfactory?s code. The first option would work without updates to the machine ini files, the second will require extra entries to tell simfactory how to release a job. This could also be used to implement `hold` and `release` commands in simfactory. The first option will require fallback code in case the lock file is left behind \(e.g. wait no longer than 1 minute before assuming a stale lock and going ahead anyway\). The lock file will require at least some level for POSIX conformance from the file system \(namely that file creation and removal is an atomic operation cluster-wide\). This most likely is the reason for occasional strange failures on clusters with jobid being unset. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2888/race-condition-writing-propertiesini-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 13:39:51 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 18:39:51 +0000 Subject: [ET Trac] #2888: race condition writing properties.ini in simfactory Message-ID: #2888: race condition writing properties.ini in simfactory Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: SimFactory Changes (by Roland Haas): Currently both the `submit()` as well as the `run()`function in `lib/simrestart.py` write \(update\) the file `output-NNNN/properties.ini`. In particular `submit()` does so _after_ submitting to record the `jobid` field while `run()` does so before running to record the `checkpointing` value. This means that \(eg on SLURM where jobs start quickly, an particular when the `submit` command contains a `sleep 5` to slow down job submission\) there can be race condition: 1. `submit` writes initial copy of `properties.ini` lacking `jobid` 2. `submit` submits the job to SLURM 3. job starts and run reads `properties.ini` 4. `submit` writes updated `properties.ini` with `jobid` 5. `run` writes `properties.ini` with `checkpointing` at this point `jobid` is lost from `properties.ini` Fixes would be: * add a lock for `properties.ini` which `submit` only release once it has done its final update * submit jobs in ?held? state \(`sbatch --hold`\) and only release them once the final update of properties.ini has happened both will require updates to simfactory?s code. The first option would work without updates to the machine ini files, the second will require extra entries to tell simfactory how to release a job. This could also be used to implement `hold` and `release` commands in simfactory. The first option will require fallback code in case the lock file is left behind \(e.g. wait no longer than 1 minute before assuming a stale lock and going ahead anyway\). The lock file will require at least some level for POSIX conformance from the file system \(namely that file creation and removal is an atomic operation cluster-wide\). This most likely is the reason for occasional strange failures on clusters with jobid being unset. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2888/race-condition-writing-propertiesini-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 24 13:40:13 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 24 Sep 2025 18:40:13 +0000 Subject: [ET Trac] #2888: race condition writing properties.ini in simfactory Message-ID: #2888: race condition writing properties.ini in simfactory Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: SimFactory Changes (by Roland Haas): Currently both the `submit()` as well as the `run()`function in `lib/simrestart.py` write \(update\) the file `output-NNNN/properties.ini`. In particular `submit()` does so _after_ submitting to record the `jobid` field while `run()` does so before running to record the `checkpointing` value. This means that \(eg on SLURM where jobs start quickly, an particular when the `submit` command contains a `sleep 5` to slow down job submission\) there can be race condition: 1. `submit` writes initial copy of `properties.ini` lacking `jobid` 2. `submit` submits the job to SLURM 3. job starts and `run` reads `properties.ini` 4. `submit` writes updated `properties.ini` with `jobid` 5. `run` writes `properties.ini` with `checkpointing` at this point `jobid` is lost from `properties.ini` Fixes would be: * add a lock for `properties.ini` which `submit` only release once it has done its final update * submit jobs in ?held? state \(`sbatch --hold`\) and only release them once the final update of properties.ini has happened both will require updates to simfactory?s code. The first option would work without updates to the machine ini files, the second will require extra entries to tell simfactory how to release a job. This could also be used to implement `hold` and `release` commands in simfactory. The first option will require fallback code in case the lock file is left behind \(e.g. wait no longer than 1 minute before assuming a stale lock and going ahead anyway\). The lock file will require at least some level for POSIX conformance from the file system \(namely that file creation and removal is an atomic operation cluster-wide\). This most likely is the reason for occasional strange failures on clusters with jobid being unset. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2888/race-condition-writing-propertiesini-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 25 09:43:18 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 25 Sep 2025 14:43:18 +0000 Subject: [ET Trac] #2482: Inconsistency in Simfactory submission scripts Message-ID: #2482: Inconsistency in Simfactory submission scripts Reporter: Steven R. Brandt Status: wontfix Milestone: Version: Type: bug Priority: major Component: SimFactory Changes (by Roland Haas): status: wontfix (was new) Comment (by Roland Haas): Not enough personpower to really fix this. Current setup is workable enough. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2482/inconsistency-in-simfactory-submission -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 25 09:44:11 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 25 Sep 2025 14:44:11 +0000 Subject: [ET Trac] #2708: Elliptica_ID_Reader fails to compile on macOS Message-ID: #2708: Elliptica_ID_Reader fails to compile on macOS Reporter: Roland Haas Status: resolved Milestone: Version: Type: bug Priority: blocker Component: Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2708/elliptica_id_reader-fails-to-compile-on -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 25 09:49:32 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 25 Sep 2025 14:49:32 +0000 Subject: [ET Trac] #2597: Simfactory on Bridges2 Message-ID: #2597: Simfactory on Bridges2 Reporter: Maria Status: new Milestone: Version: ET_2021_11 Type: task Priority: major Component: Comment (by Roland Haas): Unless objected, I will close this ticket due to inactivity after 2025-10-09 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2597/simfactory-on-bridges2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 30 13:19:31 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 30 Sep 2025 18:19:31 +0000 Subject: [ET Trac] #2889: Outflow uses incorrect `sf_centroid` to compute surface coordinates Message-ID: #2889: Outflow uses incorrect `sf_centroid` to compute surface coordinates Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Outflow incorrectly used `sf_centroid` as the origin point for the spherical surface it computes fluxes on. However for `SphericalSurface` the surface is defined with respect to `sf_origin` via `sf_radius[ind2d]` . This pull request fixes this and also introduces a runtime parameter to chose between `sf_centroid` and `sf_origin`. The former is useful if one also sets `override_radius`if eg the sphericalsurface is really just a tracker position. Thankfully for the common case where there are either a set of spheres centered on on the coordinate origin or spheres following a neutron star via tracking we usually have `sf_origin` and `sf_centroid` being identical. However flow through an apparent horizon would be incorrect. I would suspect that `sf_origin` is the centroid of the previous horizon find result. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2889/outflow-uses-incorrect-sf_centroid-to -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 30 13:19:41 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 30 Sep 2025 18:19:41 +0000 Subject: [ET Trac] #2889: Outflow uses incorrect `sf_centroid` to compute surface coordinates Message-ID: #2889: Outflow uses incorrect `sf_centroid` to compute surface coordinates Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Pull request is here: [https://bitbucket.org/einsteintoolkit/einsteinanalysis/pull-requests/25](https://bitbucket.org/einsteintoolkit/einsteinanalysis/pull-requests/25) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2889/outflow-uses-incorrect-sf_centroid-to -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 30 13:20:02 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 30 Sep 2025 18:20:02 +0000 Subject: [ET Trac] #2889: Outflow uses incorrect `sf_centroid` to compute surface coordinates Message-ID: #2889: Outflow uses incorrect `sf_centroid` to compute surface coordinates Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2889/outflow-uses-incorrect-sf_centroid-to -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 30 13:21:14 2025 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 30 Sep 2025 18:21:14 +0000 Subject: [ET Trac] #2889: Outflow uses incorrect `sf_centroid` to compute surface coordinates Message-ID: #2889: Outflow uses incorrect `sf_centroid` to compute surface coordinates Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2889/outflow-uses-incorrect-sf_centroid-to -------------- next part -------------- An HTML attachment was scrubbed... URL: