From trac-noreply at einsteintoolkit.org Sun Sep 3 09:55:41 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Sun, 03 Sep 2023 14:55:41 +0000 Subject: [ET Trac] #2756: SystemTopology fails to handle Intel CPUs with performance and efficiency cores Message-ID: #2756: SystemTopology fails to handle Intel CPUs with performance and efficiency cores Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn SystemTopology fails on new Intel CPUs with an assert similar to: ``` cactus_sim: configs/sim/build/SystemTopology/system_topology.cc:471: void {anonymous}::set_bindings(hwloc_topology_t, const mpi_host_mapping_t&): Assertion `num_pus % num_cores == 0' failed. ``` where in the case of a 12th Gen Intel\(R\) Core\(TM\) i7-12700 [https://en.wikipedia.org/wiki/List\_of\_Intel\_Core\_i7\_processors#Golden\_Cove\_\+\_Gracemont\_microarchitecture\_\(12th\_generation\)](https://en.wikipedia.org/wiki/List_of_Intel_Core_i7_processors#Golden_Cove_+_Gracemont_microarchitecture_(12th_generation)) with performance \(16\) and efficiency \(4\) logical cpus hwloc reports: core\_depth 5 num\_cores 12 pu\_depth 6 num\_pus 20 and the assert \`num\_pus % num\_cores == 0\` fails \(b/c only the 8 performance cores have hyperthreads\). This has been reported on the mailing list in [https://lists.einsteintoolkit.org/pipermail/users/2023-August/009036.html](https://lists.einsteintoolkit.org/pipermail/users/2023-August/009036.html) Not sure if the asserted property is indeed required by SystemTopology or if this is only a sanity check that can be removed without affecting functionality. Certainly performance will be unbalanced between MPI ranks and OpenMP threads that run on P or E cores respectively \(and also if a hyperthread pair was split among two MPI ranks\). This may mostly affect workstations and laptops as I would not expect server class CPUs \(on HPC systems\) to have efficiency cores \(do they?\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2756/systemtopology-fails-to-handle-intel-cpus -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 5 15:57:17 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Tue, 05 Sep 2023 20:57:17 +0000 Subject: [ET Trac] #2745: Inclusion of GRHayL library and associated MHD thorns Message-ID: #2745: Inclusion of GRHayL library and associated MHD thorns Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): I ported all the changes made to `GRHayLHD` and `GRHayLID` to the X versions and added a test to `GRHayLHDX.` I also checked that the test looks the same for both versions \(as much as they can with cell/vertex differences\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2745/inclusion-of-grhayl-library-and-associated -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 7 08:24:26 2023 From: trac-noreply at einsteintoolkit.org (Peter Diener) Date: Thu, 07 Sep 2023 13:24:26 +0000 Subject: [ET Trac] #2745: Inclusion of GRHayL library and associated MHD thorns Message-ID: #2745: Inclusion of GRHayL library and associated MHD thorns Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Peter Diener): The tests for GRHayLHD now runs, but the new data is for 1 processor whereas the test requirement is for running on 2 processors. The test for GRHayLMHD still sets wrong parameters. After fixing those, the test fails with differences in all output files. GRHayLib has no documentation. I would think that a library in order to be really useful would have documentation that describe the provided interfaces. ? ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2745/inclusion-of-grhayl-library-and-associated -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 7 08:32:21 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Thu, 07 Sep 2023 13:32:21 +0000 Subject: [ET Trac] #2745: Inclusion of GRHayL library and associated MHD thorns Message-ID: #2745: Inclusion of GRHayL library and associated MHD thorns Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): Sorry if I was unclear before, but we aren?t trying to get the MHD into this release anymore. Just `GRHayLib`, `GRHayLHD(X)`, and `GRHayLID(X)`. I have documentation.tex that I have been working on, but I haven?t finished and pushed it yet. I will update as soon as I do. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2745/inclusion-of-grhayl-library-and-associated -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 7 11:37:23 2023 From: trac-noreply at einsteintoolkit.org (Peter Diener) Date: Thu, 07 Sep 2023 16:37:23 +0000 Subject: [ET Trac] #2751: EHFinder: Array reference out of bounds Message-ID: #2751: EHFinder: Array reference out of bounds Reporter: Erik Schnetter Status: new Milestone: Version: Type: bug Priority: minor Component: Comment (by Peter Diener): This should be fixed now. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2751/ehfinder-array-reference-out-of-bounds -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 7 11:37:45 2023 From: trac-noreply at einsteintoolkit.org (Peter Diener) Date: Thu, 07 Sep 2023 16:37:45 +0000 Subject: [ET Trac] #2751: EHFinder: Array reference out of bounds Message-ID: #2751: EHFinder: Array reference out of bounds Reporter: Erik Schnetter Status: resolved Milestone: Version: Type: bug Priority: minor Component: Changes (by Peter Diener): status: resolved (was new) Comment (by Peter Diener): Fixed -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2751/ehfinder-array-reference-out-of-bounds -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 7 14:22:20 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Sep 2023 19:22:20 +0000 Subject: [ET Trac] #2739: change ADMMacros::spatial_order to GRHydro::sources_spatial_order in Hydro_RNSID example parfiles Message-ID: #2739: change ADMMacros::spatial_order to GRHydro::sources_spatial_order in Hydro_RNSID example parfiles Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): @stevenrbrandt says ?please apply? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2739/change-admmacros-spatial_order-to-grhydro -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 7 14:23:43 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 07 Sep 2023 19:23:43 +0000 Subject: [ET Trac] #2739: change ADMMacros::spatial_order to GRHydro::sources_spatial_order in Hydro_RNSID example parfiles Message-ID: #2739: change ADMMacros::spatial_order to GRHydro::sources_spatial_order in Hydro_RNSID example parfiles Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): Applied as git hash [3aa0537a](https://bitbucket.org/einsteintoolkit/einsteininitialdata/commits/3aa0537a265b7af5ad53c369225608d2e5855d9c) "Hydro\_RNSID: remove ADMMacros and ADMCoupling from tests" of [einsteininitialdata](https://bitbucket.org/einsteintoolkit/einsteininitialdata) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2739/change-admmacros-spatial_order-to-grhydro -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 7 15:33:07 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Thu, 07 Sep 2023 20:33:07 +0000 Subject: [ET Trac] #2745: Inclusion of GRHayL library and associated MHD thorns Message-ID: #2745: Inclusion of GRHayL library and associated MHD thorns Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): I pushed a version of the documentation for `GRHayLib`, as well as documentation updates/additions for the others. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2745/inclusion-of-grhayl-library-and-associated -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 7 15:33:57 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Thu, 07 Sep 2023 20:33:57 +0000 Subject: [ET Trac] #2745: Inclusion of GRHayL library and associated MHD thorns Message-ID: #2745: Inclusion of GRHayL library and associated MHD thorns Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): For the full library documentation, I point them to the GitHub wiki where we give details on all the library functions. Hopefully that is sufficient. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2745/inclusion-of-grhayl-library-and-associated -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Sep 8 14:47:09 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 08 Sep 2023 19:47:09 +0000 Subject: [ET Trac] #2755: bugs in POWER code Message-ID: #2755: bugs in POWER code Reporter: Anuj Kankani Status: open Milestone: Version: Type: bug Priority: major Component: Other Changes (by Roland Haas): status: open (was submitted) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2755/bugs-in-power-code -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 12 10:37:29 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 12 Sep 2023 15:37:29 +0000 Subject: [ET Trac] #2757: NSIMD tries to download sleef when compiling Message-ID: #2757: NSIMD tries to download sleef when compiling Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn NSIMD \(required for CarpetX\) tries to download sleef using Python requests while compiling. This fails eg if Python does not offer requests \(or is too old\), eg on expanse: ``` Traceback (most recent call last): File "/home/rhaas/CarpetXCPU/configs/sim/scratch/build/NSIMD/nsimd-3.0.1/egg/hatch.py", line 54, in import get_sleef_code File "/home/rhaas/CarpetXCPU/configs/sim/scratch/build/NSIMD/nsimd-3.0.1/egg/get_sleef_code.py", line 23, in import requests ModuleNotFoundError: No module named 'requests' CMake Error at CMakeLists.txt:217 (set_property): set_property could not find TARGET api_cpu. Perhaps it has not yet been created. CMake Error at CMakeLists.txt:218 (target_include_directories): Cannot specify include directories for target "api_cpu" which is not built by this project. CMake Error at CMakeLists.txt:320 (target_compile_options): Cannot specify compile options for target "api_cpu" which is not built by this project. -- Configuring incomplete, errors occurred! ``` but would also fail on LRZ?s SuperMUC which does not allow outgoing internet connections at all. NSIMD should contain a copy of sleef, both to avoid this and to ensure that it gets a well defined version. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2757/nsimd-tries-to-download-sleef-when -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 12 15:32:00 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 12 Sep 2023 20:32:00 +0000 Subject: [ET Trac] #2752: Parameter file parser generates illegal (?) C code Message-ID: #2752: Parameter file parser generates illegal (?) C code Reporter: Erik Schnetter Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): This was discussed during the ET call on 2023-09-07 [https://lists.einsteintoolkit.org/pipermail/users/2023-September/009064.html](https://lists.einsteintoolkit.org/pipermail/users/2023-September/009064.html) and proposed solution is to add code to escape for the respective targets: C code, LaTeX, and HTML. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2752/parameter-file-parser-generates-illegal-c -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 14 09:18:57 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 14 Sep 2023 14:18:57 +0000 Subject: [ET Trac] #2739: change ADMMacros::spatial_order to GRHydro::sources_spatial_order in Hydro_RNSID example parfiles Message-ID: #2739: change ADMMacros::spatial_order to GRHydro::sources_spatial_order in Hydro_RNSID example parfiles Reporter: Roland Haas Status: resolved Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Changes (by Roland Haas): status: resolved (was open) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2739/change-admmacros-spatial_order-to-grhydro -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 14 09:26:18 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 14 Sep 2023 14:26:18 +0000 Subject: [ET Trac] #963: Improve McLachlan accuracy Message-ID: #963: Improve McLachlan accuracy Reporter: Erik Schnetter Status: open Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): @{557058:f7fd5133-6eee-4385-a5e5-3e03342a0b24} @{557058:8bc23f2a-45c0-477d-8ac4-a5a16c734278} did you have time to look into this? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/963/improve-mclachlan-accuracy -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 14 22:41:10 2023 From: trac-noreply at einsteintoolkit.org (Michal Pirog) Date: Fri, 15 Sep 2023 03:41:10 +0000 Subject: [ET Trac] #2747: Inclusion of sgrid importer in Einstein Toolkit Message-ID: #2747: Inclusion of sgrid importer in Einstein Toolkit Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Michal Pirog):
-- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgrid-importer-in-einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Sep 15 08:59:46 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 15 Sep 2023 13:59:46 +0000 Subject: [ET Trac] #2747: Inclusion of sgrid importer in Einstein Toolkit Message-ID: #2747: Inclusion of sgrid importer in Einstein Toolkit Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): This SGRID the library, yes? is there a proposed thornlist and thorn for the actual importer \(according to the timeline at: [https://docs.einsteintoolkit.org/et-docs/Release\_Details#Schedule](https://docs.einsteintoolkit.org/et-docs/Release_Details#Schedule) that one should have passed the no-harm review and be in the the main thornlist in manifest by now\)? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgrid-importer-in-einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Sep 15 16:14:08 2023 From: trac-noreply at einsteintoolkit.org (Leonardo Werneck) Date: Fri, 15 Sep 2023 21:14:08 +0000 Subject: [ET Trac] #2749: WVUThorns: sprintf use violates standard Message-ID: #2749: WVUThorns: sprintf use violates standard Reporter: Erik Schnetter Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Leonardo Werneck): This issue was addressed in commit [72342fa](https://bitbucket.org/zach_etienne/wvuthorns_diagnostics/commits/72342fafe7e64b053b9009b376cef8263605771a). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2749/wvuthorns-sprintf-use-violates-standard -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Sep 18 21:09:21 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Tue, 19 Sep 2023 02:09:21 +0000 Subject: [ET Trac] #2758: conditional read/write statements Message-ID: #2758: conditional read/write statements Reporter: Samuel Cupp Status: new Milestone: Version: Type: enhancement Priority: minor Component: Cactus Currently, if a function reads or writes variables only under certain conditions, proper scheduling within the schedule.ccl would require duplicating the entire function schedule for every possibility. As a simple example, ``` if(CCTK_EQUALS(EOS, "Tabulated")) { schedule func at bin { LANG: C READS: var1 WRITES: var2, var3 } } else { schedule func at bin { LANG: C READS: var1 WRITES: var2 } } ``` Instead, having the ability to set these conditionals within the function scheduling like ``` schedule func at bin { LANG: C READS: var1 WRITES: var2 if(CCTK_EQUALS(EOS, "Tabulated")) { WRITES: var3 } } ``` would make this scheduling much more compact **and** more readable. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2758/conditional-read-write-statements -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Sep 18 21:11:37 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Tue, 19 Sep 2023 02:11:37 +0000 Subject: [ET Trac] #2734: Consider adding if statement functionality to read/write declarations Message-ID: #2734: Consider adding if statement functionality to read/write declarations Reporter: Samuel Cupp Status: new Milestone: Version: Type: enhancement Priority: minor Component: Cactus Comment (by Samuel Cupp): @{557058:1671c5c3-29cc-4e83-9850-a152d33a6235} do you think this would be very difficult to implement? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2734/consider-adding-if-statement-functionality -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Sep 18 21:46:27 2023 From: trac-noreply at einsteintoolkit.org (Michal Pirog) Date: Tue, 19 Sep 2023 02:46:27 +0000 Subject: [ET Trac] #2747: Inclusion of sgrid importer in Einstein Toolkit Message-ID: #2747: Inclusion of sgrid importer in Einstein Toolkit Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Michal Pirog): Hi there. I have a silly question. Can you explain to me where and how I can upload my files here to make it available to whoever is involved? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgrid-importer-in-einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 19 00:12:56 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Tue, 19 Sep 2023 05:12:56 +0000 Subject: [ET Trac] #2747: Inclusion of sgrid importer in Einstein Toolkit Message-ID: #2747: Inclusion of sgrid importer in Einstein Toolkit Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): In the upper right of the ticket page, there should be a `more` option that drops down to give the attach file option. What exactly are you trying to upload? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgrid-importer-in-einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 19 08:24:26 2023 From: trac-noreply at einsteintoolkit.org (Michal Pirog) Date: Tue, 19 Sep 2023 13:24:26 +0000 Subject: [ET Trac] #2747: Inclusion of sgrid importer in Einstein Toolkit Message-ID: #2747: Inclusion of sgrid importer in Einstein Toolkit Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Michal Pirog): I would like to upload the thorn's files for Liwei -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgrid-importer-in-einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 20 14:43:48 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Wed, 20 Sep 2023 19:43:48 +0000 Subject: [ET Trac] #2747: Inclusion of sgrid importer in Einstein Toolkit Message-ID: #2747: Inclusion of sgrid importer in Einstein Toolkit Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): Is the thorn not publicly available? There?s no way to include a thorn that isn?t public as far as I?m aware. A public repo needs to be set up asap in order for it to be able to be checked out by the toolkit. I didn?t realize this was all still private. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgrid-importer-in-einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 21 07:55:47 2023 From: trac-noreply at einsteintoolkit.org (Peter Diener) Date: Thu, 21 Sep 2023 12:55:47 +0000 Subject: [ET Trac] #2745: Inclusion of GRHayL library and associated MHD thorns Message-ID: #2745: Inclusion of GRHayL library and associated MHD thorns Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Peter Diener): I have compiled with both the gnu and intel compilers on my laptop and find that the test ?Balsara1? fails with the intel compilers but passes with the gnu compilers. Looking at this in more details, it looks to be an issue with the initial data setup. In the parameter file, the discontinuity position is set to zero. With the gnu compilers this results in the pressure being 1 at x=0 and 0.1 at x=0.000625. With the intel compilers the pressure is 1 at x=-0.000625 and 0.1 at x=0. So somehow the iniitlal profile is shifted by dx. Looks like there is some sensitivity to difference in rounding between the compilers. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2745/inclusion-of-grhayl-library-and-associated -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 21 08:39:23 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 Sep 2023 13:39:23 +0000 Subject: [ET Trac] #2745: Inclusion of GRHayL library and associated MHD thorns Message-ID: #2745: Inclusion of GRHayL library and associated MHD thorns Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Fails with GNU for balsara0 still on testing server [https://einsteintoolkit.github.io/tests/build\_738.html](https://einsteintoolkit.github.io/tests/build_738.html) [https://github.com/EinsteinToolkit/tests/blob/gh-pages/records/version\_738/sim\_738\_2/GRHayLHD/Balsara0.diffs](https://github.com/EinsteinToolkit/tests/blob/gh-pages/records/version_738/sim_738_2/GRHayLHD/Balsara0.diffs) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2745/inclusion-of-grhayl-library-and-associated -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 21 09:28:00 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 21 Sep 2023 14:28:00 +0000 Subject: [ET Trac] #2758: icpc 19 fails to compile AMReX Message-ID: #2758: icpc 19 fails to compile AMReX Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn AMReX contains code like this: ```c++ #include static constexpr std::string_view parser_f2_s[] = { "pow", "atan2", "gt", "lt", "geq", "leq", "eq", "neq", "and", "or", "heaviside", "jn", "min", "max", "fmod" }; ``` which fails to compile with ?icpc \(ICC\) 19.1.3.304 20200925? with ``` $ icpc -gxx-name=g++ -std=gnu++17 -c dummy.cc dummy.cc(4): error: expression must have a constant value { ^ dummy.cc(3): note: attempt to access run-time storage static constexpr std::string_view parser_f2_s[] = ^ compilation aborted for dummy.cc (code 2) ``` a workaround is to manually count the vector elements: ``` static constexpr std::string_view parser_f2_s[15] = ``` which compiles fine. g\+\+ is gcc-9.3.0, which itself would compile the file fine \(so it is a compiler issue, not a STL issue\). Can be tested on db1. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2758/icpc-19-fails-to-compile-amrex -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Sun Sep 24 22:10:59 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Mon, 25 Sep 2023 03:10:59 +0000 Subject: [ET Trac] #2745: Inclusion of GRHayL library and associated MHD thorns Message-ID: #2745: Inclusion of GRHayL library and associated MHD thorns Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): The Balsara0 test is passing now in the CI. Let me know if there?s any issues. Since CarpetX is in now, I enabled `GRHayLIDX` and `GRHayLHDX` so the tests can run. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2745/inclusion-of-grhayl-library-and-associated -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 26 08:55:09 2023 From: trac-noreply at einsteintoolkit.org (Michal Pirog) Date: Tue, 26 Sep 2023 13:55:09 +0000 Subject: [ET Trac] #2747: Inclusion of sgrid importer in Einstein Toolkit Message-ID: #2747: Inclusion of sgrid importer in Einstein Toolkit Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Michal Pirog): Publicly available repo is here: [https://github.com/wofti/CactusSgrid.git](https://github.com/wofti/CactusSgrid.git) The thorn itself is at the directory "DNSData" \("BNSData" is an old version\) We are using the thornlist "[dns.th](http://dns.th)" from the directory "useful\_files" as an argument for "GetComponents". Finally, we compile Cactus with the option list "dns.cfg" from the directory "useful\_files". PS: "README" is to update. And I need to prepare some .par file for testing. Again: where exactly should I upload this thorn? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgrid-importer-in-einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Sep 26 16:03:55 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 26 Sep 2023 21:03:55 +0000 Subject: [ET Trac] #2747: Inclusion of sgrid importer in Einstein Toolkit Message-ID: #2747: Inclusion of sgrid importer in Einstein Toolkit Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): You don?t have to upload it anywhere, really. All that is needed for it to be ?in the Einstien Toolkit? is that there is a correct checkout line of it in the official ET thornlist in the ET ?manifest? repository \(since, strictly speaking, this is all the ET is: a collated list of externally developed software\). _If_ you however would like to have the code hosted somewhere that is not e.g. your pesonal github or Bitbucket account \(eg b/c you may change jobs, or b/c you would need to grant at least some access to the ET release chair / a maintainer\) it can also be moved into an appropriate repository in [https://github.com/einsteintoolkit](https://github.com/einsteintoolkit) e.g. the thorn could go into ?EinsteinInitialdata?. Downside: you lose some ?branding? since your name no longer appears in the URL, upside you do not have to eg handle access and the ET maintainers will take care of the all steps required for each release. Examples for ?include? are eg the Outflow thorn in EinsteinAnalysis. Examples for ?not include? are eg Carpet. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgrid-importer-in-einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 27 14:31:48 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Wed, 27 Sep 2023 19:31:48 +0000 Subject: [ET Trac] #2746: Make Seed_Magnetic_Fields independent of IllinoisGRMHD Message-ID: #2746: Make Seed_Magnetic_Fields independent of IllinoisGRMHD Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): The associated PR: [https://bitbucket.org/zach\_etienne/wvuthorns/pull-requests/14](https://bitbucket.org/zach_etienne/wvuthorns/pull-requests/14) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2746/make-seed_magnetic_fields-independent-of -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 27 14:44:57 2023 From: trac-noreply at einsteintoolkit.org (Michal Pirog) Date: Wed, 27 Sep 2023 19:44:57 +0000 Subject: [ET Trac] #2747: Inclusion of sgrid importer in Einstein Toolkit Message-ID: #2747: Inclusion of sgrid importer in Einstein Toolkit Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Michal Pirog): I was convinced that there is some specific place where files must be uploaded. Anyway, I'm still confused. There is a deadline today which says: "2023-09-27 \(-10wk\): all codes proposed for inclusion in master branch \(still under review\) \[dates pushed back for delayed release\]" What should I/we do to not miss this deadline. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgrid-importer-in-einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 27 16:15:27 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Wed, 27 Sep 2023 21:15:27 +0000 Subject: [ET Trac] #2747: Inclusion of sgrid importer in Einstein Toolkit Message-ID: #2747: Inclusion of sgrid importer in Einstein Toolkit Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): This means adding the thorns to the `einsteintoolkit.th` in the master branch of the manifest \([link](https://bitbucket.org/einsteintoolkit/manifest/src/master/einsteintoolkit.th)\). As long as the thorns are in a publicly accessible repo, it should be fine. Note that we usually make branches and tags for every single release on these repositories \(see, for example, the plethora of `ET_YYYY_MM` branches in [wvuthorns](https://bitbucket.org/zach_etienne/wvuthorns/src/master/)\). This either means giving the ET maintainers permission to create branches in the repository \(and possibly letting any future release managers/maintainers have access\) or be willing to create these branches and tags on behalf of the ET. Generally, letting at least a few of the senior maintainers have commit access will help ensure smooth future releases in case people get sick or something at the same time as a release. So right now, the most important thing is making sure we put in the correct information. Based on what is in the linked git repo, it is ``` !TARGET = $ARR !TYPE = git !URL = https://github.com/wofti/CactusSgrid.git !REPO_PATH = .. !CHECKOUT = CactusSgrid/DNSdata ``` If that?s all we need to add, then I can do that today. @{634afd8853df3c01232121fd} what does the `$2` that most thorns use mean for repo\_path? I ask because I don?t know if the `..` in the above is what GetComponents normally expects or not. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgrid-importer-in-einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 27 16:54:20 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Wed, 27 Sep 2023 21:54:20 +0000 Subject: [ET Trac] #2746: Make Seed_Magnetic_Fields independent of IllinoisGRMHD Message-ID: #2746: Make Seed_Magnetic_Fields independent of IllinoisGRMHD Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2746/make-seed_magnetic_fields-independent-of -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 27 16:54:20 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Wed, 27 Sep 2023 21:54:20 +0000 Subject: [ET Trac] #2746: Make Seed_Magnetic_Fields independent of IllinoisGRMHD Message-ID: #2746: Make Seed_Magnetic_Fields independent of IllinoisGRMHD Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2746/make-seed_magnetic_fields-independent-of -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Sep 27 20:50:06 2023 From: trac-noreply at einsteintoolkit.org (Michal Pirog) Date: Thu, 28 Sep 2023 01:50:06 +0000 Subject: [ET Trac] #2747: Inclusion of sgrid importer in Einstein Toolkit Message-ID: #2747: Inclusion of sgrid importer in Einstein Toolkit Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Michal Pirog): First: I hope it's all we need to add, and I'll be more than happy if you do it. Thanks! Second: It's Wolfgang's repo, so I think we should ask him. I'm writing an email to him right now. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgrid-importer-in-einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Sep 28 20:48:48 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 29 Sep 2023 01:48:48 +0000 Subject: [ET Trac] #2747: Inclusion of sgrid importer in Einstein Toolkit Message-ID: #2747: Inclusion of sgrid importer in Einstein Toolkit Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): GetComponents supports some very limited replacement variables in the `URL`, `AUTH_URL` and `REPO_PATH` variables, namely it will take the `/` entry of each thorn and will assign `` to `$1` \(ie the first thingy\) and `$2` will be set to `` \(ie the second component\). More or less like Perl with do when one used a pattern `m!([^/]*)/(.*)!`. There is _also_ some magic in how `REPO_PATH` behaves depending on whether it does or does not contain a `$1` or `$2`. If it does contain a `$1` or `$2` then the relative path inside of the repository will be exactly as given by `REPO_PATH` \(after variable expansion\). If on the other hand no `$1` or `$2` is found, then the relative path in the repo is `//`. What needs to go into `REPO_PATH` thus hugely depends on the git repository layout. `$2` often works nicely because people tend to put all thorns into the root of the git repo. `..` is somewhat unusual. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgrid-importer-in-einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Sep 29 14:29:27 2023 From: trac-noreply at einsteintoolkit.org (Steven R. Brandt) Date: Fri, 29 Sep 2023 19:29:27 +0000 Subject: [ET Trac] #2553: Cactus' link command uses CPPFLAGS and CXXFLAGS Message-ID: #2553: Cactus' link command uses CPPFLAGS and CXXFLAGS Reporter: Roland Haas Status: open Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Steven R. Brandt): For the upcoming release, we need to compile with nvcc. This leads to errors in ctthorns because Kranc detects cuda and starts putting the device tag on its functions. This leads to compiler failures for ctthorns. If we didn?t have to set CXX globally to nvcc, this problem should go away. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2553/cactus-link-command-uses-cppflags-and -------------- next part -------------- An HTML attachment was scrubbed... URL: