From trac-noreply at einsteintoolkit.org Sat Nov 2 11:15:52 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Sat, 02 Nov 2024 16:15:52 +0000 Subject: [ET Trac] #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Message-ID: #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Reporter: Roland Haas Status: new Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn In git hash [51e0572e](https://github.com/einsteintoolkit/CarpetX/commits/51e0572eeb67390885431e66cb43ad8b4dc728b0) "CarpetX: ADIOS2: Use Blosc compression by default" of [CarpetX](https://github.com/einsteintoolkit/CarpetX) it started to require BLOSC which is however an external library not included in the ET. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-on-blosc-support-in-adios2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Sat Nov 2 11:16:17 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Sat, 02 Nov 2024 16:16:17 +0000 Subject: [ET Trac] #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Message-ID: #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Reporter: Roland Haas Status: new Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Comment (by Roland Haas): Pull request is here: [https://github.com/EinsteinToolkit/CarpetX/pull/314](https://github.com/EinsteinToolkit/CarpetX/pull/314) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-on-blosc-support-in-adios2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Sat Nov 2 11:16:36 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Sat, 02 Nov 2024 16:16:36 +0000 Subject: [ET Trac] #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Message-ID: #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Reporter: Roland Haas Status: new Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Comment (by Roland Haas): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-on-blosc-support-in-adios2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Sat Nov 2 13:51:55 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Sat, 02 Nov 2024 18:51:55 +0000 Subject: [ET Trac] #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Message-ID: #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Reporter: Roland Haas Status: new Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Comment (by Roland Haas): Applied as git hash [91535d21](https://github.com/einsteintoolkit/CarpetX/commits/91535d2181148bd70abf30174b4584c352848966) "CarpetX: only use BLOSC2 if compiled into ADIOS2" of [CarpetX](https://github.com/einsteintoolkit/CarpetX) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-on-blosc-support-in-adios2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Sat Nov 2 13:52:21 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Sat, 02 Nov 2024 18:52:21 +0000 Subject: [ET Trac] #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Message-ID: #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Reporter: Roland Haas Status: resolved Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-on-blosc-support-in-adios2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Sun Nov 3 11:31:03 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Sun, 03 Nov 2024 17:31:03 +0000 Subject: [ET Trac] #2818: failing tests with gcc-14 Message-ID: #2818: failing tests with gcc-14 Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): The issue seems to be related to `loop.hxx` and its code: ```c++ 190 const PointDesc p = 191 point_desc({CI, CJ, CK}, I, iter, NI, I0, BI, bnd_min, bnd_max, 192 loop_min, loop_max); ``` where the first arguments gets passed as `vect&`. Changing to code to have an explicit variable: ``` const vect _CI{CI,CJ,CK}; ``` and passing that one for the first argument makes the tests pass. Without the explicit variable gcc-14 emits a warning: ```text In lambda function, inlined from ?constexpr std::array<_Tp, _Nm> Arith::construct_array(const F&) [with T = bool; long unsigned int N = 1; F = vect::vect(std::initializer_list)::]? at /data/rhaas/postdoc/gr/cactus/ET_trunk /arrangements/CarpetX/Arith/src/vect.hxx:94:57, inlined from ?constexpr std::array<_Tp, _Nm> Arith::construct_array(const F&) [with T = bool; long unsigned int N = 2; F = vect::vect(std::initializer_list)::]? at /data/rhaas/postdoc/gr/cactus/ET_trunk /arrangements/CarpetX/Arith/src/vect.hxx:94:51, inlined from ?constexpr std::array<_Tp, _Nm> Arith::construct_array(const F&) [with T = bool; long unsigned int N = 3; F = vect::vect(std::initializer_list)::]? at /data/rhaas/postdoc/gr/cactus/ET_trunk /arrangements/CarpetX/Arith/src/vect.hxx:94:51, inlined from ?constexpr Arith::vect::vect(std::initializer_list<_Tp>) [with T = bool; int D = 3]? at /data/rhaas/postdoc/gr/cactus/ET_trunk/arrangements/CarpetX/Arith/src/vect.hxx:139:35, inlined from ?void Loop::GridDescBase::loop_box(const Arith::vect&, const Arith::vect&, const Arith::vect&, const Arith::vect&, const F&) const [with int CI = 1; int CJ = 1; int CK = 1; int VS = 1; int N = 1; F = TestProlongate::TestProlongate_Regrid(cGH*)::]? at /data/rhaas/postdoc/gr/cactus/ET_trunk/arrangements/CarpetX/Loop/src/loop.hxx:191:27, inlined from ?void Loop::GridDescBase::loop_int(const Arith::vect&, const F&) const [with int CI = 1; int CJ = 1; int CK = 1; int VS = 1; int N = 1; F = TestProlongate::TestProlongate_Regrid(cGH*)::]? at /data/rhaas/postdoc/gr/cactus/ET_trunk/arrangements/CarpetX/Loop/src/loop.hxx:276:32, inlined from ?std::enable_if_t<(where == Loop::where_t::interior), void> Loop::GridDescBase::loop(const Arith::vect&, const F&) const [with int CI = 1; int CJ = 1; int CK = 1; Loop::where_t where = Loop::where_t::interior; F = TestProlongate::TestProlongate_Regrid(cGH*)::]? at /data/rhaas/postdoc/gr/cactus/ET_trunk/arrangements/CarpetX/Loop/src/loop.hxx:650:25, inlined from ?void Loop::GridDescBase::loop(const F&) const [with int CI = 1; int CJ = 1; int CK = 1; Loop::where_t where = Loop::where_t::interior; F = TestProlongate::TestProlongate_Regrid(cGH*)::]? at /data/rhaas/postdoc/gr/cactus/ET_trunk/arrangements/CarpetX/Loop/src/loop.hxx:711:28, inlined from ?void Loop::loop(const cGH*, const F&) [with int CI = 1; int CJ = 1; int CK = 1; where_t where = Loop::where_t::interior; F = TestProlongate::TestProlongate_Regrid(cGH*)::]? at /data/rhaas/postdoc/gr/cactus/ET_trunk/arrangements/CarpetX/Loop/src/loop.hxx:770:47, inlined from ?void Loop::loop_int(const cGH*, const F&) [with int CI = 1; int CJ = 1; int CK = 1; F = TestProlongate::TestProlongate_Regrid(cGH*)::]? at /data/rhaas/postdoc/gr/cactus/ET_trunk/arrangements/CarpetX/Loop/src/loop.hxx:786:38, inlined from ?void TestProlongate::TestProlongate_Regrid(cGH*)? at /data/rhaas/postdoc/gr/cactus/ET_trunk/configs/tests/build/TestProlongate/test.cxx:236:26: /data/rhaas/postdoc/gr/cactus/ET_trunk/arrangements/CarpetX/Arith/src/vect.hxx:143:31: warning: ?? may be used uninitialized [-Wmaybe-uninitialized] 143 | return lst.begin()[d]; | ^ /data/rhaas/postdoc/gr/cactus/ET_trunk/arrangements/CarpetX/Loop/src/loop.hxx: In function ?void TestProlongate::TestProlongate_Regrid(cGH*)?: /data/rhaas/postdoc/gr/cactus/ET_trunk/arrangements/CarpetX/Loop/src/loop.hxx:177:9: note: ?? declared here 177 | #pragma omp simd | ^~~ ``` So this change: ```diff diff --git a/Loop/src/loop.hxx b/Loop/src/loop.hxx index 0aaa290c..0cb82580 100644 --- a/Loop/src/loop.hxx +++ b/Loop/src/loop.hxx @@ -187,8 +187,9 @@ public: // Outward boundary normal (if on outermost interior point), else 0 const vect BI = vect(I == bnd_max - 1) - vect(I == bnd_min); + const vect _CI{CI, CJ, CK}; const PointDesc p = - point_desc({CI, CJ, CK}, I, iter, NI, I0, BI, bnd_min, bnd_max, + point_desc(_CI, I, iter, NI, I0, BI, bnd_min, bnd_max, loop_min, loop_max); f(p); } ``` makes the tests pass, though I am not quite sure why. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2818/failing-tests-with-gcc-14 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Sun Nov 3 11:31:21 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Sun, 03 Nov 2024 17:31:21 +0000 Subject: [ET Trac] #2818: failing tests with gcc-14 Message-ID: #2818: failing tests with gcc-14 Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): responsible: [] (was ) assignee: Roland Haas (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2818/failing-tests-with-gcc-14 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Sun Nov 3 11:52:11 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Sun, 03 Nov 2024 17:52:11 +0000 Subject: [ET Trac] #2818: failing tests with gcc-14 Message-ID: #2818: failing tests with gcc-14 Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): @{557058:56049c54-f8c2-4b6c-9b88-ab697c967495} do you have any idea if this a bug in gcc-14 and I am just perturbing it out of existence or if there really is something wrong with constructing a temporary `vect` in place when calling `point_desc`? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2818/failing-tests-with-gcc-14 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Sun Nov 3 18:00:53 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Mon, 04 Nov 2024 00:00:53 +0000 Subject: [ET Trac] #2831: ExternalLibraries/MPI creates MPI_INC_DIRS that have double quotes in their value Message-ID: #2831: ExternalLibraries/MPI creates MPI_INC_DIRS that have double quotes in their value Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn ExternalLibraries/MPI?s `detect.pl` script creates entries in `make.MPI.defn` like this \(on stampede3\): ``` MPI_DIR = /opt/intel/oneapi/mpi/2021.11 MPI_INC_DIRS = "/opt/intel/oneapi/mpi/2021.11/include" MPI_LIB_DIRS = "/opt/intel/oneapi/mpi/2021.11/lib" MPI_LIBS = mpicxx mpifort mpi rt pthread dl ``` which is incorrect since make makes the double quotes part of the variables value. This is usually safe when used in the shell since `-L"Foo"` is the same as `-LFoo` but fails with Silo which stores the options in a string \(and does not escape embedded quotes\). Since make does not handle spaces well anyway `detect.pl` should not output any quotes since the paths will never contain one. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2831/externallibraries-mpi-creates-mpi_inc_dirs -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Nov 4 08:15:20 2024 From: trac-noreply at einsteintoolkit.org (Erik Schnetter) Date: Mon, 04 Nov 2024 14:15:20 +0000 Subject: [ET Trac] #2818: failing tests with gcc-14 Message-ID: #2818: failing tests with gcc-14 Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Erik Schnetter): I don?t know. It might be that the compiler doesn?t know that we?re constructing a vector of size 3 and is worried that there might be uninitialized entries if we construct a larger vector. If you want to apply the change, can you rename the new variable? Variable names starting with an underscore and then an upper case letter shouldn?t be used by an application. I usually append a `1` at the end instead. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2818/failing-tests-with-gcc-14 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Nov 4 08:53:50 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Mon, 04 Nov 2024 14:53:50 +0000 Subject: [ET Trac] #2818: failing tests with gcc-14 Message-ID: #2818: failing tests with gcc-14 Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Yes, I will rename the variable. Yes, `_FOO` is reserved by compiler / standard library I think. The thing that has me worried is that with the change in the diff the tests all pass with gcc-14 \(well other than ones that are failing for reasons such as schedule issues or hwloc not liking my efficiency cores in my workstation\) but without the change many tests in CarpetX fail. All the failing CarpetX tests also pass if I compile with gcc-13 instead of gcc-14. gcc-14 produces some other warnings \(like reporting that index -1 is out of bounds for a `double foo[3]` vector, which is true\) but I have a harder time finding out exactly what line triggers it. So this seems like I am just perturbing something out of existence. I?ll propose a the change in a pull request. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2818/failing-tests-with-gcc-14 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Nov 4 10:36:19 2024 From: trac-noreply at einsteintoolkit.org (Erik Schnetter) Date: Mon, 04 Nov 2024 16:36:19 +0000 Subject: [ET Trac] #2818: failing tests with gcc-14 Message-ID: #2818: failing tests with gcc-14 Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Erik Schnetter): `vect` objects are created via this mechanism \(see \`vect.hxx1\): ```c++ template constexpr ARITH_INLINE ARITH_DEVICE ARITH_HOST std::array construct_array(const F &f) { if constexpr (N == 0) return std::array(); if constexpr (N > 0) return array_push(construct_array(f), f(N - 1)); } ``` Maybe the compiler is getting confused by the `constexpr` expressions and accidentally evaluates the second `if` statement? That?s the only `- 1` that I see. If so, you could try splitting the function into two, with an `enable_if` condition checking `N==0` and `N>0`, and removing the `if constexpr` statements from the bodies. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2818/failing-tests-with-gcc-14 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Nov 4 10:41:21 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Mon, 04 Nov 2024 16:41:21 +0000 Subject: [ET Trac] #2818: failing tests with gcc-14 Message-ID: #2818: failing tests with gcc-14 Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): will do. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2818/failing-tests-with-gcc-14 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 08:23:57 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 Nov 2024 14:23:57 +0000 Subject: [ET Trac] #2832: possible race condition in LoopControl Message-ID: #2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: @{557058:d079f9c2-ad27-47b2-bf4b-ecc6bbe288b0} reported an issue where SEGFAULTs are triggered from within LoopControl. I can reproduce this using the thornlist and parameter file that Yosef provided. I use the attached option list, where using `-std=gnu++11` instead of `-std=c++17 -D_GNU_SOURCE` is required for the issue to show up for me. I run using ``` export OMP_NUM_THREADS=2 exe/cactus_yosef test.par ``` and the CPU on my workstation is a ?12th Gen Intel\(R\) Core\(TM\) i7-12700? attachment: OptionList (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2832/attachments/OptionList) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-condition-in-loopcontrol -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 08:24:45 2024 From: trac-noreply at einsteintoolkit.org (Erik Schnetter) Date: Tue, 05 Nov 2024 14:24:45 +0000 Subject: [ET Trac] #2833: Null pointer dereference in AEILocalInterp Message-ID: #2833: Null pointer dereference in AEILocalInterp Reporter: Erik Schnetter Status: new Milestone: Version: Type: bug Priority: critical Component: EinsteinToolkit thorn See the correction at [https://bitbucket.org/cactuscode/numerical/pull-requests/1](https://bitbucket.org/cactuscode/numerical/pull-requests/1) . This bug is triggered by AHFinderDirect. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2833/null-pointer-dereference-in-aeilocalinterp -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 08:26:35 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 Nov 2024 14:26:35 +0000 Subject: [ET Trac] #2832: possible race condition in LoopControl Message-ID: #2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): The issue may be alignment related. gcc-14 produces a warning: ``` COMPILING Carpet/LoopControl/src/loopcontrol.cc /data/rhaas/postdoc/gr/cactus/ET_trunk/configs/yosef/build/LoopControl/loopcontrol.cc: In function ?voi LC_control_init(lc_control_t*, lc_descr_t*, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t)?: /data/rhaas/postdoc/gr/cactus/ET_trunk/configs/yosef/build/LoopControl/loopcontrol.cc:797:29: warning: new? of type ?lc_thread_info_t? with extended alignment 128 [-Waligned-new=] 797 | { thread_info_ptr = new lc_thread_info_t; } | ^~~~~~~~~~~~~~~~ /data/rhaas/postdoc/gr/cactus/ET_trunk/configs/yosef/build/LoopControl/loopcontrol.cc:797:29: note: uses ?void* operator new(std::size_t)?, which does not have an alignment parameter /data/rhaas/postdoc/gr/cactus/ET_trunk/configs/yosef/build/LoopControl/loopcontrol.cc:797:29: note: use ?-faligned-new? to enable C++17 over-aligned new support ``` and changing LoopControl like this: ```diff diff --git a/LoopControl/src/loopcontrol.cc b/LoopControl/src/loopcontrol.cc index a2e3460f2..062db9c1f 100644 --- a/LoopControl/src/loopcontrol.cc +++ b/LoopControl/src/loopcontrol.cc @@ -71,12 +71,16 @@ static minstd_rand::result_type const constexpr lc_random_range = struct lc_thread_info_t { volatile int idx; // linear index of next coarse thread block -} CCTK_ATTRIBUTE_ALIGNED(128); // align to prevent sharing cache lines + char pad[128 - sizeof(int)]; // align to prevent sharing cache lines +}; +static_assert(sizeof(lc_thread_info_t) == 128, "Incorrect size for alignment"); struct lc_fine_thread_comm_t { volatile int state; // waiting threads volatile int value; // broadcast value -} CCTK_ATTRIBUTE_ALIGNED(128); // align to prevent sharing cache lines + char pad[128-2*sizeof(int)]; // align to prevent sharing cache lines +}; +static_assert(sizeof(lc_fine_thread_comm_t) == 128, "Incorrect size for alignment"); // One object per coarse thread: shared between fine threads // Note: Since we use a vector, the individual elements may not ``` makes the issue go away. Note that this may not actually give alignment to 128 bytes as originally requested. However the comments make it clear that alignment was never the goal, instead the goal was to spread out consecutive `lc_fine_thread_comm_t` across multiple cache lines, which making them big enough should also achieve. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-condition-in-loopcontrol -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 08:39:50 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 Nov 2024 14:39:50 +0000 Subject: [ET Trac] #2833: Null pointer dereference in AEILocalInterp Message-ID: #2833: Null pointer dereference in AEILocalInterp Reporter: Erik Schnetter Status: new Milestone: Version: Type: bug Priority: critical Component: EinsteinToolkit thorn Comment (by Roland Haas): Non-matching code style but the change itself seems fine. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2833/null-pointer-dereference-in-aeilocalinterp -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 08:41:38 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 Nov 2024 14:41:38 +0000 Subject: [ET Trac] #2833: Null pointer dereference in AEILocalInterp Message-ID: #2833: Null pointer dereference in AEILocalInterp Reporter: Erik Schnetter Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): responsible: [] (was ) priority: major (was critical) assignee: Roland Haas (was ) Comment (by Roland Haas): reduce severity to ?major? since ?critical? is ?At least one important thorn cannot be used, or something else is severely broken. If this is not addressed quickly, the respective change should be reverted.? \([https://docs.einsteintoolkit.org/et-docs/Tickets#Priority](https://docs.einsteintoolkit.org/et-docs/Tickets#Priority)\) which does not seem to be the case here given that AFinderDirect?s test suites pass. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2833/null-pointer-dereference-in-aeilocalinterp -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 08:42:57 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 Nov 2024 14:42:57 +0000 Subject: [ET Trac] #2833: Null pointer dereference in AEILocalInterp Message-ID: #2833: Null pointer dereference in AEILocalInterp Reporter: Erik Schnetter Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Any chance to redo the change to match AHFinderDirect?s style as outlined in [https://bitbucket.org/einsteintoolkit/einsteinanalysis/src/master/AHFinderDirect/src/CODESTYLE](https://bitbucket.org/einsteintoolkit/einsteinanalysis/src/master/AHFinderDirect/src/CODESTYLE) ? If not I?ll give that a try myself. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2833/null-pointer-dereference-in-aeilocalinterp -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 08:43:52 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 Nov 2024 14:43:52 +0000 Subject: [ET Trac] #2833: Null pointer dereference in AEILocalInterp Message-ID: #2833: Null pointer dereference in AEILocalInterp Reporter: Erik Schnetter 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/2833/null-pointer-dereference-in-aeilocalinterp -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 09:05:59 2024 From: trac-noreply at einsteintoolkit.org (Erik Schnetter) Date: Tue, 05 Nov 2024 15:05:59 +0000 Subject: [ET Trac] #2833: Null pointer dereference in AEILocalInterp Message-ID: #2833: Null pointer dereference in AEILocalInterp Reporter: Erik Schnetter Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Erik Schnetter): This coding style is quite peculiar. Did you realize it?s not hierarchical? For example, the indentation does not separate two consecutive loops. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2833/null-pointer-dereference-in-aeilocalinterp -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 09:10:51 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 Nov 2024 15:10:51 +0000 Subject: [ET Trac] #2818: failing tests with gcc-14 Message-ID: #2818: failing tests with gcc-14 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/2818/failing-tests-with-gcc-14 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 09:29:05 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 Nov 2024 15:29:05 +0000 Subject: [ET Trac] #1566: Update Cactus autoconf Message-ID: #1566: Update Cactus autoconf Reporter: Erik Schnetter Status: new Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): Pull request is here: [https://bitbucket.org/cactuscode/cactus/pull-requests/167](https://bitbucket.org/cactuscode/cactus/pull-requests/167) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1566/update-cactus-autoconf -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 09:29:16 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 Nov 2024 15:29:16 +0000 Subject: [ET Trac] #1566: Update Cactus autoconf Message-ID: #1566: Update Cactus autoconf Reporter: Erik Schnetter Status: new Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): Please review -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1566/update-cactus-autoconf -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 09:30:42 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 Nov 2024 15:30:42 +0000 Subject: [ET Trac] #1566: Update Cactus autoconf Message-ID: #1566: Update Cactus autoconf Reporter: Erik Schnetter Status: new Milestone: Version: development version Type: enhancement Priority: major Component: Cactus Changes (by Roland Haas): responsible: [] (was ) kind: enhancement (was bug) priority: major (was minor) assignee: Roland Haas (was ) We are using autoconf 2.13 for Cactus. This release is by now 15 years old and doesn't support Fortran (nor modern C++ features). It is time to update. **Keyword:** -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1566/update-cactus-autoconf -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 09:37:08 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 Nov 2024 15:37:08 +0000 Subject: [ET Trac] #2833: Null pointer dereference in AEILocalInterp Message-ID: #2833: Null pointer dereference in AEILocalInterp Reporter: Erik Schnetter Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Yes, I am not claiming it is coding style I would promote outside of AHFinderDirect. I am only asking about this in order to keep the files in AHFinderDirect themselves consistent. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2833/null-pointer-dereference-in-aeilocalinterp -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 09:51:52 2024 From: trac-noreply at einsteintoolkit.org (Erik Schnetter) Date: Tue, 05 Nov 2024 15:51:52 +0000 Subject: [ET Trac] #2832: possible race condition in LoopControl Message-ID: #2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Erik Schnetter): As you say, your padding doesn?t actually align the struct. The struct may thus be split across two cache lines. Since some architectures have 128-byte cache lines, you should instead pad to 2\*128 bytes. \(Intel CPUs have 64-byte cache lines and thus 128 bytes suffice there.\) You can instead also check the alignment \(see [https://en.cppreference.com/w/c/language/\_Alignof](https://en.cppreference.com/w/c/language/_Alignof)\) with a static assertion. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-condition-in-loopcontrol -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 10:02:33 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 Nov 2024 16:02:33 +0000 Subject: [ET Trac] #2832: possible race condition in LoopControl Message-ID: #2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Oh, right. So that won?t quite prevent cache line sharing. Unfortunately I cannot check alignment with a static assert since both types are allocated dynamically \(`lc_thread_info_t` via a `new` the other as part of a `std::vector` \(and I?d have no idea how that one would have interacted with the `CCTK_ATTRIBUTE_ALIGNED(128)`\). So I guess it would have to be using 2\*128 or at least 2 times the cache line size if that one is know at compile time. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-condition-in-loopcontrol -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 10:14:54 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 Nov 2024 16:14:54 +0000 Subject: [ET Trac] #2832: possible race condition in LoopControl Message-ID: #2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): There?s `alignas` since C\+\+11: [https://en.cppreference.com/w/cpp/language/alignas](https://en.cppreference.com/w/cpp/language/alignas) though this may not be any different from `CCTK_ATTRIBUTE_ALIGN` and indeed ``` #include struct alignas(128) aligned_t { volatile int foo; }; std::vector test_aligned_vector; aligned_t *aligned; void foo() { aligned = new aligned_t(); } ``` gives the same warning when compiled with `g++ -std=gnu++11 -c -Wall` \(only warns about `new` not about `std::vector` but I suspect that `std::vector` also does not align and only hides the issue because it internally uses a `void*` pointer for its storage\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-condition-in-loopcontrol -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 10:58:30 2024 From: trac-noreply at einsteintoolkit.org (Erik Schnetter) Date: Tue, 05 Nov 2024 16:58:30 +0000 Subject: [ET Trac] #2832: possible race condition in LoopControl Message-ID: #2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Erik Schnetter): Ah yes, silly me. We should be using `posix_memalign`. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-condition-in-loopcontrol -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 11:19:54 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 Nov 2024 17:19:54 +0000 Subject: [ET Trac] #2832: possible race condition in LoopControl Message-ID: #2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Right, I was thinking of it but did not consider it as likely to pass the smell test. Namely: how to nicely combine that one with `std::vector`? Works fine to replace the naked `new` of course. For the `std::vector` one would use something like this: ``` lc_fine_thread_comm_t lc_fine_thread_comm = nulltpr; [...] if (!lc_fine_thread_comm) { lc_fine_thread_comm = static_cast(posix_memalign(n*sizeof(*lc_fine_thread_comm), 128)); for(size_t i = 0 ; i < n ; ++i) { lc_fine_thread_comm_t* ptr = new (lc_fine_thread_comm+i) lc_fine_thread_comm_t(); assert(ptr == lc_fine_thread_comm+i); // apparently not guaranteed } } ``` and similar awkwardness if we ever were to `free` the array. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-condition-in-loopcontrol -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 11:26:30 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 Nov 2024 17:26:30 +0000 Subject: [ET Trac] #2832: possible race condition in LoopControl Message-ID: #2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Minor point: Padding size wise I think just adding and _extra_ 128 bytes \(or whatever the cache line size is\) instead of padding to 256 \(twice the cache line size\) should be sufficient to ensure that there are no shared cache lines since even in the worst case scenario where the first structure member is a the very end of a cache line padding by a full cache line size skips into the next cache line for the next array member \(which will start somewhere near the beginning of its cache line of then\). `posix_memalign` might be more efficient. Would still need a comment like right now since we do not want alignment but separation. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-condition-in-loopcontrol -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 11:56:15 2024 From: trac-noreply at einsteintoolkit.org (Erik Schnetter) Date: Tue, 05 Nov 2024 17:56:15 +0000 Subject: [ET Trac] #2832: possible race condition in LoopControl Message-ID: #2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Erik Schnetter): We don?t need `new` or `std::vector`. We replace the call to `new` with `posix_memalign`, and the call to `delete` by `free`. Then each thread has one cache line as intended. Alternatively, there could be one call to `posix_memalign` allocating memory for all threads, and each thread uses pointer arithmetic to find its place. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-condition-in-loopcontrol -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 14:15:42 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 Nov 2024 20:15:42 +0000 Subject: [ET Trac] #2832: possible race condition in LoopControl Message-ID: #2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Like so: [https://github.com/EinsteinToolkit/Carpet/pull/11](https://github.com/EinsteinToolkit/Carpet/pull/11) ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-condition-in-loopcontrol -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 15:20:04 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 Nov 2024 21:20:04 +0000 Subject: [ET Trac] #2832: possible race condition in LoopControl Message-ID: #2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Applied as git hash [ff99c0d16](https://github.com/einsteintoolkit/Carpet/commits/ff99c0d16feb6282edb0b21f2151a520d4a63d0d) "LoopControl: replace **allign** with posix\_memalign" of [Carpet](https://github.com/einsteintoolkit/Carpet) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-condition-in-loopcontrol -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 15:20:49 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 05 Nov 2024 21:20:49 +0000 Subject: [ET Trac] #2832: possible race condition in LoopControl Message-ID: #2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): @{557058:d079f9c2-ad27-47b2-bf4b-ecc6bbe288b0} could you give this a try, please? It removes the SEGFAULT for me, but then this being a Heisenberg type bug, this may be accidental. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-condition-in-loopcontrol -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 5 16:23:50 2024 From: trac-noreply at einsteintoolkit.org (Yosef Zlochower) Date: Tue, 05 Nov 2024 22:23:50 +0000 Subject: [ET Trac] #2832: possible race condition in LoopControl Message-ID: #2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Yosef Zlochower): I am not getting segfaults so far with the new code. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-condition-in-loopcontrol -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Nov 6 14:29:51 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 Nov 2024 20:29:51 +0000 Subject: [ET Trac] #2503: Various small problems with FishboneMoncriefID Message-ID: #2503: Various small problems with FishboneMoncriefID Reporter: Gabriele Bozzola Status: open Milestone: ET_2023_05 Version: development version Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): The milestone ET\_2023\_05 having passed on this: Any progress on this? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2503/various-small-problems-with -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Nov 6 14:31:23 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 Nov 2024 20:31:23 +0000 Subject: [ET Trac] #2645: Major update to Baikal/BaikalVacuum Message-ID: #2645: Major update to Baikal/BaikalVacuum Reporter: Zach Etienne Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): Has this been merged \(2 years ago\)? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2645/major-update-to-baikal-baikalvacuum -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Nov 6 14:31:41 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 Nov 2024 20:31:41 +0000 Subject: [ET Trac] #2633: SummationByPart's Diff_gv aliased function does ont document which part of the grid the computed derivative is valid Message-ID: #2633: SummationByPart's Diff_gv aliased function does ont document which part of the grid the computed derivative is valid Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: Comment (by Roland Haas): Any updates on this? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2633/summationbyparts-diff_gv-aliased-function -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Nov 6 14:37:26 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 Nov 2024 20:37:26 +0000 Subject: [ET Trac] #2591: New `CENTERING` syntax not documented Message-ID: #2591: New `CENTERING` syntax not documented Reporter: Erik Schnetter Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Roland Haas): It?s experimental, and subject to change. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2591/new-centering-syntax-not-documented -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Nov 6 14:38:38 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 Nov 2024 20:38:38 +0000 Subject: [ET Trac] #2576: `after` statements in scheduler in `IllinoisGRMHD` Message-ID: #2576: `after` statements in scheduler in `IllinoisGRMHD` Reporter: Gabriele Bozzola Status: new Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Zach, I assume this can be closed since the thorn called ?IllinoisGRMHD? now does not share code with the ?IllinoisGRMHD? in use when Gabriele reported this issue? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2576/after-statements-in-scheduler-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Nov 6 14:45:00 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 Nov 2024 20:45:00 +0000 Subject: [ET Trac] #2069: connection failures to svn.cactuscode.org Message-ID: #2069: connection failures to svn.cactuscode.org Reporter: Roland Haas Status: wontfix Milestone: Version: development version Type: bug Priority: minor Component: EinsteinToolkit website Changes (by Roland Haas): status: wontfix (was open) I am getting connection failures to svn.cactuscode.org using svn 1.9.7 on Debian buster (which is starting to phase out tls 1.0 and 1.1 support https://lists.debian.org/debian-devel-announce/2017/08/msg00004.html). Namely I get: ET_Hack$ svn checkout https://svn.cactuscode.org/projects/ExternalLibraries/zlib/ svn: E170013: Unable to connect to a repository at URL 'https://svn.cactuscode.org/projects/ExternalLibraries/zlib' svn: E120171: Error running context: An error occurred during SSL communication and openssl shows: ET_Hack$ openssl s_client -connect svn.cactuscode.org:443 CONNECTED(00000003) 140481992824064:error:14171102:SSL routines:tls_process_server_hello:unsupported protocol:../ssl/statem/statem_clnt.c:917: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 86 bytes and written 183 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1503529726 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- systems which still allow tls1.0 (eg the QueenBee login nodes) return $ openssl s_client -connect svn.cactuscode.org:443 depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root verify return:1 depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority verify return:1 depth=1 C = US, ST = MI, L = Ann Arbor, O = Internet2, OU = InCommon, CN = InCommon RSA Server CA verify return:1 depth=0 C = US, postalCode = 70803, ST = Louisiana, L = Baton Rouge, street = 110 Thomas Boyd, O = Louisiana State University, OU = LSU A & M, CN = svn.cactuscode.org verify return:1 CONNECTED(00000003) --- Certificate chain 0 s:/C=US/postalCode=70803/ST=Louisiana/L=Baton Rouge/street=110 Thomas Boyd/O=Louisiana State University/OU=LSU A & M/CN=svn.cactuscode.org i:/C=US/ST=MI/L=Ann Arbor/O=Internet2/OU=InCommon/CN=InCommon RSA Server CA 1 s:/C=US/ST=MI/L=Ann Arbor/O=Internet2/OU=InCommon/CN=InCommon RSA Server CA i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority 2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root --- Server certificate -----BEGIN CERTIFICATE----- MIIGgDCCBWigAwIBAgIQHqWvzUQZraL+FC0Gui4TnTANBgkqhkiG9w0BAQsFADB2 MQswCQYDVQQGEwJVUzELMAkGA1UECBMCTUkxEjAQBgNVBAcTCUFubiBBcmJvcjES MBAGA1UEChMJSW50ZXJuZXQyMREwDwYDVQQLEwhJbkNvbW1vbjEfMB0GA1UEAxMW SW5Db21tb24gUlNBIFNlcnZlciBDQTAeFw0xNTEyMDEwMDAwMDBaFw0xODExMzAy MzU5NTlaMIG3MQswCQYDVQQGEwJVUzEOMAwGA1UEERMFNzA4MDMxEjAQBgNVBAgT CUxvdWlzaWFuYTEUMBIGA1UEBxMLQmF0b24gUm91Z2UxGDAWBgNVBAkTDzExMCBU aG9tYXMgQm95ZDEjMCEGA1UEChMaTG91aXNpYW5hIFN0YXRlIFVuaXZlcnNpdHkx EjAQBgNVBAsMCUxTVSBBICYgTTEbMBkGA1UEAxMSc3ZuLmNhY3R1c2NvZGUub3Jn MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA40EHmQwApNBq6wt6VyZ0 hWbeCpkOkYENmksB9kPtxzVSz0gK26nnPl68wyb3gTLN3qhfkH9rxlPNuQoo9L3q 5WnIAUrPgzz+afP/kXMzeUtD4GdKx4NhSFnOaVE8rimz2EiOAx7BC8uxfT+EOJ3i C07jwSKg8l+1M0SH1BQqjPK8HeVkfAP2jWQVBAThz/TMvs6P9w4yH8aKsUO2DpOw ocRUvEEvYd6cc4ouuJkhCkosw4NUHC5gCuuoJcVo8wuqR1F+aE8qvtG1CKNTkU6M 5QZgPcqQ4ENwM3SJTlSrWIsqebu24NDacmxc32K2CwLeBEQHM5YCKj1UAODAmtZB aBD3w7lVO0odunOWI+E/R9NARSpwyCBBCv43TDPDKp48Nmffaj7nhSRIl4hFxtTW FTC3rkoHL5fuSFWZBNVJDD7iYFsSovDUep9gAAd8szjQQdwdUTIY/ad/xFjS8UX+ Q6myUkLfBDnSQp2lMrDBYmrOBUacwMkFI4gJEyZpWA3RXAZloa8Mmopq8bHthgCN OjMDf7JAsXNo7OP7n3TIe52XVKtaYpK6OVpZelCaY7huYv/5+oZdqk0A4+ij5RBl 4GukstJQcLSErYiyheesAeSBwXMfQch57uhiB/bUL5W5lRE34Ru6gAckTt7E/Uji d9jAJ7K/ISCyp2qn9NDRtycCAwEAAaOCAcYwggHCMB8GA1UdIwQYMBaAFB4Fo3eP bJbiW4dLprSGrHEADOc4MB0GA1UdDgQWBBSuuHX667Gw/EAO8dHJCvbWxYzPHTAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcD AQYIKwYBBQUHAwIwZwYDVR0gBGAwXjBSBgwrBgEEAa4jAQQDAQEwQjBABggrBgEF BQcCARY0aHR0cHM6Ly93d3cuaW5jb21tb24ub3JnL2NlcnQvcmVwb3NpdG9yeS9j cHNfc3NsLnBkZjAIBgZngQwBAgIwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Ny bC5pbmNvbW1vbi1yc2Eub3JnL0luQ29tbW9uUlNBU2VydmVyQ0EuY3JsMHUGCCsG AQUFBwEBBGkwZzA+BggrBgEFBQcwAoYyaHR0cDovL2NydC51c2VydHJ1c3QuY29t L0luQ29tbW9uUlNBU2VydmVyQ0FfMi5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9v Y3NwLnVzZXJ0cnVzdC5jb20wHQYDVR0RBBYwFIISc3ZuLmNhY3R1c2NvZGUub3Jn MA0GCSqGSIb3DQEBCwUAA4IBAQA8RerhAuPvOngiT4cSmhtiFp+r+i4hXzKB3UwU J3mjgrOQz3AxbmW1A9CyMEPAxtAhM1GdPmSR8T/KeGEE5/We5uVO1SvFpSA8BmsC 7vjirkNLVMlrIrDM89uUwJi5m/i7yupqhoxdReuuz4NP8PJqzOWSaU4uSvU98/Jq 1K5m4dsFdB+cW4EnO70Qv3Htl7AZUZHCNhRvbmtilQcAa+wTTYzBtJFiQ/GufDd8 DSMAa4icWq80UDdilikkt4IiMsFyEHJ0R6Jwppf3VnWD2Z+AtM5wEY6/Z4Loy0nn G/yFK5/d8vXprdFI2D3kfEx7YyMldqUwsfeEmu8Lk5bd4zqN -----END CERTIFICATE----- subject=/C=US/postalCode=70803/ST=Louisiana/L=Baton Rouge/street=110 Thomas Boyd/O=Louisiana State University/OU=LSU A & M/CN=svn.cactuscode.org issuer=/C=US/ST=MI/L=Ann Arbor/O=Internet2/OU=InCommon/CN=InCommon RSA Server CA --- No client certificate CA names sent Server Temp Key: DH, 1024 bits --- SSL handshake has read 5565 bytes and written 445 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 4096 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 02B9ECA6650E99DAB46E41D229C6B6317D5B6649DE5602AAACB85DDA3D4BCB7F Session-ID-ctx: Master-Key: 6A79D044DE035A170C384CFFD2AD5B15B5691D518F04597E9A2BA9ED4A14CE93A18B0AB3D9CF65EC73A913FA7AC364EB Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1503529970 Timeout : 300 (sec) Verify return code: 0 (ok) --- DONE and only fail if tls1.2 is forced: $ openssl s_client -connect svn.cactuscode.org:443 -tls1_2 CONNECTED(00000003) 47690330324936:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:339: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 5 bytes and written 7 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1503530008 Timeout : 7200 (sec) Verify return code: 0 (ok) --- Is there any chance of having LSU update their webserver so that it offer tls 1.2 (around since August 2008)? Note that chances are that Ubuntu (which branches off from Debian unstable regularly) will pick up this change soon affecting the majority of our new Linux ET users. For Debian this is a blocker since it prevents me from even downloading the code. **Keyword:** SSL Comment (by Roland Haas): svn.cactuscode.org no longer exists -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2069/connection-failures-to-svncactuscodeorg -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Nov 6 14:50:07 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 Nov 2024 20:50:07 +0000 Subject: [ET Trac] #2201: included walltime clock in CCTK_VWarn and CCTK_VInfo output Message-ID: #2201: included walltime clock in CCTK_VWarn and CCTK_VInfo output Reporter: Roland Haas Status: invalid Milestone: Version: development version Type: enhancement Priority: minor Component: Cactus Changes (by Roland Haas): status: invalid (was open) To correlate events in Cactus with external events on a cluster (eg IO slowdown, node or network maintenance, network congestion events) it would be useful to (have the option of) including the current time in warning messages output by Cactus, eg something like: HH:MM:SS.CC for hours, minutes, seconds and fractions of seconds (which wraps around at midnight but that should be something that one can figure out). Runtime in seconds would be less useful for this since one then has to check when the run actually started. **Keyword:** None Comment (by Roland Haas): An option for the desired output already exists. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2201/included-walltime-clock-in-cctk_vwarn-and -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Nov 6 14:51:05 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 Nov 2024 20:51:05 +0000 Subject: [ET Trac] #2271: Problem with MPI process Message-ID: #2271: Problem with MPI process Reporter: Status: closed Milestone: Version: Type: bug Priority: minor Component: Changes (by Roland Haas): status: closed (was new) Comment (by Roland Haas): no response by "Former user" -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2271/problem-with-mpi-process -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Nov 6 14:53:05 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 Nov 2024 20:53:05 +0000 Subject: [ET Trac] #2606: Inconsistent LAPACK versions in ExternalLibraries/BLAS & LAPACK Message-ID: #2606: Inconsistent LAPACK versions in ExternalLibraries/BLAS & LAPACK Reporter: Zach Etienne Status: new Milestone: Version: development version Type: bug Priority: minor Component: Comment (by Roland Haas): Zach, will you update the included LAPACK source in BLAS and LAPACK? To the newest one that works? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2606/inconsistent-lapack-versions-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Nov 6 14:58:08 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 Nov 2024 20:58:08 +0000 Subject: [ET Trac] #2282: gallery examples use low-order integration n Multipole Message-ID: #2282: gallery examples use low-order integration n Multipole Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit website Comment (by Roland Haas): This is still an issue. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2282/gallery-examples-use-low-order-integration -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Nov 6 15:04:26 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 Nov 2024 21:04:26 +0000 Subject: [ET Trac] #2688: Include NRPyEOS in next ET release Message-ID: #2688: Include NRPyEOS in next ET release Reporter: Leonardo Werneck Status: new Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Changes (by Roland Haas): Comment (by Roland Haas): Is this still of interest given that GRHayL based IllinoisGRMHD exists? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2688/include-nrpyeos-in-next-et-release -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Nov 6 16:05:26 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 Nov 2024 22:05:26 +0000 Subject: [ET Trac] #2773: make CarpetX-ThornDoc is confused in InterLatex.pl Message-ID: #2773: make CarpetX-ThornDoc is confused in InterLatex.pl Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): Any updates on this? The ?Confused? is from piraha. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2773/make-carpetx-thorndoc-is-confused-in -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Nov 6 16:06:41 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 Nov 2024 22:06:41 +0000 Subject: [ET Trac] #2171: PAPI Compile Issues with Intel 19 beta on Ubuntu 18.04 Message-ID: #2171: PAPI Compile Issues with Intel 19 beta on Ubuntu 18.04 Reporter: Zach Etienne Status: new Milestone: Version: development version Type: bug Priority: minor Component: Other Comment (by Roland Haas): Is this still a concern? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2171/papi-compile-issues-with-intel-19-beta-on -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Nov 6 16:32:37 2024 From: trac-noreply at einsteintoolkit.org (Leonardo Rosa Werneck) Date: Wed, 06 Nov 2024 22:32:37 +0000 Subject: [ET Trac] #2688: Include NRPyEOS in next ET release Message-ID: #2688: Include NRPyEOS in next ET release Reporter: Leonardo Werneck Status: new Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Comment (by Leonardo Rosa Werneck): No, it is not. NRPyEOS is the base of GRHayL?s EOS gem, and no longer needs to be added separately. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2688/include-nrpyeos-in-next-et-release -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Nov 6 16:49:44 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 Nov 2024 22:49:44 +0000 Subject: [ET Trac] #2688: Include NRPyEOS in next ET release Message-ID: #2688: Include NRPyEOS in next ET release Reporter: Leonardo Werneck Status: resolved Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2688/include-nrpyeos-in-next-et-release -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Nov 6 16:49:58 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 06 Nov 2024 22:49:58 +0000 Subject: [ET Trac] #2688: Include NRPyEOS in next ET release Message-ID: #2688: Include NRPyEOS in next ET release Reporter: Leonardo Werneck Status: closed Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Changes (by Roland Haas): status: closed (was resolved) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2688/include-nrpyeos-in-next-et-release -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 09:02:54 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Nov 2024 15:02:54 +0000 Subject: [ET Trac] #2176: Test "Binary neutron star" example Message-ID: #2176: Test "Binary neutron star" example Reporter: Roland Haas Status: resolved Milestone: ET_2024_05 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): responsible: [] (was ) assignee: Maxwell Rizzo (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2176/test-binary-neutron-star-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 09:03:29 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Nov 2024 15:03:29 +0000 Subject: [ET Trac] #2176: Test "Binary neutron star" example Message-ID: #2176: Test "Binary neutron star" example Reporter: Roland Haas Status: resolved Milestone: ET_2024_05 Version: development version Type: task Priority: major Component: EinsteinToolkit website Comment (by Roland Haas): @{712020:002d68cb-a9e4-45eb-9433-93bf55a13168} will test for the 2024\_11 release. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2176/test-binary-neutron-star-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 09:13:08 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Nov 2024 15:13:08 +0000 Subject: [ET Trac] #2176: Test "Binary neutron star" example Message-ID: #2176: Test "Binary neutron star" example Reporter: Roland Haas Status: open Milestone: ET_2024_05 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): status: open (was resolved) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2176/test-binary-neutron-star-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 09:33:40 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Nov 2024 15:33:40 +0000 Subject: [ET Trac] #2832: possible race condition in LoopControl Message-ID: #2832: possible race condition in LoopControl 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/2832/possible-race-condition-in-loopcontrol -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 09:50:19 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Nov 2024 15:50:19 +0000 Subject: [ET Trac] #2833: Null pointer dereference in AEILocalInterp Message-ID: #2833: Null pointer dereference in AEILocalInterp Reporter: Erik Schnetter Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Actually I was confused since the change was for AEILocalInterp. Similar code style though. Steve will approve and I will also approve given the updated pull request. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2833/null-pointer-dereference-in-aeilocalinterp -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 10:02:44 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Nov 2024 16:02:44 +0000 Subject: [ET Trac] #2833: Null pointer dereference in AEILocalInterp Message-ID: #2833: Null pointer dereference in AEILocalInterp Reporter: Erik Schnetter Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Applied as git hash [535f597](https://bitbucket.org/cactuscode/numerical/commits/535f5975d3ee289400c10c7d761035c63a594a87) "AEILocalInterp: Avoid null pointer dereference" of [numerical](https://bitbucket.org/cactuscode/numerical) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2833/null-pointer-dereference-in-aeilocalinterp -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 10:02:56 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Nov 2024 16:02:56 +0000 Subject: [ET Trac] #2833: Null pointer dereference in AEILocalInterp Message-ID: #2833: Null pointer dereference in AEILocalInterp Reporter: Erik Schnetter 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/2833/null-pointer-dereference-in-aeilocalinterp -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 11:45:09 2024 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Thu, 07 Nov 2024 17:45:09 +0000 Subject: [ET Trac] #2503: Various small problems with FishboneMoncriefID Message-ID: #2503: Various small problems with FishboneMoncriefID Reporter: Gabriele Bozzola Status: open Milestone: ET_2023_05 Version: development version Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Zach Etienne): My plan is to port FishboneMoncriefID to NRPy2 \([https://github.com/nrpy/nrpy](https://github.com/nrpy/nrpy)\) and address these issues during the upgrade. Hopefully we can finish this in summer 2025, alongside our push to migrate the nrpytutorial notebooks \([https://github.com/zachetienne/nrpytutorial](https://github.com/zachetienne/nrpytutorial)\) to NRPy2. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2503/various-small-problems-with -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 13:09:26 2024 From: trac-noreply at einsteintoolkit.org (Cheng-Hsin Cheng) Date: Thu, 07 Nov 2024 19:09:26 +0000 Subject: [ET Trac] #2827: TwoPunctures_BBHSF defines new macro outside of the "% START CACTUS THORNGUIDE" block Message-ID: #2827: TwoPunctures_BBHSF defines new macro outside of the "% START CACTUS THORNGUIDE" block Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Cheng-Hsin Cheng): This bug is fixed by the pull request [https://bitbucket.org/canuda/scalar/pull-requests/11](https://bitbucket.org/canuda/scalar/pull-requests/11), which has been merged into master. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2827/twopunctures_bbhsf-defines-new-macro -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 13:21:23 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Nov 2024 19:21:23 +0000 Subject: [ET Trac] #2827: TwoPunctures_BBHSF defines new macro outside of the "% START CACTUS THORNGUIDE" block Message-ID: #2827: TwoPunctures_BBHSF defines new macro outside of the "% START CACTUS THORNGUIDE" block 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/2827/twopunctures_bbhsf-defines-new-macro -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 13:29:59 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Nov 2024 19:29:59 +0000 Subject: [ET Trac] #2172: Test "Binary black hole GW150914" example Message-ID: #2172: Test "Binary black hole GW150914" example Reporter: Roland Haas Status: open Milestone: ET_2024_05 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): status: open (was resolved) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2172/test-binary-black-hole-gw150914-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 13:30:48 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Nov 2024 19:30:48 +0000 Subject: [ET Trac] #2172: Test "Binary black hole GW150914" example Message-ID: #2172: Test "Binary black hole GW150914" example Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): responsible: [] (was []) milestone: ET_2024_11 (was ET_2024_05) assignee: Peter Diener (was Deborah Ferguson) Comment (by Roland Haas): @{557058:f7fd5133-6eee-4385-a5e5-3e03342a0b24} will run the test for 2024\_11 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2172/test-binary-black-hole-gw150914-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 13:31:04 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Nov 2024 19:31:04 +0000 Subject: [ET Trac] #2176: Test "Binary neutron star" example Message-ID: #2176: Test "Binary neutron star" example Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): milestone: ET_2024_11 (was ET_2024_05) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2176/test-binary-neutron-star-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 13:31:13 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Nov 2024 19:31:13 +0000 Subject: [ET Trac] #2175: Test "Single, stable neutron star" example Message-ID: #2175: Test "Single, stable neutron star" example Reporter: Roland Haas Status: open Milestone: ET_2024_05 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): status: open (was resolved) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2175/test-single-stable-neutron-star-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 13:32:14 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Nov 2024 19:32:14 +0000 Subject: [ET Trac] #2175: Test "Single, stable neutron star" example Message-ID: #2175: Test "Single, stable neutron star" example Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): responsible: [] (was []) milestone: ET_2024_11 (was ET_2024_05) assignee: David Boyer (was Maxwell Rizzo) Comment (by Roland Haas): @{712020:f7b71fbc-4964-482c-9ef9-4a5f5b90754b} will run the test for 2024-11 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2175/test-single-stable-neutron-star-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 13:33:35 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Nov 2024 19:33:35 +0000 Subject: [ET Trac] #2174: Test "Multi Patch Scalar Wave Equation" example Message-ID: #2174: Test "Multi Patch Scalar Wave Equation" example Reporter: Roland Haas Status: open Milestone: ET_2024_05 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): status: open (was resolved) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2174/test-multi-patch-scalar-wave-equation -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 13:35:01 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Nov 2024 19:35:01 +0000 Subject: [ET Trac] #2174: Test "Multi Patch Scalar Wave Equation" example Message-ID: #2174: Test "Multi Patch Scalar Wave Equation" example Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): milestone: ET_2024_11 (was ET_2024_05) Comment (by Roland Haas): @{557058:983e20ba-85ac-47d8-a0f1-16f1f6139bcd} will runs this test for 2024-11 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2174/test-multi-patch-scalar-wave-equation -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 13:36:43 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Nov 2024 19:36:43 +0000 Subject: [ET Trac] #2174: Test "Multi Patch Scalar Wave Equation" example Message-ID: #2174: Test "Multi Patch Scalar Wave Equation" example Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): responsible: [] (was []) assignee: William Gabella (was Lucas Timotheo Sanches) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2174/test-multi-patch-scalar-wave-equation -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 13:37:06 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Nov 2024 19:37:06 +0000 Subject: [ET Trac] #2173: Test "Poisson equation" example Message-ID: #2173: Test "Poisson equation" example Reporter: Roland Haas Status: open Milestone: ET_2024_05 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): status: open (was resolved) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2173/test-poisson-equation-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 13:37:48 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Nov 2024 19:37:48 +0000 Subject: [ET Trac] #2173: Test "Poisson equation" example Message-ID: #2173: Test "Poisson equation" example Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): responsible: [] (was []) milestone: ET_2024_11 (was ET_2024_05) assignee: Lucas Timotheo Sanches (was Steven R. Brandt) Comment (by Roland Haas): @{5f2f18c8e8c45600229698f5} will run this for 2024-11 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2173/test-poisson-equation-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 17:10:21 2024 From: trac-noreply at einsteintoolkit.org (David Boyer) Date: Thu, 07 Nov 2024 23:10:21 +0000 Subject: [ET Trac] #2175: Test "Single, stable neutron star" example Message-ID: #2175: Test "Single, stable neutron star" example Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Comment (by David Boyer): @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} I have run the gallery example and everything looks good, same outcome as before. The new runs are tarred up and ready to go. However, I have also rerun the test with the new gauge settings from ticket #2520, and now since I know what I need to do, I could upload those instead if you like, taking out both tickets at the same time. Would this alternative be preferred? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2175/test-single-stable-neutron-star-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 7 18:46:01 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 08 Nov 2024 00:46:01 +0000 Subject: [ET Trac] #2175: Test "Single, stable neutron star" example Message-ID: #2175: Test "Single, stable neutron star" example Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Comment (by Roland Haas): uploading only the new one should be sufficient. Maybe add a comment to #2520 that before you updated the parfile everything looked the same as before to document that the change observed is only due to the changed gauge. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2175/test-single-stable-neutron-star-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Nov 8 08:40:20 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 08 Nov 2024 14:40:20 +0000 Subject: [ET Trac] #2818: failing tests with gcc-14 Message-ID: #2818: failing tests with gcc-14 Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): The negative array index warning is actually from within AMReX: ```text COMPILING CarpetX/CarpetX/src/reduction.cxx In file included from /data/rhaas/postdoc/gr/cactus/ET_Next/configs/sim/scratch/external/AMReX/include/AMReX_Box.H:9, from /data/rhaas/postdoc/gr/cactus/ET_Next/configs/sim/scratch/external/AMReX/include/AMReX_BaseFab.H:9, from /data/rhaas/postdoc/gr/cactus/ET_Next/configs/sim/scratch/external/AMReX/include/AMReX_FArrayBox.H:6, from /data/rhaas/postdoc/gr/cactus/ET_Next/arrangements/CarpetX/Loop/src/loop.hxx:4, from /data/rhaas/postdoc/gr/cactus/ET_Next/configs/sim/bindings/include/loop.hxx:4, from /data/rhaas/postdoc/gr/cactus/ET_Next/arrangements/CarpetX/CarpetX/src/driver.hxx:4, from /data/rhaas/postdoc/gr/cactus/ET_Next/configs/sim/build/CarpetX/reduction.cxx:1: In member function ?constexpr int& amrex::IntVectND::operator[](int) [with int dim = 3]?, inlined from ?amrex::Box amrex::BATbndryReg::operator()(const amrex::Box&) const? at /data/rhaas/postdoc/gr/cactus/ET_Next/configs/sim/scratch/external/AMReX/include/AMReX_BoxArray.H:223:25: /data/rhaas/postdoc/gr/cactus/ET_Next/configs/sim/scratch/external/AMReX/include/AMReX_IntVect.H:240:79: warning: array subscript -1 is below array bounds of ?int [3]? [-Warray-bounds=] 240 | int& operator[] (int i) noexcept { BL_ASSERT(i>=0 && i < dim); return vect[i]; } | ~~~~^ /data/rhaas/postdoc/gr/cactus/ET_Next/configs/sim/scratch/external/AMReX/include/AMReX_IntVect.H: In member function ?amrex::Box amrex::BATbndryReg::operator()(const amrex::Box&) const?: /data/rhaas/postdoc/gr/cactus/ET_Next/configs/sim/scratch/external/AMReX/include/AMReX_IntVect.H:788:9: note: while referencing ?amrex::IntVectND<3>::vect? 788 | int vect[dim] = {}; | ^~~~ ``` and from the output I cannot see who may be calling `amrex::Box amrex::BATbndryReg::operator()(const amrex::Box&)` other than ?somewhere in `reduction.cxx`". -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2818/failing-tests-with-gcc-14 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Nov 8 08:53:19 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 08 Nov 2024 14:53:19 +0000 Subject: [ET Trac] #2818: failing tests with gcc-14 Message-ID: #2818: failing tests with gcc-14 Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Pull request for original issue \(failing tests\) is [https://github.com/EinsteinToolkit/CarpetX/pull/319](https://github.com/EinsteinToolkit/CarpetX/pull/319/files) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2818/failing-tests-with-gcc-14 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Nov 8 10:03:11 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 08 Nov 2024 16:03:11 +0000 Subject: [ET Trac] #2818: failing tests with gcc-14 Message-ID: #2818: failing tests with gcc-14 Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Failing tests have been addressed in git hash [81e426ff](https://github.com/EinsteinToolkit/CarpetX/commits/81e426ffe9bdfe455d249bab5ac3f60a8a861ef2) "Loop: explicitly create function args to avoid compiler issue" of [CarpetX](https://github.com/EinsteinToolkit/CarpetX) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2818/failing-tests-with-gcc-14 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Nov 8 10:35:02 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 08 Nov 2024 16:35:02 +0000 Subject: [ET Trac] #2834: Baikal regeneration instruction in README fail Message-ID: #2834: Baikal regeneration instruction in README fail Reporter: Roland Haas Status: new Milestone: ET_2024_11 Version: Type: bug Priority: major Component: README says: > 4. Regenerating these thorns > > Baikal and BaikalVacuum can be automatically generated via > > pip install git\+[https://github.com/nrpy/nrpy.git at 79774f69b2911fe5729b2d256c7e1fe754c2b3d8](https://github.com/nrpy/nrpy.git at 79774f69b2911fe5729b2d256c7e1fe754c2b3d8) python3 -m nrpy.examples.carpet\_baikal\_thorns > > The second command will generate the thorns in project/et\_baikal/ > and can then be copied into the WVUThorns directory. Yet following these I am missing the `test`, `doc` and `par` directories as well as the `README` file and get very many differences. Most of the differences are harmless \(comments\) but same changes affect `CCTK_ATTRIBUTE_NOINLINE` which, being something that Zach found to be required to cut down compilation time, is important. So currently I cannot regenerate the Baikal thorns. ? attachment: vacuum.diff (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2834/attachments/vacuum.diff) attachment: matter.diff (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2834/attachments/matter.diff) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2834/baikal-regeneration-instruction-in-readme -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Nov 8 11:11:59 2024 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Fri, 08 Nov 2024 17:11:59 +0000 Subject: [ET Trac] #2834: Baikal regeneration instruction in README fail Message-ID: #2834: Baikal regeneration instruction in README fail Reporter: Roland Haas Status: new Milestone: ET_2024_11 Version: Type: bug Priority: major Component: Comment (by Zach Etienne): Largely this is a README issue: Only codes requiring NRPy generation will populate the thorns, so test/ doc/ and par/ will not be populated just by running NRPy. Instead, src/ and \*.ccl files should be deleted in the thorns and replaced with generated codes. The README should be updated to reflect this. In addition, there have been some minor reshufflings to improve maintainability, diagnostics, and performance, including 1. computing the squared momentum constraint \(MSQUAREDGF\). 2. sorting the parameters in param.ccl in a case-insensitive alphabetical way. 3. replacing pow\(x, -1/6\) with 1 / sqrt\(cbrt\(x\)\) \(it is faster!\) 4. Starting all function-level comment blocks with /\*\* instead of /\* . This enables syntax highlighting of @param \[parameter name\] in all IDEs I tried \(emacs & vscode\). 5. simd/simd\_intrinsics.h has been tidied up a bit, and a few new intrinsics \(currently unused by Baikal\*, but used by other \[future ET\] NRPy projects\) were added. The above changes reflect the Baikal\* thorns in the latest `NRPy-main`. Should I proceed in updating the README to use this? There is no functional change. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2834/baikal-regeneration-instruction-in-readme -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Nov 8 13:12:54 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 08 Nov 2024 19:12:54 +0000 Subject: [ET Trac] #2834: Baikal regeneration instruction in README fail Message-ID: #2834: Baikal regeneration instruction in README fail Reporter: Roland Haas Status: new Milestone: ET_2024_11 Version: Type: bug Priority: major Component: Comment (by Roland Haas): These changes are all fine and there is nothing wrong with the generated Baikal\* code updating during the release lifetime. What I am after is to have a way for the release manager and potential Baikal\* users to generate the C code from the original Python code. So that in case one has bug fixes to propose one can actually start from the real source code and not something unknown. Having the full thorn be generated with just a single command is very useful for the release manager since they have to generate very many thorns and if each one required a dozen manual steps \(worst would be ?edit this file ??\), then this becomes very time consuming. The Kranc generated files uniformly require that one does `make` in the the `m` directory which contains the actual source code. RIght now with Baikal it seems that the source used is in `nrpy` and stored in some, to most users, unknown directory in `~/.local` unless one uses a virtualenv. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2834/baikal-regeneration-instruction-in-readme -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Nov 8 13:45:17 2024 From: trac-noreply at einsteintoolkit.org (David Boyer) Date: Fri, 08 Nov 2024 19:45:17 +0000 Subject: [ET Trac] #2520: update gauge settings in TOV example to be more typical Message-ID: #2520: update gauge settings in TOV example to be more typical Reporter: Roland Haas Status: open Milestone: ET_2023_11 Version: development version Type: enhancement Priority: major Component: Comment (by David Boyer): I have ran these tests with the new gauge settings in the current development, and these will be the updated gallery examples for the 11\_2024 release. I will note that before the changes to the parfiles were made, I did test the original gallery example, and the results were the same as before. Any observed changes in the gallery example of these new parfiles came due purely to the change in the gauge settings, as nothing else is different from the original parfiles. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2520/update-gauge-settings-in-tov-example-to-be -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Nov 8 14:18:46 2024 From: trac-noreply at einsteintoolkit.org (David Boyer) Date: Fri, 08 Nov 2024 20:18:46 +0000 Subject: [ET Trac] #2175: Test "Single, stable neutron star" example Message-ID: #2175: Test "Single, stable neutron star" example Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Comment (by David Boyer): @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} I?m trying to upload the results to [https://bitbucket.org/einsteintoolkit/www/downloads/](https://bitbucket.org/einsteintoolkit/www/downloads/), but it?s saying I don?t have write permission and won?t let me upload. It looks like I still don?t have write permission. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2175/test-single-stable-neutron-star-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Nov 8 14:19:26 2024 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Fri, 08 Nov 2024 20:19:26 +0000 Subject: [ET Trac] #2834: Baikal regeneration instruction in README fail Message-ID: #2834: Baikal regeneration instruction in README fail Reporter: Roland Haas Status: new Milestone: ET_2024_11 Version: Type: bug Priority: major Component: Comment (by Zach Etienne): I agree that a Makefile would be most helpful. I?ll just do that. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2834/baikal-regeneration-instruction-in-readme -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Nov 8 14:56:31 2024 From: trac-noreply at einsteintoolkit.org (Zach Etienne) Date: Fri, 08 Nov 2024 20:56:31 +0000 Subject: [ET Trac] #2834: Baikal regeneration instruction in README fail Message-ID: #2834: Baikal regeneration instruction in README fail Reporter: Roland Haas Status: new Milestone: ET_2024_11 Version: Type: bug Priority: major Component: Comment (by Zach Etienne): Fixed in commit 82cde4590a280b477e744f6b5468595c79504b0f . Changelog entry for this commit: ``` Sync Baikal* with NRPy-main and add Makefile-baikal_thorns - Synced WVUThorns/Baikal* with NRPy-main, including: - Implemented computation of the squared momentum constraint (MSQUAREDGF). - Sorted parameters in `param.ccl` in a case-insensitive alphabetical order. - Replaced `pow(x, -1/6)` with `1 / sqrt(cbrt(x))` for enhanced performance. - Updated function-level comment blocks to start with `/**` instead of `/*` to enable `@param` syntax highlighting in IDEs (Emacs & VSCode). - Tidied up `simd/simd_intrinsics.h` and added new intrinsics for future ET NRPy projects. - Added `WVUThorns/Makefile-baikal_thorns` to regenerate Baikal* thorns from a trusted NRPy commit. ``` ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2834/baikal-regeneration-instruction-in-readme -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Nov 11 11:05:11 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Mon, 11 Nov 2024 17:05:11 +0000 Subject: [ET Trac] #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Message-ID: #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Reporter: Roland Haas Status: resolved Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Comment (by Roland Haas): This seems to cause test failures on Anvil, likely due to some leftover option string \(which I had hoped would be harmless\). The first line of the attached log file says that ADIOS2 is continuing without compression but then it still seems to abort: ```text Warning: ADIOS2 backend does not support compression method blosc. Continuing without compression. Original error: [1;36m[Fri Nov 08 21:18:08 2024][1;34m [ADIOS2 EXCEPTION][0m : ADIOS2 didn't compile with blosc library, operator not added[0m Warning: ADIOS2 backend does not support compression method blosc. Continuing without compression. Original error: [1;36m[Fri Nov 08 21:18:08 2024][1;34m [ADIOS2 EXCEPTION][0m : ADIOS2 didn't compile with blosc library, operator not added[0m [a566:2717461] *** An error occurred in MPI_Win_allocate_shared [a566:2717461] *** reported by process [4252828002,1] [a566:2717461] *** on communicator MPI COMMUNICATOR 8 SPLIT FROM 6 [a566:2717461] *** MPI_ERR_INTERN: internal error [a566:2717461] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort, [a566:2717461] *** and potentially your MPI job) In: PMI_Abort(17, N/A) slurmstepd: error: *** STEP 8387965.354 ON a566 CANCELLED AT 2024-11-08T21:18:08 *** srun: Job step aborted: Waiting up to 32 seconds for job step to finish. srun: error: a566: tasks 0-1: Killed ``` ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-on-blosc-support-in-adios2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Nov 11 11:05:42 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Mon, 11 Nov 2024 17:05:42 +0000 Subject: [ET Trac] #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Message-ID: #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Reporter: Roland Haas Status: resolved Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Comment (by Roland Haas): log file from Anvil testsuite run -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-on-blosc-support-in-adios2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Nov 11 11:05:53 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Mon, 11 Nov 2024 17:05:53 +0000 Subject: [ET Trac] #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Message-ID: #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Changes (by Roland Haas): status: open (was resolved) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-on-blosc-support-in-adios2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Nov 11 11:13:44 2024 From: trac-noreply at einsteintoolkit.org (Erik Schnetter) Date: Mon, 11 Nov 2024 17:13:44 +0000 Subject: [ET Trac] #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Message-ID: #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Comment (by Erik Schnetter): I confirm that the solution is to handle the option string in `io_openpmd.cxx` in the same way as the Blosc options in `io_adios2.cxx`, i.e. to use an `#ifdef`. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-on-blosc-support-in-adios2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Nov 11 12:12:42 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Mon, 11 Nov 2024 18:12:42 +0000 Subject: [ET Trac] #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Message-ID: #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Comment (by Roland Haas): Thank you. Somewhat ugly unfortunately. 3 #ifdefs spread over the length of the file. Naturally this runs ok on my workstation. I?ll push the change. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-on-blosc-support-in-adios2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Nov 11 12:31:17 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Mon, 11 Nov 2024 18:31:17 +0000 Subject: [ET Trac] #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Message-ID: #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Comment (by Roland Haas): Somewhat ugly since I inject an ifdef in the string: [https://github.com/EinsteinToolkit/CarpetX/compare/main...rhaas/blosc2](https://github.com/EinsteinToolkit/CarpetX/compare/main...rhaas/blosc2) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-on-blosc-support-in-adios2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Nov 11 12:32:24 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Mon, 11 Nov 2024 18:32:24 +0000 Subject: [ET Trac] #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Message-ID: #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Comment (by Roland Haas): The string is: ``` INFO (CarpetX): options: { "adios2": { "dataset": { "operators": [ { "type": "blosc", "parameters": { "clevel": "9", "doshuffle": "BLOSC_SHUFFLE" } } ] } } } Warning: ADIOS2 backend does not support compression method blosc. Continuing without compression. ``` \(if I fudge things to included it even though I don?t have blosc\). Note the extra empty lines 6 and 14. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-on-blosc-support-in-adios2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Nov 12 09:21:20 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 12 Nov 2024 15:21:20 +0000 Subject: [ET Trac] #2834: Baikal regeneration instruction in README fail Message-ID: #2834: Baikal regeneration instruction in README fail Reporter: Roland Haas Status: resolved Milestone: ET_2024_11 Version: Type: bug Priority: major Component: Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2834/baikal-regeneration-instruction-in-readme -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 14 09:21:41 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 14 Nov 2024 15:21:41 +0000 Subject: [ET Trac] #2818: failing tests with gcc-14 Message-ID: #2818: failing tests with gcc-14 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/2818/failing-tests-with-gcc-14 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Nov 15 10:20:12 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 15 Nov 2024 16:20:12 +0000 Subject: [ET Trac] #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Message-ID: #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Comment (by Roland Haas): @{557058:56049c54-f8c2-4b6c-9b88-ab697c967495} comments? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-on-blosc-support-in-adios2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Nov 15 11:22:27 2024 From: trac-noreply at einsteintoolkit.org (Erik Schnetter) Date: Fri, 15 Nov 2024 17:22:27 +0000 Subject: [ET Trac] #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Message-ID: #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Comment (by Erik Schnetter): This works for me: ```c++ diff --git a/CarpetX/src/io_openpmd.cxx b/CarpetX/src/io_openpmd.cxx index acdbf9f7..43f30a9d 100644 --- a/CarpetX/src/io_openpmd.cxx +++ b/CarpetX/src/io_openpmd.cxx @@ -16,6 +16,10 @@ #include +#ifdef HAVE_CAPABILITY_ADIOS2 +#include +#endif + #if defined _OPENMP #include #elif defined __HIPCC__ @@ -116,6 +120,7 @@ constexpr openPMD::IterationEncoding iterationEncoding = openPMD::IterationEncoding::fileBased; // TODO: Set number of threads? +#ifdef ADIOS2_HAVE_BLOSC2 const std::string options = R"EOS( { "adios2": { @@ -133,6 +138,18 @@ const std::string options = R"EOS( } } )EOS"; +#else +const std::string options = R"EOS( + { + "adios2": { + "dataset": { + "operators": [ + ] + } + } + } +)EOS"; +#endif constexpr bool input_ghosts = false; constexpr bool output_ghosts = false; ``` ? I the long term we would want to be able to use Cactus parameters to choose this? If you prefer you can also just undo the changes that require Blosc. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-on-blosc-support-in-adios2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Nov 15 12:29:30 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 15 Nov 2024 18:29:30 +0000 Subject: [ET Trac] #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Message-ID: #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Comment (by Roland Haas): ok, I?ll add that one. If this will become dynamic anyway, then I am not too worried about ending up with a combinatorial explosion of different options. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-on-blosc-support-in-adios2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Nov 15 12:45:45 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 15 Nov 2024 18:45:45 +0000 Subject: [ET Trac] #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Message-ID: #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Comment (by Roland Haas): Applied as git hash [0fafb866](https://github.com/EinsteinToolkit/CarpetX/commits/0fafb866de36a310d167068e711389eaf3c70262) "CarpetX: disable BLOSC in runtime options if ADIOS2 does not support it" of \[CarpetX\]\([https://github.com/EinsteinToolkit/CarpetX](https://github.com/EinsteinToolkit/CarpetX) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-on-blosc-support-in-adios2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 21 09:25:35 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 Nov 2024 15:25:35 +0000 Subject: [ET Trac] #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Message-ID: #2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Reporter: Roland Haas Status: resolved Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Changes (by Roland Haas): status: resolved (was open) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-on-blosc-support-in-adios2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 21 09:40:47 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 Nov 2024 15:40:47 +0000 Subject: [ET Trac] #2807: Hydro_RNSID passes CFLAGS to LD Message-ID: #2807: Hydro_RNSID passes CFLAGS to LD Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Changes (by Roland Haas): title: Hydro_RNSID passes CFLAGS to LD (was Hydro_RNSD passes CFLAGS to LD) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2807/hydro_rnsid-passes-cflags-to-ld -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 21 14:25:28 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 Nov 2024 20:25:28 +0000 Subject: [ET Trac] #2174: Test "Multi Patch Scalar Wave Equation" example Message-ID: #2174: Test "Multi Patch Scalar Wave Equation" example Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): Before each release, check that http://einsteintoolkit.org/gallery/multipatch/index.html still works and produces correct output. **Steps**: 1. download the _development_ version of the Einstein Toolkit: ```shell curl -kLO https://raw.githubusercontent.com/gridaphobe/CRL/master/GetComponents chmod a+x GetComponents ./GetComponents https://bitbucket.org/einsteintoolkit/manifest/raw/master/einsteintoolkit.th ``` 2. download the parameter file fro the gallery example ```shell cd Cactus wget --output-document par/Kerr-Schild_Multipole.par https://bitbucket.org/llamacode/llama/raw/master/LlamaWaveToy/par/Kerr-Schild_Multipole.par ``` 3. compile Cactus for the system you are on \(this may require that you add a cluster allocation etc.\) ```shell ./utils/Scripts/MakeThornList --master thornlists/einsteintoolkit.th --output thornlists/Kerr-Schild_Multipole.th par/Kerr-Schild_Multipole.par ./simfactory/bin/sim setup-silent ./simfactory/bin/sim build --thornlist thornlists/Kerr-Schild_Multipole.th ``` 4. run the simulation, using number of MPI ranks similar to what is shown on the ET website, so _for example_ ```shell ./simfactory/bin/sim create-submit Kerr-Schild_Multipole --parfile par/Kerr-Schild_Multipole.par --cores 8 --num-threads 2 --walltime 0:30:00 ``` 5. on your laptop install VisIt using the precompiled executable available from its [download page](https://visit-dav.github.io/visit-website/) 6. comprehensive instructions on how to produce the images are on the [gallery page](http://einsteintoolkit.org/gallery/multipatch/index.html ) **Data to upload** 1. Data is made available at [https://bitbucket.org/einsteintoolkit/www/downloads/](https://bitbucket.org/einsteintoolkit/www/downloads/) and you should see a blue ?Add Files? button in the top right, when logged in with your Bitbucket account. If that is not the case contact the release manager to have you added. 2. The data file is named Kerr-Schild\_Multipole-YYYYMMDD.tar.gz and should contain the files required to reproduce the plots as well as parameter files, stdout and stderr files and the plot scripts. As of this writing this are the files `u.file_*.h5`, `x.file_*.h5`, `y.file_*.h5`, `z.file_*.h5`, `Kerr-Schild_Multipole.par`, `Kerr-Schild_Multipole.out`, `Kerr-Schild_Multipole.err`, `plot.py`, `Kerr-Schild_Multipole.session`. 3. uploading the file with a browser can be troublesome and fail with no apparent error message. Instead using `curl` and bitbucket?s [REST API ](https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/downloads#post)can be used. 1. If you have enabled TFA for Bitbucket, then you can use an Application password with write permission to the repo. These can be created here: [https://bitbucket.org/account/settings/app-passwords/](https://bitbucket.org/account/settings/app-passwords/) 2. Then run \(replace the file name and the user name and password with the appropriate values\): ``` curl -u YOURBITBUCKETUSERNAME:YOURBITBUCKETPASSWORD -X POST https://api.bitbucket.org/2.0/repositories/einsteintoolkit/www/downloads -F files=@Kerr-Schild_Multipole-YYYYMMDD.tar.gz ``` ? Comment (by Roland Haas): provide detailed instructions in description -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2174/test-multi-patch-scalar-wave-equation -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 21 14:26:40 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 Nov 2024 20:26:40 +0000 Subject: [ET Trac] #2174: Test "Multi Patch Scalar Wave Equation" example Message-ID: #2174: Test "Multi Patch Scalar Wave Equation" example Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): responsible: [] (was []) assignee: Domenica Garzon Armendariz (was William Gabella) Comment (by Roland Haas): Update to indicate that @{712020:d1a3df85-d975-4103-a904-7214e64f1e72} will handle this for ET\_2024\_11 \(Cannon\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2174/test-multi-patch-scalar-wave-equation -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 21 14:33:35 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 Nov 2024 20:33:35 +0000 Subject: [ET Trac] #2174: Test "Multi Patch Scalar Wave Equation" example Message-ID: #2174: Test "Multi Patch Scalar Wave Equation" example Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): Before each release, check that http://einsteintoolkit.org/gallery/multipatch/index.html still works and produces correct output. **Steps**: 1. download the _development_ version of the Einstein Toolkit: ```shell curl -kLO https://raw.githubusercontent.com/gridaphobe/CRL/master/GetComponents chmod a+x GetComponents ./GetComponents https://bitbucket.org/einsteintoolkit/manifest/raw/master/einsteintoolkit.th ``` 2. download the parameter file fro the gallery example ```shell cd Cactus wget --output-document par/Kerr-Schild_Multipole.par https://bitbucket.org/llamacode/llama/raw/master/LlamaWaveToy/par/Kerr-Schild_Multipole.par ``` 3. compile Cactus for the system you are on \(this may require that you add a cluster allocation etc.\) ```shell ./utils/Scripts/MakeThornList --master thornlists/einsteintoolkit.th --output thornlists/Kerr-Schild_Multipole.th par/Kerr-Schild_Multipole.par ./simfactory/bin/sim setup-silent ./simfactory/bin/sim build --thornlist thornlists/Kerr-Schild_Multipole.th ``` 4. run the simulation, using number of MPI ranks similar to what is shown on the ET website, so _for example_ ```shell ./simfactory/bin/sim create-submit Kerr-Schild_Multipole --parfile par/Kerr-Schild_Multipole.par --cores 8 --num-threads 2 --walltime 0:30:00 ``` 5. on your laptop install VisIt using the precompiled executable available from its [download page](https://visit-dav.github.io/visit-website/) 6. comprehensive instructions on how to produce the images are on the [gallery page](http://einsteintoolkit.org/gallery/multipatch/index.html) **Data to upload** 1. Data is made available at [https://bitbucket.org/einsteintoolkit/www/downloads/](https://bitbucket.org/einsteintoolkit/www/downloads/) and you should see a blue ?Add Files? button in the top right, when logged in with your Bitbucket account. If that is not the case contact the release manager to have you added. 2. The data file is named Kerr-Schild\_Multipole-YYYYMMDD.tar.gz and should contain the files required to reproduce the plots as well as parameter files, stdout and stderr files and the plot scripts. As of this writing this are the files `u.file_*.h5`, `x.file_*.h5`, `y.file_*.h5`, `z.file_*.h5`, `Kerr-Schild_Multipole.par`, `Kerr-Schild_Multipole.out`, `Kerr-Schild_Multipole.err`, `plot.py`, `Kerr-Schild_Multipole.session`. 3. uploading the file with a browser can be troublesome and fail with no apparent error message. Instead using `curl` and bitbucket?s [REST API ](https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/downloads#post)can be used. 1. If you have enabled TFA for Bitbucket, then you can use an Application password with write permission to the repo. These can be created here: [https://bitbucket.org/account/settings/app-passwords/](https://bitbucket.org/account/settings/app-passwords/) 2. Then run \(replace the file name and the user name and password with the appropriate values\): ```shell curl -u YOURBITBUCKETUSERNAME:YOURBITBUCKETPASSWORD -X POST https://api.bitbucket.org/2.0/repositories/einsteintoolkit/www/downloads -F files=@Kerr-Schild_Multipole-YYYYMMDD.tar.gz ``` **Update the webpage** 1. clone the `www` repository to update the gallery page using: ```shell git clone git at bitbucket.org:einsteintoolkit/www.git ``` 2. update the figure files in `gallery/multipatch` with ones you created \(the `kerr_4x3.png` one is used on the ET website frontpage in the ?slider? so its aspect ratio must be 4x3\). 3. indicate in `index.html` the date and your name to show when the gallery example was last run 4. update the run time estimates if possible 5. update instructions on the website if they were not clear 6. add, commit and push the changed files to the `www` repository ```shell git add gallery/multipatch/index.html gallery/multipatch/kerr.png gallery/multipatch/kerr_4x3.png git commit -m 'multipatch: update for release ET_YYYY_MM' git push ``` Please report in this ticket any issue you found ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2174/test-multi-patch-scalar-wave-equation -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Nov 21 14:35:54 2024 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 Nov 2024 20:35:54 +0000 Subject: [ET Trac] #2174: Test "Multi Patch Scalar Wave Equation" example Message-ID: #2174: Test "Multi Patch Scalar Wave Equation" example Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): Before each release, check that http://einsteintoolkit.org/gallery/multipatch/index.html still works and produces correct output. **Steps**: 1. download the _development_ version of the Einstein Toolkit: ```shell curl -kLO https://raw.githubusercontent.com/gridaphobe/CRL/master/GetComponents chmod a+x GetComponents ./GetComponents https://bitbucket.org/einsteintoolkit/manifest/raw/master/einsteintoolkit.th ``` 2. download the parameter file fro the gallery example ```shell cd Cactus wget --output-document par/Kerr-Schild_Multipole.par https://bitbucket.org/llamacode/llama/raw/master/LlamaWaveToy/par/Kerr-Schild_Multipole.par ``` 3. compile Cactus for the system you are on \(this may require that you add a cluster allocation etc.\) ```shell ./utils/Scripts/MakeThornList --master thornlists/einsteintoolkit.th --output thornlists/Kerr-Schild_Multipole.th par/Kerr-Schild_Multipole.par ./simfactory/bin/sim setup-silent ./simfactory/bin/sim build --thornlist thornlists/Kerr-Schild_Multipole.th ``` 4. run the simulation, using number of MPI ranks similar to what is shown on the ET website, so _for example_ ```shell ./simfactory/bin/sim create-submit Kerr-Schild_Multipole --parfile par/Kerr-Schild_Multipole.par --cores 8 --num-threads 2 --walltime 0:30:00 ``` 5. on your laptop install VisIt using the precompiled executable available from its [download page](https://visit-dav.github.io/visit-website/) 6. comprehensive instructions on how to produce the images are on the [gallery page](http://einsteintoolkit.org/gallery/multipatch/index.html) **Data to upload** 1. Data is made available at [https://bitbucket.org/einsteintoolkit/www/downloads/](https://bitbucket.org/einsteintoolkit/www/downloads/) and you should see a blue ?Add Files? button in the top right, when logged in with your Bitbucket account. If that is not the case contact the release manager to have you added. 2. The data file is named Kerr-Schild\_Multipole-YYYYMMDD.tar.gz and should contain the files required to reproduce the plots as well as parameter files, stdout and stderr files and the plot scripts. As of this writing this are the files `u.file_*.h5`, `x.file_*.h5`, `y.file_*.h5`, `z.file_*.h5`, `Kerr-Schild_Multipole.par`, `Kerr-Schild_Multipole.out`, `Kerr-Schild_Multipole.err`, `plot.py`, `Kerr-Schild_Multipole.session`. 3. uploading the file with a browser can be troublesome and fail with no apparent error message. Instead using `curl` and bitbucket?s [REST API ](https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/downloads#post)can be used. 1. If you have enabled TFA for Bitbucket, then you can use an Application password with write permission to the repo. These can be created here: [https://bitbucket.org/account/settings/app-passwords/](https://bitbucket.org/account/settings/app-passwords/) 2. Then run \(replace the file name and the user name and password with the appropriate values\): ```shell curl -u YOURBITBUCKETUSERNAME:YOURBITBUCKETPASSWORD -X POST https://api.bitbucket.org/2.0/repositories/einsteintoolkit/www/downloads -F files=@Kerr-Schild_Multipole-YYYYMMDD.tar.gz ``` **Update the webpage** 1. clone the `www` repository to update the gallery page using: ```shell git clone git at bitbucket.org:einsteintoolkit/www.git ``` 2. update the figure files in `gallery/multipatch` with ones you created \(the `kerr_4x3.png` one is used on the ET website frontpage in the ?slider? so its aspect ratio must be 4x3\). 3. indicate in `index.html` the date and your name to show when the gallery example was last run 4. update the run time estimates if possible 5. update instructions on the website if they were not clear 6. add, commit and push the changed files to the `www` repository ```shell git add gallery/multipatch/index.html gallery/multipatch/kerr.png gallery/multipatch/kerr_4x3.png git commit -m 'multipatch: update for release ET_YYYY_MM' git push ``` Please report in this ticket any issue you found -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2174/test-multi-patch-scalar-wave-equation -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Nov 22 14:04:25 2024 From: trac-noreply at einsteintoolkit.org (Lucas Timotheo Sanches) Date: Fri, 22 Nov 2024 20:04:25 +0000 Subject: [ET Trac] #2173: Test "Poisson equation" example Message-ID: #2173: Test "Poisson equation" example Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Comment (by Lucas Timotheo Sanches): Updated the example page and datasets for 2024-11 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2173/test-poisson-equation-example -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Nov 22 14:05:20 2024 From: trac-noreply at einsteintoolkit.org (Lucas Timotheo Sanches) Date: Fri, 22 Nov 2024 20:05:20 +0000 Subject: [ET Trac] #2173: Test "Poisson equation" example Message-ID: #2173: Test "Poisson equation" example Reporter: Roland Haas Status: resolved Milestone: ET_2024_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Lucas Timotheo Sanches): status: resolved (was open) Comment (by Lucas Timotheo Sanches): Updated the Poisson gallery example page and datasets for 2024-11 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2173/test-poisson-equation-example -------------- next part -------------- An HTML attachment was scrubbed... URL: