From trac-noreply at einsteintoolkit.org Thu Jun 1 09:17:57 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 01 Jun 2023 14:17:57 +0000 Subject: [ET Trac] #2712: KadathThorn build script contains GNUisms Message-ID: #2712: KadathThorn build script contains GNUisms Reporter: Roland Haas Status: resolved Milestone: ET_2023_05 Version: Type: bug Priority: major Component: Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2712/kadaththorn-build-script-contains-gnuisms -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 1 10:25:32 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 01 Jun 2023 15:25:32 +0000 Subject: [ET Trac] #1334: CCTK_CHECK_HEADER_LIB_FUNC adds library multiple times to $LIBS Message-ID: #1334: CCTK_CHECK_HEADER_LIB_FUNC adds library multiple times to $LIBS Reporter: Frank L?ffler Status: new Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): As @{557058:cf051f66-042f-4a92-a2c7-f2be5a7912de} mentions, adding a library multiple times is harmless. Sometimes, for static linking, it is even required if there are two libraries that require functions from each other. Eg. `libA` contains `funcA1` and `funcA2`. `funcA1` calls `funcB1` in `libB` which itself calls `funcA2` in `libA`. The way to link these correctly for static linking is `-lA -lB -lA` that is one has to repeat one \(or the other\) of the libraries since the linker acts on the library list only once and does so sequentially and will only include objects from a library that if it _already_ knows that the object is required when it processes the library file. This may not be an issue for `CCTK_CHECK_HEADER_LIB_FUNC` if it only ever uses a single library, but would be an issue if it ever added two libraries since `-lA -lB -lA -lB` is not the same as `-lA -lB`. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1334/cctk_check_header_lib_func-adds-library -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 1 10:26:45 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 01 Jun 2023 15:26:45 +0000 Subject: [ET Trac] #1334: CCTK_CHECK_HEADER_LIB_FUNC adds library multiple times to $LIBS Message-ID: #1334: CCTK_CHECK_HEADER_LIB_FUNC adds library multiple times to $LIBS Reporter: Frank L?ffler Status: new Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): One could try and beautify the library list by removing consecutive identical libraries `m m m` or similar, which may help a bit but is not guaranteed to remove all possible redundant duplicates. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1334/cctk_check_header_lib_func-adds-library -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 1 10:28:59 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 01 Jun 2023 15:28:59 +0000 Subject: [ET Trac] #2669: math is not rendered correctly in online docs Message-ID: #2669: math is not rendered correctly in online docs Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): The mathjax \(so one hopes\) rendered math in thorndocs eg in [http://einsteintoolkit.org/thornguide/CactusNumerical/LocalReduce/documentation.html](http://einsteintoolkit.org/thornguide/CactusNumerical/LocalReduce/documentation.html) is not being shown correctly. I \(firefox 102.5.0esr, Debian Linux/GNU\) am shown: ? ![](https://bitbucket.org/repo/8zBLME5/images/1379777661-image.png) instead of the correct \(when I run `make LocalReduce-ThornDocHTML` on my laptop\): ? ![](https://bitbucket.org/repo/8zBLME5/images/2946320859-correct.png) ? This most likely is due to different tex4html engines in Ubuntu 20.04 \(the github documentation runner\) and Debian bullseye. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2669/math-is-not-rendered-correctly-in-online -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 1 10:29:18 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 01 Jun 2023 15:29:18 +0000 Subject: [ET Trac] #2669: math is not rendered correctly in online docs Message-ID: #2669: math is not rendered correctly in online docs Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): The mathjax \(so one hopes\) rendered math in thorndocs eg in [http://einsteintoolkit.org/thornguide/CactusNumerical/LocalReduce/documentation.html](http://einsteintoolkit.org/thornguide/CactusNumerical/LocalReduce/documentation.html) is not being shown correctly. I \(firefox 102.5.0esr, Debian Linux/GNU\) am shown: ? ![](https://bitbucket.org/repo/8zBLME5/images/1379777661-image.png) ? instead of the correct \(when I run `make LocalReduce-ThornDocHTML` on my laptop\): ? ![](https://bitbucket.org/repo/8zBLME5/images/2946320859-correct.png) ? This most likely is due to different tex4html engines in Ubuntu 20.04 \(the github documentation runner\) and Debian bullseye. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2669/math-is-not-rendered-correctly-in-online -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 1 10:32:04 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 01 Jun 2023 15:32:04 +0000 Subject: [ET Trac] #2663: add an notice about minimum Intel / GCC version required to configure output Message-ID: #2663: add an notice about minimum Intel / GCC version required to configure output Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): @{557058:8bc23f2a-45c0-477d-8ac4-a5a16c734278} says \(in pull request\): please apply. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2663/add-an-notice-about-minimum-intel-gcc -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 1 10:33:15 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 01 Jun 2023 15:33:15 +0000 Subject: [ET Trac] #2663: add an notice about minimum Intel / GCC version required to configure output Message-ID: #2663: add an notice about minimum Intel / GCC version required to configure output Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): Applied as git hash [16e3c365](https://bitbucket.org/cactuscode/cactus/commits/16e3c365f1c201e9a398fc02e4487a935cc76d19) "Cactus: add configure test for functional C\+\+11 math" of [cactus](https://bitbucket.org/cactuscode/cactus) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2663/add-an-notice-about-minimum-intel-gcc -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 1 10:33:28 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 01 Jun 2023 15:33:28 +0000 Subject: [ET Trac] #2663: add an notice about minimum Intel / GCC version required to configure output Message-ID: #2663: add an notice about minimum Intel / GCC version required to configure output Reporter: Roland Haas Status: resolved Milestone: Version: Type: enhancement Priority: major Component: Changes (by Roland Haas): status: resolved (was new) Comment (by Roland Haas): Thank you. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2663/add-an-notice-about-minimum-intel-gcc -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 1 17:20:12 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Thu, 01 Jun 2023 22:20:12 +0000 Subject: [ET Trac] #2735: EinsteinBase: storage declaration simplification Message-ID: #2735: EinsteinBase: storage declaration simplification Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: trivial Component: EinsteinToolkit thorn Currently, the various \*Base thorns declare storage like ``` if (timelevels == 1) { STORAGE: stress_energy_scalar[1] STORAGE: stress_energy_vector[1] STORAGE: stress_energy_tensor[1] } else if (timelevels == 2) { STORAGE: stress_energy_scalar[2] STORAGE: stress_energy_vector[2] STORAGE: stress_energy_tensor[2] } else if (timelevels == 3) { STORAGE: stress_energy_scalar[3] STORAGE: stress_energy_vector[3] STORAGE: stress_energy_tensor[3] } ``` We can instead just say ``` STORAGE: stress_energy_scalar[timelevels] STORAGE: stress_energy_vector[timelevels] STORAGE: stress_energy_tensor[timelevels] ``` This, of course, will properly declare the storage depending on the parameter at runtime. As I understand the behavior, this also works for timelevels = 0. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2735/einsteinbase-storage-declaration -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 1 17:21:52 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Thu, 01 Jun 2023 22:21:52 +0000 Subject: [ET Trac] #2735: EinsteinBase: storage declaration simplification Message-ID: #2735: EinsteinBase: storage declaration simplification Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: trivial Component: EinsteinToolkit thorn Comment (by Samuel Cupp): The associated PR is [here](https://bitbucket.org/einsteintoolkit/einsteinbase/pull-requests/5). Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2735/einsteinbase-storage-declaration -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 1 17:24:55 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Thu, 01 Jun 2023 22:24:55 +0000 Subject: [ET Trac] #2735: EinsteinBase: storage declaration simplification Message-ID: #2735: EinsteinBase: storage declaration simplification Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: trivial Component: EinsteinToolkit thorn Comment (by Samuel Cupp): The only question is whether we want to preserve the \(imo strange\) behavior of ADMBase and TmunuBase which ignores the requested timelevels if they aren?t initialized to zero. Zeroing can be an option, but to me it seems like enforcing it prevents people from using poisoning to notice bad behavior. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2735/einsteinbase-storage-declaration -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 1 17:30:50 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Thu, 01 Jun 2023 22:30:50 +0000 Subject: [ET Trac] #2735: EinsteinBase: storage declaration simplification Message-ID: #2735: EinsteinBase: storage declaration simplification Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: trivial Component: EinsteinToolkit thorn Comment (by Samuel Cupp): Right now, the PR removed them in ADMBase. They remain in HydroBase because there are many different variables using the same parameter that one may or may not need in a given run. Essentially, the ?initial\_Y\_e? and similar parameters are serving to determine whether these variables are active. However, in ADMBase the only variables with this behavior are `dtshift`, `dtlapse`, and `shift`. There?s definitely no need for shift to do this, as its storage is already controlled by `shift_timelevels`. The only question is whether we need to reintroduce the ``` if (! CCTK_Equals(initial_dtlapse, "none")) { dtlapse[lapse_timelevels] } if (! CCTK_Equals(initial_dtshift, "none")) { dtshift[shift_timelevels] } ``` ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2735/einsteinbase-storage-declaration -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 2 05:04:00 2023 From: trac-noreply at einsteintoolkit.org (Miguel Zilhão) Date: Fri, 02 Jun 2023 10:04:00 +0000 Subject: [ET Trac] #2723: No boundary conditions registered for variables in group LEANBSSNMOL Message-ID: #2723: No boundary conditions registered for variables in group LEANBSSNMOL Reporter: Vikram Manikantan Status: new Milestone: ET_2023_05 Version: ET_2022_11 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Miguel Zilh?o): I?ve now merged the master branch with development, so this change should now be present also in master. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2723/no-boundary-conditions-registered-for -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 2 09:15:26 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 02 Jun 2023 14:15:26 +0000 Subject: [ET Trac] #2723: No boundary conditions registered for variables in group LEANBSSNMOL Message-ID: #2723: No boundary conditions registered for variables in group LEANBSSNMOL Reporter: Vikram Manikantan Status: resolved Milestone: ET_2023_05 Version: ET_2022_11 Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2723/no-boundary-conditions-registered-for -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 2 09:15:45 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 02 Jun 2023 14:15:45 +0000 Subject: [ET Trac] #2723: No boundary conditions registered for variables in group LEANBSSNMOL Message-ID: #2723: No boundary conditions registered for variables in group LEANBSSNMOL Reporter: Vikram Manikantan Status: resolved Milestone: ET_2023_05 Version: ET_2022_11 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Thank you for the fix. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2723/no-boundary-conditions-registered-for -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 2 10:38:10 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 02 Jun 2023 15:38:10 +0000 Subject: [ET Trac] #2736: consider using git+https together with a branch name or kuibit install Message-ID: #2736: consider using git+https together with a branch name or kuibit install Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: trivial Component: Other Each ET release is tied to a specific kuibit version and @{557058:4b0c8315-696b-4d2e-92da-2da5fea9e8d4} allows the ET to create branches and tags in kuibit. Yet to then install kuibit the instruction in the ET use numeric version numbers `1.4.0` or so and thus a code which may not actually match up with the ET branch `ET_YYYY_MM` of any release \(unless special care is taken by the release coordinator to create a release branch of the version \(tag\) that will be used for the release\). It may be interesting to consider instead to use: ```shell pip install git+https://github.com/Sbozzolo/kuibit at ET_2023_05 ``` instead. At least from the point of view of consistent ET versions. The downside of course being that this probably breaks pip?s logic to compare newer versions and may inundate kuibit?s bug tracker with version numbers that are really ET versions and not kuibit version.s -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2736/consider-using-git-https-together-with-a -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 2 10:49:19 2023 From: trac-noreply at einsteintoolkit.org (Gabriele Bozzola) Date: Fri, 02 Jun 2023 15:49:19 +0000 Subject: [ET Trac] #2736: consider using git+https together with a branch name or kuibit install Message-ID: #2736: consider using git+https together with a branch name or kuibit install Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: trivial Component: Other Comment (by Gabriele Bozzola): I can see another drawback to this. When you install kuibit with `pip install kuibit`, you are served the wheels from PyPI. These are very small files \(460 kB\) and are supposed to work immediately on all the supported architectures/versions. When you install kuibit from git, you have to download the entire repo \(along with the tests, some data files, and so on, and the entire git history\), which can be 100s of MBs - 1 GB. Moreover, you have to recompile the package locally. This should not be a problem for 99 % of the cases, but I would not be surprised if there were incompatibilities in some cases. So, as developer, I would prefer sticking with PyPI for the slightly better user experience, but I do not feel strongly about this. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2736/consider-using-git-https-together-with-a -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 2 10:52:51 2023 From: trac-noreply at einsteintoolkit.org (Gabriele Bozzola) Date: Fri, 02 Jun 2023 15:52:51 +0000 Subject: [ET Trac] #2736: consider using git+https together with a branch name or kuibit install Message-ID: #2736: consider using git+https together with a branch name or kuibit install Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: trivial Component: Other Comment (by Gabriele Bozzola): In addition, kuibit comes with an internal notion of version \(\`kuibit.\_\_version\_\_\`\), which is used for deprecated features or to check if some features are available. If I don?t change this, `kuibit at ET_2023_05`would still advertise itself as version 1.4.0, which might introduce some confusion. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2736/consider-using-git-https-together-with-a -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jun 6 03:19:46 2023 From: trac-noreply at einsteintoolkit.org (Vikram Manikantan) Date: Tue, 06 Jun 2023 08:19:46 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Vikram Manikantan): Hi Leonardo, In your suggested modification above, do you mean to replace the current lines that have ?SetTmunu? or just append this IF statement to the end of the file? See below for existing code in schedule.ccl. ``` schedule IllinoisGRMHD_conserv_to_prims in SetTmunu after (compute_B_and_Bstagger_from_A, TmunuBase_ZeroTmunu) { LANG: C } "Compute primitive variables from conservatives. This is non-trivial, requiring a Newton-Raphson root-finder." schedule IllinoisGRMHD_outer_boundaries_on_P_rho_b_vx_vy_vz in SetTmunu after IllinoisGRMHD_conserv_to_prims { # We must sync {P,rho_b,vx,vy,vz} here. SYNC: grmhd_primitives_allbutBi LANG: C } "Apply outflow-only, flat BCs on {P,rho_b,vx,vy,vz}. Outflow only == velocities pointed inward from outer boundary are set to zero." ``` ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jun 7 08:49:37 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 07 Jun 2023 13:49:37 +0000 Subject: [ET Trac] #2737: define CCTK_DEVICE and CCTK_HOST in Cactus Message-ID: #2737: define CCTK_DEVICE and CCTK_HOST in Cactus Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: minor Component: Cactus Cactus supports CUDA programming in the option lists level via various `CUDA_FOO` variables but does not provide macros for `__device__` and `__host__` modifiers used by both CUDA and HIP accelerators. It would be good if Cactus could provide those depending on which compiler is detected, Predefined defines to look for are \(copying AMReX\): `CUDA_ARCH || HIP_DEVICE_COMPILE || SYCL_DEVICE_ONLY` \(in its `include/AMReX_GpuQualifiers.H`\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2737/define-cctk_device-and-cctk_host-in-cactus -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jun 7 08:57:24 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 07 Jun 2023 13:57:24 +0000 Subject: [ET Trac] #2737: define CCTK_DEVICE and CCTK_HOST in Cactus Message-ID: #2737: define CCTK_DEVICE and CCTK_HOST in Cactus Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: minor Component: Cactus Comment (by Roland Haas): Alternatively one may also look for `__HCC__` and `__CUDACC__` according to [https://sep5.readthedocs.io/en/latest/Programming\_Guides/HIP-porting-guide.html](https://sep5.readthedocs.io/en/latest/Programming_Guides/HIP-porting-guide.html) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2737/define-cctk_device-and-cctk_host-in-cactus -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jun 7 23:05:21 2023 From: trac-noreply at einsteintoolkit.org (Vikram Manikantan) Date: Thu, 08 Jun 2023 04:05:21 +0000 Subject: [ET Trac] #2723: No boundary conditions registered for variables in group LEANBSSNMOL Message-ID: #2723: No boundary conditions registered for variables in group LEANBSSNMOL Reporter: Vikram Manikantan Status: resolved Milestone: ET_2023_05 Version: ET_2022_11 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Vikram Manikantan): @{557058:65c5f18c-c3ad-4126-bb2b-be0e766b31ef} @{557058:088051f9-5b94-4b5e-bfbe-71137030b9c1} Thanks for your replies. Even after using the updated master branch, the issue is still persistent. I even double checked that the changes in schedule.ccl have been made. Is this issue a concern? I am reopening this ticket. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2723/no-boundary-conditions-registered-for -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jun 7 23:05:52 2023 From: trac-noreply at einsteintoolkit.org (Vikram Manikantan) Date: Thu, 08 Jun 2023 04:05:52 +0000 Subject: [ET Trac] #2723: No boundary conditions registered for variables in group LEANBSSNMOL Message-ID: #2723: No boundary conditions registered for variables in group LEANBSSNMOL Reporter: Vikram Manikantan Status: open Milestone: ET_2023_05 Version: ET_2022_11 Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Vikram Manikantan): status: open (was resolved) Comment (by Vikram Manikantan): From latest comment. The issue is still present even with the suggested fixes, so I am reopening this ticket. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2723/no-boundary-conditions-registered-for -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 8 07:37:42 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 08 Jun 2023 12:37:42 +0000 Subject: [ET Trac] #2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic" Message-ID: #2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic" Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Hello all, not sure if this is already internally tracked by Canuda, but the commits that "remove parameter eta\_beta\_dynamic" seem to have made tests fail. See?[https://einsteintoolkit.github.io/tests/build\_683.html](https://einsteintoolkit.github.io/tests/build_683.html)?where it lists commit 12 and the failed tests. Unfortunately the ET test system had been offline for a bit \(due to GitHub removing python2 from the system\) and the change was not visible in the test results right away and so that report contains many \(unrelated\) changes. What I would guess are the relevant changes are: > ?? updated submodules > Submodule repos/lean\_public 0faaf83..7457e18: > > LeanBSSNMoL: remove parameter eta\_beta\_dynamic from test parameter files > > NPScalars \[schedule.ccl\]: fix scheduling of CalcNPScalars > > LeanBSSNMoL: remove unused parameters eta\_beta\_dynamic and moving\_eta\_transition > > LeanBSSNMoL \[schedule.ccl\]: remove sync call in LeanBSSN\_adm2bssn > > LeanBSSNMoL \[schedule.ccl\]: make sure that ApplyBCs at CCTK\_INITIAL is only called after Boundary\_SelectGroupForBC are set ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2738/caunda-proca-and-canuda-scalar-test -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 8 07:47:16 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 08 Jun 2023 12:47:16 +0000 Subject: [ET Trac] #2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic" Message-ID: #2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic" Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): @{557058:65c5f18c-c3ad-4126-bb2b-be0e766b31ef} @{557058:a2800088-fc6e-4fbe-9a1e-663271f736bd} some more details. The Einstein Toolkit tests still all pass in test run 682 on [https://einsteintoolkit.github.io/tests/](https://einsteintoolkit.github.io/tests/) then first fail in run 683 [https://einsteintoolkit.github.io/tests/build\_683.html](https://einsteintoolkit.github.io/tests/build_683.html) . The HTML page shows a list of changes that happened to the full ET repositories since the last run \(ie from 682 to 683\). Most of them are for nrpytutorial so unlikely to affect anything in Canuda or Lean\_public. The last recorded change though in LeanBSSLMoL and reports on the changes in git commits [0faaf83](https://bitbucket.org/einsteintoolkit/tickets/commits/0faaf83)..[7457e18](https://bitbucket.org/einsteintoolkit/tickets/commits/7457e18) of lean\_public \(you can see them using `git log 0faaf83..7457e18` in your checkout\): > updated submodules > Submodule repos/lean\_public [0faaf83](https://bitbucket.org/einsteintoolkit/tickets/commits/0faaf83)..[7457e18](https://bitbucket.org/einsteintoolkit/tickets/commits/7457e18): > > LeanBSSNMoL: remove parameter eta\_beta\_dynamic from test parameter files > NPScalars \[schedule.ccl\]: fix scheduling of CalcNPScalars > LeanBSSNMoL: remove unused parameters eta\_beta\_dynamic and moving\_eta\_transition > LeanBSSNMoL \[schedule.ccl\]: remove sync call in LeanBSSN\_adm2bssn > LeanBSSNMoL \[schedule.ccl\]: make sure that ApplyBCs at CCTK\_INITIAL is only called after Boundary\_SelectGroupForBC are set ? The HTML page contains links to the log files for each failing test in the ?Failed Tests and Changes? table. Eg. [https://github.com/EinsteinToolkit/tests/blob/gh-pages/records/version\_683/sim\_683\_2/NPScalars/teukolsky.log](https://github.com/EinsteinToolkit/tests/blob/gh-pages/records/version_683/sim_683_2/NPScalars/teukolsky.log) for the failing ?teukolsky? test in NPScalars. The teukolsky test seems to run without error message and then fails due to too large differences \(see the diff link in the table that shows the diff file that the Cactus test system produces: [https://github.com/EinsteinToolkit/tests/blob/gh-pages/records/version\_683/sim\_683\_1/NPScalars/teukolsky.diffs](https://github.com/EinsteinToolkit/tests/blob/gh-pages/records/version_683/sim_683_1/NPScalars/teukolsky.diffs) \) The others seem to fail with a parameter file error \(visible in their log files\): ``` WARNING[L1,P0] (Cactus): Major error in parameter file '/home/runner/simulations/TestJob01_temp_2/output-0000/arrangements/Scalar/TwoPunctures_BBHSF/test/SF_twopuncturesID_test.par' line 166: Parameter 'LeanBSSNMoL::eta_beta_dynamic' not found WARNING level 0 from host fv-az357-438.xjukslrwoije1kgjy1zwota3vf.cx.internal.cloudapp.net process 0 in thorn Cactus, file /home/runner/work/tests/tests/master/configs/sim/build/Cactus/main/ProcessParameterDatabase.c:201: -> CCTKi_SetParameterSetMask: 1 major error in parameter file WARNING[L1,P0] (Cactus): Major error in parameter file '/home/runner/simulations/TestJob01_temp_2/output-0000/arrangements/Scalar/TwoPunctures_BBHSF/test/SF_twopuncturesID_test.par' line 166: Parameter 'LeanBSSNMoL::eta_beta_dynamic' not found WARNING level 0 from host fv-az357-438.xjukslrwoije1kgjy1zwota3vf.cx.internal.cloudapp.net process 0 in thorn Cactus, file /home/runner/work/tests/tests/master/configs/sim/build/Cactus/main/ProcessParameterDatabase.c:201: -> CCTKi_SetParameterSetMask: 1 major error in parameter file WARNING[L1,P1] (Cactus): Major error in parameter file '/home/runner/simulations/TestJob01_temp_2/output-0000/arrangements/Scalar/TwoPunctures_BBHSF/test/SF_twopuncturesID_test.par' line 166: Parameter 'LeanBSSNMoL::eta_beta_dynamic' not found WARNING level 0 from host fv-az357-438.xjukslrwoije1kgjy1zwota3vf.cx.internal.cloudapp.net process 1 in thorn Cactus, file /home/runner/work/tests/tests/master/configs/sim/build/Cactus/main/ProcessParameterDatabase.c:201: -> CCTKi_SetParameterSetMask: 1 major error in parameter file -------------------------------------------------------------------------- MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD with errorcode 1. ``` which, if one scrolls to the right, refers to a parameter `LeanBSSNMoL::eta_beta_dynamic`which is not found. ?major? since it should be fixed before the next release and no know workaround \(to make the tests pass\) exists. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2738/caunda-proca-and-canuda-scalar-test -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 8 09:32:06 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 08 Jun 2023 14:32:06 +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: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn @{557058:3bd8b315-5aeb-4783-8a43-0585fee09596} reported [https://lists.einsteintoolkit.org/pipermail/users/2023-June/008942.html](https://lists.einsteintoolkit.org/pipermail/users/2023-June/008942.html) that the example parameter files still contains use of `ADMMacros::spatial_order` which `GRHydro` no longer uses and has been replaced in `GRHydro` by `GRHydro::sources_spatial_order`. Since ADMMacros is deprecated these should be removed from the par files. -- 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 Jun 8 09:33:23 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 08 Jun 2023 14:33:23 +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: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): Pull request is here: [https://bitbucket.org/einsteintoolkit/einsteininitialdata/pull-requests/17](https://bitbucket.org/einsteintoolkit/einsteininitialdata/pull-requests/17) -- 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 Jun 8 09:33:35 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 08 Jun 2023 14:33:35 +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 Changes (by Roland Haas): status: open (was new) Comment (by Roland Haas): Please review. -- 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 Jun 8 18:56:43 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Thu, 08 Jun 2023 23:56:43 +0000 Subject: [ET Trac] #2723: No boundary conditions registered for variables in group LEANBSSNMOL Message-ID: #2723: No boundary conditions registered for variables in group LEANBSSNMOL Reporter: Vikram Manikantan Status: open Milestone: ET_2023_05 Version: ET_2022_11 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): Looking more closely at the thorn, I feel its important to point out that it doesn?t have any READ or WRITE declarations. This means that no one has updated it to use the PreSync features. So even if you resolve the boundary warnings, it won?t really benefit you because the READ/WRITE declarations aren?t there yet. I?m sure the maintainers of Lean would be appreciative if you added them. However, if you don?t have the time to add those to the schedule.ccl, then none of the `presync_mode` settings can actually be used. I do think I have found the source of the issue, though. The issue is that the PreSync feature isn?t being informed of what the BCs are. The old boundary thorn uses `Boundary_SelectGroupForBC` to control how BCs are applied, while PreSync depends on the driver function `Driver_SelectGroupForBC`. At some point, I had suggested that this call be added to the `Boundary_SelectGroupForBC` as well for the sake of old thorns, but that doesn?t seem to have happened. I did a pretty ugly edit real quick by duplicating the boundary f?n calls with driver calls. This runs until it hits an error because PreSync tries to apply boundary conditions on something that isn?t valid in the interior \(and nothing is valid anywhere because of paragraph 1\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2723/no-boundary-conditions-registered-for -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 9 02:48:17 2023 From: trac-noreply at einsteintoolkit.org (Vikram Manikantan) Date: Fri, 09 Jun 2023 07:48:17 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Vikram Manikantan): Hello @{5bae587b96242d2e2b6110a4} , I implemented the changes in schedule.ccl in IlllinoisGRMHD as suggested, but it is still producing NaNs. See the output log of the simulation below. Please also see my above comment about replacing the SetTmunu group versus appending to the scheduler. Let me know what is the correct approach. Thanks. ![](https://bitbucket.org/repo/8zBLME5/images/3545285135-ILGRMHD_error.png) ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 9 07:11:10 2023 From: trac-noreply at einsteintoolkit.org (Bruno Giacomazzo) Date: Fri, 09 Jun 2023 12:11:10 +0000 Subject: [ET Trac] #2740: broken links in the Tutorial for New Users webpage Message-ID: #2740: broken links in the Tutorial for New Users webpage Reporter: Bruno Giacomazzo Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit website The link to the Github repository in ?Download the tutorial? \([https://github.com/einsteintoolkit/jupyter-et](https://github.com/einsteintoolkit/jupyter-et)\) and the one to the read only version of the CactusTutorial.ipynb notebook \([https://github.com/einsteintoolkit/jupyter-et/blob/master/tutorial-server/notebooks/CactusTutorial.ipynb](https://github.com/einsteintoolkit/jupyter-et/blob/master/tutorial-server/notebooks/CactusTutorial.ipynb)\) do not work anymore. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2740/broken-links-in-the-tutorial-for-new-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 9 08:14:10 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 09 Jun 2023 13:14:10 +0000 Subject: [ET Trac] #2740: broken links in the Tutorial for New Users webpage Message-ID: #2740: broken links in the Tutorial for New Users webpage Reporter: Bruno Giacomazzo Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit website Comment (by Roland Haas): Hello Bruno. Thanks for letting us know. Turns out I had forgotten to make the repository ?public? when moving it from the nds-org owned repository to an EinsteinToolkit owned one. Naturally, the private repo does work for me. Should be fixed now. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2740/broken-links-in-the-tutorial-for-new-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 9 08:14:25 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 09 Jun 2023 13:14:25 +0000 Subject: [ET Trac] #2740: broken links in the Tutorial for New Users webpage Message-ID: #2740: broken links in the Tutorial for New Users webpage Reporter: Bruno Giacomazzo Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): responsible: [] (was ) assignee: Roland Haas (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2740/broken-links-in-the-tutorial-for-new-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 9 08:27:27 2023 From: trac-noreply at einsteintoolkit.org (Bruno Giacomazzo) Date: Fri, 09 Jun 2023 13:27:27 +0000 Subject: [ET Trac] #2740: broken links in the Tutorial for New Users webpage Message-ID: #2740: broken links in the Tutorial for New Users webpage Reporter: Bruno Giacomazzo Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit website Comment (by Bruno Giacomazzo): Thanks Roland, I confirm they work now also for me. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2740/broken-links-in-the-tutorial-for-new-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 9 08:39:23 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 09 Jun 2023 13:39:23 +0000 Subject: [ET Trac] #2740: broken links in the Tutorial for New Users webpage Message-ID: #2740: broken links in the Tutorial for New Users webpage Reporter: Bruno Giacomazzo Status: resolved Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): status: resolved (was new) Comment (by Roland Haas): Thank you. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2740/broken-links-in-the-tutorial-for-new-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 9 10:29:47 2023 From: trac-noreply at einsteintoolkit.org (Gabriele Bozzola) Date: Fri, 09 Jun 2023 15:29:47 +0000 Subject: [ET Trac] #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Message-ID: #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Reporter: Gabriele Bozzola Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn A student in my group found the following problem in `ID_converter_ILGRMHD`: If you compile Einstein Toolkit in debug mode, the code crashes. This is due to the function `CCTK_GFINDEX4D` that is used in some thorns \(such as `ID_converter_ILGRMHD`\). The function is used to unroll a vector index into a linear one: ```c int CCTK_GFIndex4D (const cGH *GH, int i, int j, int k, int l) { #ifdef CCTK_DEBUG if (i < 0 || i >= GH->cctk_lsh[0] || j < 0 || j >= GH->cctk_lsh[1] || k < 0 || k >= GH->cctk_lsh[2] || l < 0 || l >= GH->cctk_lsh[3]) { CCTK_VError (__LINE__, __FILE__, "Cactus", "Grid function index out of bounds. i=%d j=%d k=%d l=%d cctk_lsh=[%d,%d,%d,%d]", i, j, k, l, GH->cctk_lsh[0], GH->cctk_lsh[1], GH->cctk_lsh[2], GH->cctk_lsh[3]); } #endif return (i + GH->cctk_ash[0]*(j + GH->cctk_ash[1]*(k + GH->cctk_ash[2] * l))); } ``` The code crashes when `CCTK_DEBUG` because cctk\_lsh\[3\] is 0, so the conditional in line 7 is not satisfied. To reproduce, run `magnetizedTOV.par `in IllinoisGRMHD with `CCTK_DEBUG` enabled. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2741/some-thorns-seem-to-incorrectly-use -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 9 10:42:54 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 09 Jun 2023 15:42:54 +0000 Subject: [ET Trac] #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Message-ID: #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Reporter: Gabriele Bozzola Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Still? Grr. I though tthat had been fixed in #2582 but clearly this was missed and also missed in #2394. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2741/some-thorns-seem-to-incorrectly-use -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 9 10:43:15 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 09 Jun 2023 15:43:15 +0000 Subject: [ET Trac] #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Message-ID: #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Reporter: Gabriele Bozzola Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): responsible: [] (was ) assignee: Zach Etienne (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2741/some-thorns-seem-to-incorrectly-use -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 9 10:43:23 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 09 Jun 2023 15:43:23 +0000 Subject: [ET Trac] #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Message-ID: #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Reporter: Gabriele Bozzola 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/2741/some-thorns-seem-to-incorrectly-use -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 9 10:46:35 2023 From: trac-noreply at einsteintoolkit.org (Leonardo Werneck) Date: Fri, 09 Jun 2023 15:46:35 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Leonardo Werneck): Hi @{712020:6db3039f-ec91-4049-9d17-ea10007f7722} ! Would it be possible for you to share a parameter file that results in this error? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 9 10:58:40 2023 From: trac-noreply at einsteintoolkit.org (Gabriele Bozzola) Date: Fri, 09 Jun 2023 15:58:40 +0000 Subject: [ET Trac] #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Message-ID: #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Reporter: Gabriele Bozzola Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Gabriele Bozzola): Let me double check what version we are running, maybe it was fixed and I rushed into reporting it! -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2741/some-thorns-seem-to-incorrectly-use -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 9 11:01:50 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 09 Jun 2023 16:01:50 +0000 Subject: [ET Trac] #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Message-ID: #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Reporter: Gabriele Bozzola Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Oh, it still is in the current version \(master, git hash [0cb4d23](https://bitbucket.org/zach_etienne/wvuthorns/commits/0cb4d23a59e511b9a3607178d9ca373c582e70d4) "Baikal & BaikalVacuum codegen: Add pip install sympy==1.11 to the automated codegen instructions" of [wvuthorns](https://bitbucket.org/zach_etienne/wvuthorns)\). We \(@{557058:8bc23f2a-45c0-477d-8ac4-a5a16c734278} and I\) just missed it in the last round of removing `CCTK_GFINDEX4D` and also missed it when handling a slightly different issue in `ID_converter_ILGRMHD` that actually showed lines with `CCTK_GFINDEX4D` in the ticket description. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2741/some-thorns-seem-to-incorrectly-use -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 9 11:05:00 2023 From: trac-noreply at einsteintoolkit.org (Gabriele Bozzola) Date: Fri, 09 Jun 2023 16:05:00 +0000 Subject: [ET Trac] #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Message-ID: #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Reporter: Gabriele Bozzola Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Gabriele Bozzola): Yes, we were running an older version and sorry for opening a duplicated ticket. The problem is now only in `wvuthorns_diagnostics` ``` particle_tracerET/src/compute_particles_four_velocities.C: const double vU[3] = { vel[CCTK_GFINDEX4D(cctkGH,i,j,k,0)], particle_tracerET/src/compute_particles_four_velocities.C: vel[CCTK_GFINDEX4D(cctkGH,i,j,k,1)], particle_tracerET/src/compute_particles_four_velocities.C: vel[CCTK_GFINDEX4D(cctkGH,i,j,k,2)] }; particle_tracerET/src/convert_to_MHD_3velocity.C: double ETvx = vel[CCTK_GFINDEX4D(cctkGH,i,j,k,0)]; particle_tracerET/src/convert_to_MHD_3velocity.C: double ETvy = vel[CCTK_GFINDEX4D(cctkGH,i,j,k,1)]; particle_tracerET/src/convert_to_MHD_3velocity.C: double ETvz = vel[CCTK_GFINDEX4D(cctkGH,i,j,k,2)]; Seed_Magnetic_Fields_BNS/src/Seed_Magnetic_Fields.C: Avec[CCTK_GFINDEX4D(cctkGH,i,j,k,0)] = -(y[index] + 0.5*dY)*A_b*pow(max(Pressure_at_Ax_stagger-P_cut,0.0),n_s); Seed_Magnetic_Fields_BNS/src/Seed_Magnetic_Fields.C: if(!have_two_NSs_along_x_axis) Avec[CCTK_GFINDEX4D(cctkGH,i,j,k,1)] = (xL + 0.5*dX)*A_b*pow(max(Pressure_at_Ay_stagger-P_cut,0.0),n_s); Seed_Magnetic_Fields_BNS/src/Seed_Magnetic_Fields.C: if(r1<=r_NS1) Avec[CCTK_GFINDEX4D(cctkGH,i,j,k,1)] = (x1 + 0.5*dX)*A_b*pow(max(Pressure_at_Ay_stagger-P_cut,0.0),n_s); Seed_Magnetic_Fields_BNS/src/Seed_Magnetic_Fields.C: if(r2<=r_NS2) Avec[CCTK_GFINDEX4D(cctkGH,i,j,k,1)] = (x2 + 0.5*dX)*A_b*pow(max(Pressure_at_Ay_stagger-P_cut,0.0),n_s); Seed_Magnetic_Fields_BNS/src/Seed_Magnetic_Fields.C: if(r1>r_NS1 && r2>r_NS2) Avec[CCTK_GFINDEX4D(cctkGH,i,j,k,1)] = 0.0; // No external B-field. Seed_Magnetic_Fields_BNS/src/Seed_Magnetic_Fields.C: Avec[CCTK_GFINDEX4D(cctkGH,i,j,k,0)] = - (yL + 0.5 * dY) * (Ap1 + Ap2); Seed_Magnetic_Fields_BNS/src/Seed_Magnetic_Fields.C: Avec[CCTK_GFINDEX4D(cctkGH,i,j,k,1)] = (x1 + 0.5 * dX) * Ap1 + (x2 + 0.5 * dX) * Ap2; Seed_Magnetic_Fields_BNS/src/Seed_Magnetic_Fields.C: Avec[CCTK_GFINDEX4D(cctkGH,i,j,k,2)] = 0.0; Seed_Magnetic_Fields_BNS/src/Seed_Magnetic_Fields.C: Avec[CCTK_GFINDEX4D(cctkGH,i,j,k,0)] = -y[index]*A_b*pow(max(PL-P_cut,0.0),n_s); Seed_Magnetic_Fields_BNS/src/Seed_Magnetic_Fields.C: Avec[CCTK_GFINDEX4D(cctkGH,i,j,k,1)] = x[index]*A_b*pow(max(PL-P_cut,0.0),n_s); Seed_Magnetic_Fields_BNS/src/Seed_Magnetic_Fields.C: Avec[CCTK_GFINDEX4D(cctkGH,i,j,k,2)] = 0.0; smallbPoynET/src/compute_bi_b2_Poyn_fluxET.C: double ETvx = vel[CCTK_GFINDEX4D(cctkGH,i,j,k,0)]; smallbPoynET/src/compute_bi_b2_Poyn_fluxET.C: double ETvy = vel[CCTK_GFINDEX4D(cctkGH,i,j,k,1)]; smallbPoynET/src/compute_bi_b2_Poyn_fluxET.C: double ETvz = vel[CCTK_GFINDEX4D(cctkGH,i,j,k,2)]; smallbPoynET/src/compute_bi_b2_Poyn_fluxET.C: double Bx_center = Bvec[CCTK_GFINDEX4D(cctkGH,i,j,k,0)]; smallbPoynET/src/compute_bi_b2_Poyn_fluxET.C: double By_center = Bvec[CCTK_GFINDEX4D(cctkGH,i,j,k,1)]; smallbPoynET/src/compute_bi_b2_Poyn_fluxET.C: double Bz_center = Bvec[CCTK_GFINDEX4D(cctkGH,i,j,k,2)]; ``` ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2741/some-thorns-seem-to-incorrectly-use -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 9 11:21:48 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 09 Jun 2023 16:21:48 +0000 Subject: [ET Trac] #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Message-ID: #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Reporter: Gabriele Bozzola Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): yup. I had not updated my own repo. Sorry about the confusion. `particle_tracerET` is actually a newly submitted module in the Schwarzschild release. Anyhow, assigned to @{557058:8bc23f2a-45c0-477d-8ac4-a5a16c734278} . -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2741/some-thorns-seem-to-incorrectly-use -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Sun Jun 11 21:16:21 2023 From: trac-noreply at einsteintoolkit.org (Vikram Manikantan) Date: Mon, 12 Jun 2023 02:16:21 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Vikram Manikantan): Hi @{5bae587b96242d2e2b6110a4} ! Yes, I am attaching it here. I also want to follow up on a previous question. Currently there is a SetTmunu scheduled in schedule.ccl and in your solution there is an AddToTmunu in the if statement. I am wondering if both should be in the file, or just the AddToTmunu? ? disk.par --> ``` ################################################################################ # Script variables ################################################################################ # __file__ = disk.rpar # __name__ = __main__ # bh_movement_threshold = 0.124 # carpet_str = CartGrid3D::type = "coordbase" # Carpet::domain_from_coordbase = "yes" # # Driver::ghost_size = 4 # CoordBase::boundary_size_x_lower = 4 # CoordBase::boundary_size_y_lower = 4 # CoordBase::boundary_size_z_lower = 4 # CoordBase::boundary_size_x_upper = 4 # CoordBase::boundary_size_y_upper = 4 # CoordBase::boundary_size_z_upper = 4 # # ReflectionSymmetry::avoid_origin_x = no # ReflectionSymmetry::avoid_origin_y = no # ReflectionSymmetry::avoid_origin_z = no # # CoordBase::domainsize = "minmax" # CoordBase::xmax = 5120.001785714286 # CoordBase::ymax = 5120.001785714286 # CoordBase::zmax = 5120.001785714286 # CoordBase::dx = 102.4 # CoordBase::dy = 102.4 # CoordBase::dz = 102.4 # CoordBase::xmin = -5119.998214285714 # CoordBase::ymin = -5119.998214285714 # CoordBase::zmin = -5119.998214285714 # # CarpetRegrid2::num_centres = 3 # Carpet::max_refinement_levels = 14 # Carpet::time_refinement_factors = "[1,1,1,1,1,1,1,1,1,2,4,8,16,32]" # # CarpetRegrid2::num_levels_1 = 14 # CarpetRegrid2::position_x_1 = -6.5 # CarpetRegrid2::position_y_1 = 0 # CarpetRegrid2::position_z_1 = 0 # CarpetRegrid2::radius_1[1] = 2539.52 # CarpetRegrid2::radius_1[2] = 1269.76 # CarpetRegrid2::radius_1[3] = 634.88 # CarpetRegrid2::radius_1[4] = 317.44 # CarpetRegrid2::radius_1[5] = 158.72 # CarpetRegrid2::radius_1[6] = 79.36 # CarpetRegrid2::radius_1[7] = 39.68 # CarpetRegrid2::radius_1[8] = 19.84 # CarpetRegrid2::radius_1[9] = 9.92 # CarpetRegrid2::radius_1[10] = 4.96 # CarpetRegrid2::radius_1[11] = 2.48 # CarpetRegrid2::radius_1[12] = 1.24 # CarpetRegrid2::radius_1[13] = 0.62 # CarpetRegrid2::num_levels_2 = 14 # CarpetRegrid2::position_x_2 = 6.5 # CarpetRegrid2::position_y_2 = 0 # CarpetRegrid2::position_z_2 = 0 # CarpetRegrid2::radius_2[1] = 2539.52 # CarpetRegrid2::radius_2[2] = 1269.76 # CarpetRegrid2::radius_2[3] = 634.88 # CarpetRegrid2::radius_2[4] = 317.44 # CarpetRegrid2::radius_2[5] = 158.72 # CarpetRegrid2::radius_2[6] = 79.36 # CarpetRegrid2::radius_2[7] = 39.68 # CarpetRegrid2::radius_2[8] = 19.84 # CarpetRegrid2::radius_2[9] = 9.92 # CarpetRegrid2::radius_2[10] = 4.96 # CarpetRegrid2::radius_2[11] = 2.48 # CarpetRegrid2::radius_2[12] = 1.24 # CarpetRegrid2::radius_2[13] = 0.62 # CarpetRegrid2::num_levels_3 = 11 # CarpetRegrid2::position_x_3 = 0 # CarpetRegrid2::position_y_3 = 0 # CarpetRegrid2::position_z_3 = 0 # CarpetRegrid2::radius_3[1] = 2539.52 # CarpetRegrid2::radius_3[2] = 1269.76 # CarpetRegrid2::radius_3[3] = 634.88 # CarpetRegrid2::radius_3[4] = 317.44 # CarpetRegrid2::radius_3[5] = 158.72 # CarpetRegrid2::radius_3[6] = 79.36 # CarpetRegrid2::radius_3[7] = 39.68 # CarpetRegrid2::radius_3[8] = 19.84 # CarpetRegrid2::radius_3[9] = 9.92 # CarpetRegrid2::radius_3[10] = 4.96 # cfl_condition = 1.5 # cfl_num = 0.45 # cfl_num_on_disk = 0.45 # col_width = 30 # damp_lorenz = 8 # diss_str = Dissipation::order = 7 # Dissipation::vars = "LeanBSSNMoL::conf_fac # LeanBSSNMoL::hmetric # LeanBSSNMoL::hcurv # LeanBSSNMoL::trk # LeanBSSNMoL::gammat # ADMBase::lapse # ADMBase::shift # LeanBSSNMoL::conf_fac # LeanBSSNMoL::hmetric # LeanBSSNMoL::hcurv # LeanBSSNMoL::trk # LeanBSSNMoL::gammat" # Dissipation::epsdis_for_level[0] = 1.953125e-05 # Dissipation::epsdis_for_level[1] = 3.90625e-05 # Dissipation::epsdis_for_level[2] = 7.8125e-05 # Dissipation::epsdis_for_level[3] = 0.00015625 # Dissipation::epsdis_for_level[4] = 0.0003125 # Dissipation::epsdis_for_level[5] = 0.000625 # Dissipation::epsdis_for_level[6] = 0.00125 # Dissipation::epsdis_for_level[7] = 0.0025 # Dissipation::epsdis_for_level[8] = 0.005 # Dissipation::epsdis_for_level[9] = 0.01 # Dissipation::epsdis_for_level[10] = 0.01 # Dissipation::epsdis_for_level[11] = 0.01 # Dissipation::epsdis_for_level[12] = 0.01 # Dissipation::epsdis_for_level[13] = 0.01 # Dissipation::epsdis_for_level[14] = 0.01 # dx_coarse = 102.4 # dx_fine = 0.0125 # dx_fine_on_disk = 3.2 # e = 2.718281828459045 # effective_cfl = 0.0017578125 # eps_dis = 0.01 # eta_beta = 2 # evolution_order = 6 # expected_ah_radius_minus = 0.5 # expected_ah_radius_plus = 0.5 # expected_final_ah_radius = 1.0 # expected_merger_time = 2000 # extr_radius = 200.0 # final_time = 4000 # ghosts = 4 # gw_radii_str = Multipole::radius[0] = 100.0 # Multipole::radius[1] = 114.28571428571429 # Multipole::radius[2] = 128.57142857142858 # Multipole::radius[3] = 142.85714285714286 # Multipole::radius[4] = 157.14285714285714 # Multipole::radius[5] = 171.42857142857144 # Multipole::radius[6] = 185.71428571428572 # Multipole::radius[7] = 200.0 # horizon_every = 64 # i = 7 # inf = inf # int_outer_boundary = 50 # key = xp # lorenz_condition = 1.5 # max_dt_allowed = 0.1875 # max_gw_radius = 200 # min_gw_radius = 100 # nan = nan # num_gw_radii = 8 # num_ref_radii = 13 # number_of_synced_levels = 9 # out_every_2D = 256 # out_every_3D = 1024 # outer_boundary = 5120.0 # outer_boundary_factor = 2 # outflow_radii_str = Outflow::surface_index[0] = 5 # Outflow::override_radius[0] = "yes" # Outflow::radius[0] = 100.0 # Outflow::surface_index[1] = 5 # Outflow::override_radius[1] = "yes" # Outflow::radius[1] = 114.28571428571429 # Outflow::surface_index[2] = 5 # Outflow::override_radius[2] = "yes" # Outflow::radius[2] = 128.57142857142858 # Outflow::surface_index[3] = 5 # Outflow::override_radius[3] = "yes" # Outflow::radius[3] = 142.85714285714286 # Outflow::surface_index[4] = 5 # Outflow::override_radius[4] = "yes" # Outflow::radius[4] = 157.14285714285714 # Outflow::surface_index[5] = 5 # Outflow::override_radius[5] = "yes" # Outflow::radius[5] = 171.42857142857144 # Outflow::surface_index[6] = 5 # Outflow::override_radius[6] = "yes" # Outflow::radius[6] = 185.71428571428572 # Outflow::surface_index[7] = 5 # Outflow::override_radius[7] = "yes" # Outflow::radius[7] = 200.0 # par_b = 6.5 # pi = 3.141592653589793 # radius = 2539.52 # radius0 = 0.62 # radius_number = 1 # refinement_level_radius_factor = 2 # regrid_every = 256 # rl_synced_every = 32 # rlrf = 2 # skip_radii = 3 # step_gw_radius = 14.285714285714286 # tau = 6.283185307179586 # timers_every = 1024 # tp_str = ADMBase::initial_data = "twopuncturespowerlaw" # ADMBase::initial_lapse = "twopunctures-averaged" # ADMBase::initial_shift = "zero" # ADMBase::initial_dtlapse = "zero" # ADMBase::initial_dtshift = "zero" # # TwoPuncturesPowerLaw::give_bare_mass = "no" # TwoPuncturesPowerLaw::par_b = 6.5 # TwoPuncturesPowerLaw::target_m_plus = 0.5 # TwoPuncturesPowerLaw::target_m_minus = 0.5 # TwoPuncturesPowerLaw::par_m_plus = 0.5 # TwoPuncturesPowerLaw::par_m_minus = 0.5 # TwoPuncturesPowerLaw::par_P_plus[0] = -0.000413874209381327 # TwoPuncturesPowerLaw::par_P_plus[1] = 0.0807444483485998 # TwoPuncturesPowerLaw::par_P_plus[2] = 0 # TwoPuncturesPowerLaw::par_P_minus[0] = 0.000413874209381327 # TwoPuncturesPowerLaw::par_P_minus[1] = -0.0807444483485998 # TwoPuncturesPowerLaw::par_P_minus[2] = 0 # TwoPuncturesPowerLaw::par_S_plus[0] = 0.0 # TwoPuncturesPowerLaw::par_S_plus[1] = 0.0 # TwoPuncturesPowerLaw::par_S_plus[2] = 0.0 # TwoPuncturesPowerLaw::par_S_minus[0] = 0.0 # TwoPuncturesPowerLaw::par_S_minus[1] = 0.0 # TwoPuncturesPowerLaw::par_S_minus[2] = 0.0 # TwoPuncturesPowerLaw::center_offset[0] = 0.0 # TwoPuncturesPowerLaw::center_offset[1] = 0.0 # TwoPuncturesPowerLaw::center_offset[2] = 0.0 # val = 6.5 # wave_extract_every = 32 # xm = -6.5 # xp = 6.5 ################################################################################ # Par file ################################################################################ ActiveThorns = " ADMBase ADMCoupling ADMMacros AEILocalInterp AHFinderDirect Boundary Carpet CarpetIOASCII CarpetIOBasic CarpetIOHDF5 CarpetIOScalar CarpetInterp CarpetLib # CarpetMask CarpetReduce CarpetRegrid2 CarpetSlab CarpetTracker CartGrid3D # Christoffel Convert_to_HydroBase CoordBase CoordGauge CycleClock # DiskDiagnostics Dissipation EOS_Base EOS_Omni Fortran GenericFD GSL ID_converter_ILGRMHD IllinoisGRMHD HydroBase HDF5 hwloc IOUtil InitBase LeanBSSNMoL LocalInterp LoopControl MoL MPI Multipole NaNChecker NewRad NPScalars PunctureTracker QuasiLocalMeasures OpenBLAS Outflow Seed_Magnetic_Fields Slab SpaceMask SphericalSurface StaticConformal SummationByParts SymBase SystemStatistics SystemTopology TerminationTrigger TensorTypes TGRTensor Time Timers TimerReport TmunuBase TwoPuncturesPowerLaw Vectors VolumeIntegrals_GRMHD zlib ReflectionSymmetry " # # Cactus::presync_mode = "mixed-error" #################################################################### # Grid details #################################################################### Carpet::use_buffer_zones = "yes" Carpet::init_3_timelevels = "no" Carpet::init_fill_timelevels = "yes" Carpet::verbose = "no" Carpet::veryverbose = "no" Carpet::schedule_barriers = "no" Carpet::storage_verbose = "no" Grid::avoid_origin = "no" Time::dtfac = 0.0017578125 Cactus::terminate = time Cactus::cctk_final_time = 4000 MoL::ODE_Method = "rk4" MoL::MoL_Intermediate_Steps = 4 MoL::MoL_Num_Scratch_Levels = 1 Carpet::prolongation_order_space = 5 Carpet::prolongation_order_time = 2 Cactus::cctk_full_warnings = "yes" Cactus::highlight_warning_messages = "no" CarpetLib::poison_new_memory = "yes" CarpetLib::poison_value = 113 CarpetLib::output_bboxes = "no" CarpetLib::interleave_communications = "yes" CarpetLib::combine_sends = "yes" CarpetLib::support_staggered_operators = "yes" # IllinoisGRMHD requires staggered operators CarpetRegrid2::freeze_unaligned_levels = "yes" CarpetRegrid2::freeze_unaligned_parent_levels = "yes" CarpetRegrid2::verbose = "yes" CarpetRegrid2::regrid_every = 256 CartGrid3D::type = "coordbase" Carpet::domain_from_coordbase = "yes" Driver::ghost_size = 4 CoordBase::boundary_size_x_lower = 4 CoordBase::boundary_size_y_lower = 4 CoordBase::boundary_size_z_lower = 4 CoordBase::boundary_size_x_upper = 4 CoordBase::boundary_size_y_upper = 4 CoordBase::boundary_size_z_upper = 4 ReflectionSymmetry::avoid_origin_x = no ReflectionSymmetry::avoid_origin_y = no ReflectionSymmetry::avoid_origin_z = no CoordBase::domainsize = "minmax" CoordBase::xmax = 5120.001785714286 CoordBase::ymax = 5120.001785714286 CoordBase::zmax = 5120.001785714286 CoordBase::dx = 102.4 CoordBase::dy = 102.4 CoordBase::dz = 102.4 CoordBase::xmin = -5119.998214285714 CoordBase::ymin = -5119.998214285714 CoordBase::zmin = -5119.998214285714 CarpetRegrid2::num_centres = 3 Carpet::max_refinement_levels = 14 Carpet::time_refinement_factors = "[1,1,1,1,1,1,1,1,1,2,4,8,16,32]" CarpetRegrid2::num_levels_1 = 14 CarpetRegrid2::position_x_1 = -6.5 CarpetRegrid2::position_y_1 = 0 CarpetRegrid2::position_z_1 = 0 CarpetRegrid2::radius_1[1] = 2539.52 CarpetRegrid2::radius_1[2] = 1269.76 CarpetRegrid2::radius_1[3] = 634.88 CarpetRegrid2::radius_1[4] = 317.44 CarpetRegrid2::radius_1[5] = 158.72 CarpetRegrid2::radius_1[6] = 79.36 CarpetRegrid2::radius_1[7] = 39.68 CarpetRegrid2::radius_1[8] = 19.84 CarpetRegrid2::radius_1[9] = 9.92 CarpetRegrid2::radius_1[10] = 4.96 CarpetRegrid2::radius_1[11] = 2.48 CarpetRegrid2::radius_1[12] = 1.24 CarpetRegrid2::radius_1[13] = 0.62 CarpetRegrid2::num_levels_2 = 14 CarpetRegrid2::position_x_2 = 6.5 CarpetRegrid2::position_y_2 = 0 CarpetRegrid2::position_z_2 = 0 CarpetRegrid2::radius_2[1] = 2539.52 CarpetRegrid2::radius_2[2] = 1269.76 CarpetRegrid2::radius_2[3] = 634.88 CarpetRegrid2::radius_2[4] = 317.44 CarpetRegrid2::radius_2[5] = 158.72 CarpetRegrid2::radius_2[6] = 79.36 CarpetRegrid2::radius_2[7] = 39.68 CarpetRegrid2::radius_2[8] = 19.84 CarpetRegrid2::radius_2[9] = 9.92 CarpetRegrid2::radius_2[10] = 4.96 CarpetRegrid2::radius_2[11] = 2.48 CarpetRegrid2::radius_2[12] = 1.24 CarpetRegrid2::radius_2[13] = 0.62 CarpetRegrid2::num_levels_3 = 11 CarpetRegrid2::position_x_3 = 0 CarpetRegrid2::position_y_3 = 0 CarpetRegrid2::position_z_3 = 0 CarpetRegrid2::radius_3[1] = 2539.52 CarpetRegrid2::radius_3[2] = 1269.76 CarpetRegrid2::radius_3[3] = 634.88 CarpetRegrid2::radius_3[4] = 317.44 CarpetRegrid2::radius_3[5] = 158.72 CarpetRegrid2::radius_3[6] = 79.36 CarpetRegrid2::radius_3[7] = 39.68 CarpetRegrid2::radius_3[8] = 19.84 CarpetRegrid2::radius_3[9] = 9.92 CarpetRegrid2::radius_3[10] = 4.96 CarpetRegrid2::movement_threshold_1 = 0.124 CarpetRegrid2::movement_threshold_2 = 0.124 CarpetRegrid2::movement_threshold_3 = 0.124 #################################################################### # Initial Data #################################################################### InitBase::initial_data_setup_method = "init_some_levels" HydroBase::initial_Avec = "zero" HydroBase::initial_Aphi = "zero" HydroBase::initial_Bvec = "zero" HydroBase::initial_hydro = "twopuncturespowerlaw" TwoPuncturesPowerLaw::ell_inner = 5.15 TwoPuncturesPowerLaw::sam_disk = 0.0 TwoPuncturesPowerLaw::RoM_inner = 18.0 IllinoisGRMHD::gamma_th = 1.333333333333333333333333333 ID_converter_ILGRMHD::Gamma_Initial = 1.333333333333333333333333333 # rho_max = 1 IllinoisGRMHD::K_poly = 7.98742131429e-4 ID_converter_ILGRMHD::K_Initial = 7.98742131429e-4 IllinoisGRMHD::rho_b_atm = 1e-8 IllinoisGRMHD::tau_atm = 1e-7 IllinoisGRMHD::compute_extra_diagnostics = "yes" ADMBase::initial_data = "twopuncturespowerlaw" ADMBase::initial_lapse = "twopunctures-averaged" ADMBase::initial_shift = "zero" ADMBase::initial_dtlapse = "zero" ADMBase::initial_dtshift = "zero" TwoPuncturesPowerLaw::give_bare_mass = "no" TwoPuncturesPowerLaw::par_b = 6.5 TwoPuncturesPowerLaw::target_m_plus = 0.5 TwoPuncturesPowerLaw::target_m_minus = 0.5 TwoPuncturesPowerLaw::par_m_plus = 0.5 TwoPuncturesPowerLaw::par_m_minus = 0.5 TwoPuncturesPowerLaw::par_P_plus[0] = -0.000413874209381327 TwoPuncturesPowerLaw::par_P_plus[1] = 0.0807444483485998 TwoPuncturesPowerLaw::par_P_plus[2] = 0 TwoPuncturesPowerLaw::par_P_minus[0] = 0.000413874209381327 TwoPuncturesPowerLaw::par_P_minus[1] = -0.0807444483485998 TwoPuncturesPowerLaw::par_P_minus[2] = 0 TwoPuncturesPowerLaw::par_S_plus[0] = 0.0 TwoPuncturesPowerLaw::par_S_plus[1] = 0.0 TwoPuncturesPowerLaw::par_S_plus[2] = 0.0 TwoPuncturesPowerLaw::par_S_minus[0] = 0.0 T -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Sun Jun 11 21:20:19 2023 From: trac-noreply at einsteintoolkit.org (Vikram Manikantan) Date: Mon, 12 Jun 2023 02:20:19 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Vikram Manikantan): Parameter file that produces this issue -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Sun Jun 11 21:21:23 2023 From: trac-noreply at einsteintoolkit.org (Vikram Manikantan) Date: Mon, 12 Jun 2023 02:21:23 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Vikram Manikantan): Hi @{5bae587b96242d2e2b6110a4} ! Yes, I am attaching it above. I also want to follow up on a previous question. Currently there is a SetTmunu scheduled in schedule.ccl and in your solution there is an AddToTmunu in the if statement. I am wondering if both should be in the file, or just the AddToTmunu? ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Jun 12 03:38:12 2023 From: trac-noreply at einsteintoolkit.org (Miguel Zilhão) Date: Mon, 12 Jun 2023 08:38:12 +0000 Subject: [ET Trac] #2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic" Message-ID: #2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic" Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Miguel Zilh?o): This was indeed a problem, but it should have been fixed with commit [https://bitbucket.org/canuda/lean\_public/commits/7457e1822e3a880efd67e11f163671b2f5a55c07](https://bitbucket.org/canuda/lean_public/commits/7457e1822e3a880efd67e11f163671b2f5a55c07) On my machine all tests are currently passing? Is this still a problem with the current master branch? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2738/caunda-proca-and-canuda-scalar-test -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Jun 12 08:57:46 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Mon, 12 Jun 2023 13:57:46 +0000 Subject: [ET Trac] #2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic" Message-ID: #2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic" Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Yes, this is still happening. You can take a look at the tests at [https://einsteintoolkit.github.io/tests/](https://einsteintoolkit.github.io/tests/) The LeanBSSN\_Ei\_mu0.4\_c0.05.log test \(you can click on the ?log? link to access the output file\) fails with ``` Major error in parameter file '/home/runner/simulations/TestJob01_temp_1/output-0000/arrangements/Proca/NPScalars_Proca/test/LeanBSSN_Ei_mu0.4_c0.05.par' line 150: Parameter 'LeanBSSNMoL::eta_beta_dynamic' not found ``` which should also fail on your system Did you maybe forget to push all changes? I just tried and I get a test failure for the LeabBSSN Ei test as well after a fresh checkout on my workstation: ``` ./GetComponents --parallel --shallow https://bitbucket.org/einsteintoolkit/manifest/raw/master/einsteintoolkit.th ``` Please note that there are apparently multiple tests in Canuda named `LeanBSSN_Ei_mu0.4_c0.05.par` and the one that fails is `./repos/Proca/NPScalars_Proca/test/LeanBSSN_Ei_mu0.4_c0.05.par`. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2738/caunda-proca-and-canuda-scalar-test -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Mon Jun 12 09:28:01 2023 From: trac-noreply at einsteintoolkit.org (Miguel Zilhão) Date: Mon, 12 Jun 2023 14:28:01 +0000 Subject: [ET Trac] #2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic" Message-ID: #2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic" Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Miguel Zilh?o): I see, sorry, I should have read properly the description that this is happening in the scalar and proca arrangements :-\) I've removed the parameter that was giving problems in the following commits: * [https://bitbucket.org/canuda/proca/commits/d24ddf835b0552410175fab2f6f84fe1a537575a](https://bitbucket.org/canuda/proca/commits/d24ddf835b0552410175fab2f6f84fe1a537575a) * [https://bitbucket.org/canuda/scalar/commits/44df0f7bb4afa01b406a5876acd107ae2bf439d9](https://bitbucket.org/canuda/scalar/commits/44df0f7bb4afa01b406a5876acd107ae2bf439d9) I hope this is now fixed. ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2738/caunda-proca-and-canuda-scalar-test -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jun 13 16:11:18 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Tue, 13 Jun 2023 21:11:18 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): I?m not sure what your schedule.ccl currently looks like, but the master branch of \`IllinoisGRMHD\` only has those two functions \(which I?ll refer to as con2prim\) in AddToTmunu, not SetTmunu. Did you also add it to SetTmunu? All Leo did was change the scheduling from something that looks like ``` schedule con2prim in AddToTmunu ``` to ``` if(stress_energy_at_RHS) { schedule con2prim in AddToTmunu } else { schedule con2prim in HydroBase_Con2Prim } ``` ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jun 13 16:12:10 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Tue, 13 Jun 2023 21:12:10 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): If you could also post the scheduling output at the start of the run, that might help me know what is wrong. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jun 13 16:32:02 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Tue, 13 Jun 2023 21:32:02 +0000 Subject: [ET Trac] #2742: Change Seed_Magnetic_Fields scheduling so it can be used by more thorns Message-ID: #2742: Change Seed_Magnetic_Fields scheduling so it can be used by more thorns Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Right now, this thorn schedules based on the `ID_converter_ILGRMHD` function, preventing it from being used out-of-the-box by `GRHayLMHD`. I could change the scheduling to explicitly depend on this thorn, but a cleaner solution is to make their scheduling be based on HydroBase?s groups, providing a more consistent interface. As such, I propose that the seeding function be set to run `before HydroBase_Prim2ConInitial`. There?s a similar issue with Seed\_Magnetic\_Fields\_BNS in that it can only be guaranteed to work with `Meudon_Bin_NS`. Since both thorns should be changed to behave in a similar manner, I propose simply merging them into one. An example of this is in a [PR](https://bitbucket.org/zach_etienne/wvuthorns/pull-requests/14). However, I?m not sure of the best way to handle the deprecation/behavior changes. It might be simpler to just make a new thorn \(possibly in the GRHayL repo\) that provides the combined thorn while keeping the old ones in their current state. This PR also contains a bug fix for `ID_converter_GiRaFFE` and a very small optional feature for `IllinoisGRMHD` which I can make separately if we decide to make a new thorn instead of changing the existing one. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2742/change-seed_magnetic_fields-scheduling-so -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jun 13 16:33:48 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Tue, 13 Jun 2023 21:33:48 +0000 Subject: [ET Trac] #2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic" Message-ID: #2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic" Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Still fails _one_ \(1\) test: [https://einsteintoolkit.github.io/tests/build\_689.html](https://einsteintoolkit.github.io/tests/build_689.html) Note that the table lists 1 Failed Test and 4 Newly Passing Tests ie your commit fixed 4 tests. There was a bit of a delay since I had to do some emergency cleanup so that the test do not run out of quota on GitHub \(we have accumulated about ~20GB of test results in the repository and GitHub does not like this\). The tests all run right now, but the failing one \(teukolsky in NPSacalars\) shows significant \(ie higher than the set threshold\) differences from the recorded known-good values. See eg the diffs files linked \(the link labelled ?diffs? in the table\) on the website for the build: [https://github.com/EinsteinToolkit/tests/blob/gh-pages/records/version\_689/sim\_689\_1/NPScalars/teukolsky.diffs](https://github.com/EinsteinToolkit/tests/blob/gh-pages/records/version_689/sim_689_1/NPScalars/teukolsky.diffs) I have \(obviously\) no clue if this due to data needing to be regenerated due to the committed code changes or if this is some sort of roundoff level sensitivity that would require a less stringent error threshold to pass on multiple machines due to different compiler settings. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2738/caunda-proca-and-canuda-scalar-test -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jun 13 16:34:44 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Tue, 13 Jun 2023 21:34:44 +0000 Subject: [ET Trac] #2742: Change Seed_Magnetic_Fields scheduling so it can be used by more thorns Message-ID: #2742: Change Seed_Magnetic_Fields scheduling so it can be used by more thorns Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): @{557058:8bc23f2a-45c0-477d-8ac4-a5a16c734278} , I would like your input on how you?d like me to change the scheduling, and whether you prefer two thorns or one. It seems strange for Seed\_Magnetic\_Fields\_BNS to be in the diagnostics repo, especially when we can just have 1 thorn to provide both. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2742/change-seed_magnetic_fields-scheduling-so -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jun 13 16:59:45 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Tue, 13 Jun 2023 21:59:45 +0000 Subject: [ET Trac] #2742: Change Seed_Magnetic_Fields scheduling so it can be used by more thorns Message-ID: #2742: Change Seed_Magnetic_Fields scheduling so it can be used by more thorns Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} In regards to deprecation, correct me if I?m wrong: the best approach to merge the two thorns is to A\) Introduce the extra stuff to SMF to allow for BNS as well B\) Ensure the default behavior of Seed\_Magnetic\_Fields \(SMF\) is as before C\) Add deprecation warning for SMF\_BNS thorn D\) In the release after the one where this is added, remove the SMF\_BNS thorn entirely -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2742/change-seed_magnetic_fields-scheduling-so -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jun 13 17:22:29 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Tue, 13 Jun 2023 22:22:29 +0000 Subject: [ET Trac] #2742: Change Seed_Magnetic_Fields scheduling so it can be used by more thorns Message-ID: #2742: Change Seed_Magnetic_Fields scheduling so it can be used by more thorns Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): Also, what is the preferred method for alerting users to a deprecated feature? `CCTK_VWARN`?`CCTK_VINFO`? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2742/change-seed_magnetic_fields-scheduling-so -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jun 13 18:22:33 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Tue, 13 Jun 2023 23:22:33 +0000 Subject: [ET Trac] #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Message-ID: #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Reporter: Gabriele Bozzola Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): I pushed a commit to `wvuthorns_diagnostics` to change the `CCTK_GFINDEX4D` to `CCTK_VECTGFINDEX3D` for `Seed_Magnetic_Fields_BNS`, `particle_tracerET`, and `smallbPoynET`. If there are any issues, let me know. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2741/some-thorns-seem-to-incorrectly-use -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jun 13 20:18:46 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Wed, 14 Jun 2023 01:18:46 +0000 Subject: [ET Trac] #2742: Change Seed_Magnetic_Fields scheduling so it can be used by more thorns Message-ID: #2742: Change Seed_Magnetic_Fields scheduling so it can be used by more thorns Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Hello Sam, what official docs we have on this is here: [https://docs.einsteintoolkit.org/et-docs/Policies\_to\_retire\_functionality](https://docs.einsteintoolkit.org/et-docs/Policies_to_retire_functionality) So more or less what you describe. Expect this to still catch people by surprise though. There is an \(inofficial since I don't think we ever really discussed keeping it\) list of deprecated and retired functionality that I try to keep here: [https://docs.einsteintoolkit.org/et-docs/Deprecated\_features](https://docs.einsteintoolkit.org/et-docs/Deprecated_features) \(but the last entry is from 2020 so it is almost certainly not up to date\). No warning in the thorn to be deprecated is needed. Other codes do that, increasing levels of annoyance as the deprecation date, which is a fixed date recorded in the code, comes closer, up to and including refusing to _run_ if the compiled functionality is too old. In the ET the warning comes in the form of a list of deprecated features in the release announcements and discussion in the ET calls. Previous advise wrt to breaking changes is eg here: Note that you cannot deprecate \(change\) default parameter _values_, since that would lead to silent changes in behaviour. This is not foolproof of course, just look at the trouble we have with `GRHydro::sources_spatial_order` and `ADMMacros::spatial_order`. Or at least it must have been a very very long time that anyone has ever relied on that default. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2742/change-seed_magnetic_fields-scheduling-so -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jun 14 00:48:23 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Wed, 14 Jun 2023 05:48:23 +0000 Subject: [ET Trac] #2742: Change Seed_Magnetic_Fields scheduling so it can be used by more thorns Message-ID: #2742: Change Seed_Magnetic_Fields scheduling so it can be used by more thorns Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): Yeah, the only parameter changes are that the `Afield_type` parameter options are ambiguously named if I added in BNS as well, so I prepended TOV or BNS to all the keywords. This doesn?t matter for BNS, since those are new to the thorn. For the TOV case, I also have the old parameter names in there for now with a deprecation warning. The behavior is identical \(all the cases have something like `if(old_name || new_name)`. Eventually, I would want to phase out the `old_name`, but that could be done at any time, basically. The default is `new_name`, but there?s no real difference between the two. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2742/change-seed_magnetic_fields-scheduling-so -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jun 14 07:31:55 2023 From: trac-noreply at einsteintoolkit.org (Vikram Manikantan) Date: Wed, 14 Jun 2023 12:31:55 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Vikram Manikantan): Hi Samuel, I adjusted my schedule.ccl so it looks like the master branch - the SetTmunu was an error on my end. My file contains the if\(stress\_energy\_at\_RHS\) as described by Leo and yourself. I am attaching an out file from my most recent test run. Let me know if that is enough and if there is anything else I can provide. Thanks for your help! -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jun 14 07:32:33 2023 From: trac-noreply at einsteintoolkit.org (Vikram Manikantan) Date: Wed, 14 Jun 2023 12:32:33 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Vikram Manikantan): [dot]out file from most recent test run -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jun 14 15:29:34 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Wed, 14 Jun 2023 20:29:34 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): If I make the change in `IllinoisGRMHD`?s schedule.ccl and run the test parfile `magnetizedTOV.par`, I don?t get any issues with `stress_energy_at_RHS` on or off. As such, I?m not sure if the issue is with `IllinoisGRMHD` itself. Particularly, the values that are `nan` when Con2Prim starts are the B field and the metric. The B field I could envision potentially having an issue if the setup for the scheduling were wrong, but the fact that all the spacetime quantities are `nan` seems to suggest there could be something wrong with the spacetime evolution or ID. ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 15 07:55:33 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 15 Jun 2023 12:55:33 +0000 Subject: [ET Trac] #2735: EinsteinBase: storage declaration simplification Message-ID: #2735: EinsteinBase: storage declaration simplification Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: trivial Component: EinsteinToolkit thorn Comment (by Roland Haas): Well. It?s historic \(not surprisingly\). Being able to use variables in the storage statement is newer than ADMBase is, and I am not sure if ``` STORAGE: lapse[0] ``` would have been acceptable \(since one could just leave out the statemetnt altogether without loss if only constants are allowed anyway\). I think there are parameter files out there that want storage for lapse but not for dtlapse \(eg lapse for output only and dtlapse is not desired\). If storage was enabled for dtshift then this will consume more memory \(probably not too bad\) and also \(more importantly\) subjuect dtshift to poisoning, and consistency checks by presync which may \(if sufficiently aggressive options are chosen\) make the code stop. So the ugly way of disabling storage by setting ?initial\_shift? to ?none? probably has to stay. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2735/einsteinbase-storage-declaration -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 15 09:27:53 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 15 Jun 2023 14:27:53 +0000 Subject: [ET Trac] #2647: incorrect WENO coefficient in GRHydro WENO reconstruction code Message-ID: #2647: incorrect WENO coefficient in GRHydro WENO reconstruction code Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): The interpolation vs. reconstruction behaviour should be checked against PPM to decide if WENO or WENOZ coefficients should be updated \(one is reconstruction the other one is interpolation\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2647/incorrect-weno-coefficient-in-grhydro-weno -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 15 09:43:59 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Thu, 15 Jun 2023 14:43:59 +0000 Subject: [ET Trac] #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Message-ID: #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Reporter: Gabriele Bozzola Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): I had missed one file in `particle_tracerET`, but I have pushed that as well now. I am closing the ticket since `grep`ing for `CCTK_GFINDEX4D` gets nothing in `wvuthorns` and `wvuthorns_diagnostics`. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2741/some-thorns-seem-to-incorrectly-use -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 15 09:44:23 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Thu, 15 Jun 2023 14:44:23 +0000 Subject: [ET Trac] #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Message-ID: #2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D Reporter: Gabriele Bozzola Status: resolved Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Samuel Cupp): status: resolved (was open) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2741/some-thorns-seem-to-incorrectly-use -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 15 09:51:25 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Thu, 15 Jun 2023 14:51:25 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): My previous comment was incorrect, as I forgot to also set `update_Tmunu`. I do get nans when I set that. I haven?t tried to debug this, but my guess is that moving this to a different bin leads to the A->B routine happening in a different place relative to con2prim, which causes this issue. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 15 10:09:04 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Thu, 15 Jun 2023 15:09:04 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): To have more correct scheduling, change the `in HydroBase_Con2Prim` to `in HydroBase_PostStep after HydroBase_Con2Prim.` This is because that con2prim group also runs in PostPostInitial where IllinoisGRMHD manually schedules functions. This should only put it in the places where AddToTmunu appears. I still get nans, but I don?t have time right now to track down where they come from. If you track down where they first appear, please let me know. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 16 02:49:37 2023 From: trac-noreply at einsteintoolkit.org (Miguel Zilhão) Date: Fri, 16 Jun 2023 07:49:37 +0000 Subject: [ET Trac] #2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic" Message-ID: #2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic" Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Miguel Zilh?o): That one was was due to another commit, and indeed the data needed to be regenerated. I?ve done so here: [https://bitbucket.org/canuda/lean\_public/commits/e13352d877a5a5b6699a9ec668df4f677deccf93](https://bitbucket.org/canuda/lean_public/commits/e13352d877a5a5b6699a9ec668df4f677deccf93) I hope this fixes it. The test now passes on my machine, but at the moment I have no other machine to try. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2738/caunda-proca-and-canuda-scalar-test -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 16 11:00:00 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 16 Jun 2023 16:00:00 +0000 Subject: [ET Trac] #2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic" Message-ID: #2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic" Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Tests are all passing again. [https://einsteintoolkit.github.io/tests/build\_693.html](https://einsteintoolkit.github.io/tests/build_693.html) Thank you! I?ll close the ticket. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2738/caunda-proca-and-canuda-scalar-test -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 16 12:44:40 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 16 Jun 2023 17:44:40 +0000 Subject: [ET Trac] #2735: EinsteinBase: storage declaration simplification Message-ID: #2735: EinsteinBase: storage declaration simplification Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: trivial Component: EinsteinToolkit thorn Comment (by Roland Haas): Applied as git hash [db5777d](https://bitbucket.org/einsteintoolkit/einsteinbase/commits/db5777d1f921254d3e8d489c5b2e2b1c336113ef) "TmunuBase: schedule cleanup" of [einsteinbase](https://bitbucket.org/einsteintoolkit/einsteinbase) Thanks for the patch. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2735/einsteinbase-storage-declaration -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 16 12:44:53 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 16 Jun 2023 17:44:53 +0000 Subject: [ET Trac] #2735: EinsteinBase: storage declaration simplification Message-ID: #2735: EinsteinBase: storage declaration simplification Reporter: Samuel Cupp Status: resolved Milestone: ET_2023_11 Version: Type: enhancement Priority: trivial Component: EinsteinToolkit thorn Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2735/einsteinbase-storage-declaration -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jun 27 22:47:45 2023 From: trac-noreply at einsteintoolkit.org (Vikram Manikantan) Date: Wed, 28 Jun 2023 03:47:45 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Vikram Manikantan): The scheduling is already `in HydroBase_Con2Prim after IllinoisGRMHD_conserv_to_prims`. Do you mean to make it `in HydroBase_PostStep after HydroBase_Con2Prim after IllinoisGRMHD_conserv_to_prims` or just `in HydroBase_PostStep after HydroBase_Con2Prim`? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Tue Jun 27 22:48:56 2023 From: trac-noreply at einsteintoolkit.org (Vikram Manikantan) Date: Wed, 28 Jun 2023 03:48:56 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Vikram Manikantan): Also, I do not have `update_Tmunu` in my scheduler anywhere. What do you mean when you say you set this? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Wed Jun 28 01:23:21 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Wed, 28 Jun 2023 06:23:21 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): It?s been a while since I looked at it, but I think it should be `in HydroBase_PostStep after HydroBase_Con2Prim`. `update_Tmunu` is a parameter, not something in the scheduler. If you don?t want IllinoisGRMHD to ever set Tmunu, then you need to set that to `no` in the parfile. It defaults to `yes`. I didn?t get nans with `update_Tmunu=yes`, but I did with `update_Tmunu=no`. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 29 08:56:41 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 29 Jun 2023 13:56:41 +0000 Subject: [ET Trac] #2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic" Message-ID: #2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic" Reporter: Roland Haas Status: resolved Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2738/caunda-proca-and-canuda-scalar-test -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Thu Jun 29 09:49:25 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Thu, 29 Jun 2023 14:49:25 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): There was some discussion on this in the Einstein Toolkit call just now. The situation seems that one can enable Tmunu storage but disable Tmunu being actually set by setting `TmunuBase::stress_energy_storage = yes` and `TmunuBase::stress_energy_at_RHS = no` . `TmunuBase` relies on running in `MoL_PostStep`. Since `Tmunu` is a derived quantity like the primitives it may be most consistent with other codes to have `Tmunu` set at INITIAL at the same time say `HydroBase_Con2PrimInitial` is running by scheduling the `SetTmunu` group in there instead of only in `MoL_PostStep`. This would rely on checking on `ADMSbase_SetADMVars` and possible touch `HydroBase` as well in case setting Tmunu uses primitive variables. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 30 12:15:05 2023 From: trac-noreply at einsteintoolkit.org (Roland Haas) Date: Fri, 30 Jun 2023 17:15:05 +0000 Subject: [ET Trac] #2743: debug output from rdwr.pl when it cannot find variables Message-ID: #2743: debug output from rdwr.pl when it cannot find variables Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: Cactus if one mistypes a variable name in schedule.ccl then there is debug output produced to screen \(or at least this better be debug output and not intended for regular user level error messages\). Note the `rwdw.pl` file name reference somewhere in the middle of the Perl hash dump. ``` CST error in /autofs/nccs-svm1_home1/haas/ET/Cactus/repos/flesh/lib/sbin/CreateScheduleBindings.pl (at 795) -> Could not determine gtype for 'regcheck::rhshar' Use of uninitialized value in string eq at /autofs/nccs-svm1_home1/haas/ET/Cactus/repos/flesh/lib/sbin/CreateScheduleBindings.pl line 833. CST warning in /autofs/nccs-svm1_home1/haas/ET/Cactus/repos/flesh/lib/sbin/CreateScheduleBindings.pl (at 943) -> Schedule error: Thorn RegCheck - group or variable rhshar doesn't exist. Creating function bindings... Generating arguments... $VAR1 = { 'rhsvar5' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'var20' => { 'impl' => 'REGCHECK', 'ntimelevels' => '1', 'type' => 'REAL' }, 'rhsvar9' => { 'ntimelevels' => '1', 'type' => 'REAL', 'impl' => 'REGCHECK' }, 'var18' => { 'ntimelevels' => '1', 'type' => 'REAL', 'impl' => 'REGCHECK' }, 'rhsvar3' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'var13' => { 'impl' => 'REGCHECK', 'ntimelevels' => '1', 'type' => 'REAL' }, 'var23' => { 'type' => 'REAL', 'ntimelevels' => '1', 'impl' => 'REGCHECK' }, 'var12' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'rhsvar2' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'var5' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'var6' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'rhsvar' => { 'type' => 'REAL', 'ntimelevels' => '1', 'impl' => 'REGCHECK' }, 'var4' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'var3' => { 'type' => 'REAL', 'ntimelevels' => '1', 'impl' => 'REGCHECK' }, 'rhsvar11' => { 'ntimelevels' => '1', 'type' => 'REAL', 'impl' => 'REGCHECK' }, 'rhsvar15' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'rhsvar10' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'rhsvar18' => { 'type' => 'REAL', 'ntimelevels' => '1', 'impl' => 'REGCHECK' }, 'rhsvar22' => { 'impl' => 'REGCHECK', 'ntimelevels' => '1', 'type' => 'REAL' }, 'rhsvar14' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'var15' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'rhsvar17' => { 'type' => 'REAL', 'ntimelevels' => '1', 'impl' => 'REGCHECK' }, 'var' => { 'type' => 'REAL', 'ntimelevels' => '1', 'impl' => 'REGCHECK' }, 'rhsvar7' => { 'impl' => 'REGCHECK', 'ntimelevels' => '1', 'type' => 'REAL' }, 'var9' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'var8' => { 'type' => 'REAL', 'ntimelevels' => '1', 'impl' => 'REGCHECK' }, 'rhsvar21' => { 'ntimelevels' => '1', 'type' => 'REAL', 'impl' => 'REGCHECK' }, 'rhsvar8' => { 'type' => 'REAL', 'ntimelevels' => '1', 'impl' => 'REGCHECK' }, 'rhsvar23' => { 'type' => 'REAL', 'ntimelevels' => '1', 'impl' => 'REGCHECK' }, 'var7' => { 'impl' => 'REGCHECK', 'ntimelevels' => '1', 'type' => 'REAL' }, 'var25' => { 'impl' => 'REGCHECK', 'ntimelevels' => '1', 'type' => 'REAL' }, 'var2' => { 'ntimelevels' => '1', 'type' => 'REAL', 'impl' => 'REGCHECK' }, 'var21' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'rhsvar20' => { 'type' => 'REAL', 'ntimelevels' => '1', 'impl' => 'REGCHECK' }, 'var11' => { 'type' => 'REAL', 'ntimelevels' => '1', 'impl' => 'REGCHECK' }, 'var22' => { 'impl' => 'REGCHECK', 'ntimelevels' => '1', 'type' => 'REAL' }, 'var14' => { 'ntimelevels' => '1', 'type' => 'REAL', 'impl' => 'REGCHECK' }, 'var27' => { 'impl' => 'REGCHECK', 'ntimelevels' => '1', 'type' => 'REAL' }, 'var26' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'regrid_error' => { 'impl' => 'CARPETX', 'type' => 'REAL', 'ntimelevels' => '1' }, 'rhsvar4' => { 'type' => 'REAL', 'ntimelevels' => '1', 'impl' => 'REGCHECK' }, 'var17' => { 'type' => 'REAL', 'ntimelevels' => '1', 'impl' => 'REGCHECK' }, 'var10' => { 'impl' => 'REGCHECK', 'ntimelevels' => '1', 'type' => 'REAL' }, 'rhsvar19' => { 'impl' => 'REGCHECK', 'ntimelevels' => '1', 'type' => 'REAL' }, 'rhsvar1' => { 'impl' => 'REGCHECK', 'ntimelevels' => '1', RegCheck / rhshar at /autofs/nccs-svm1_home1/haas/ET/Cactus/repos/flesh/lib/sbin/rdwr.pl line 289. 'type' => 'REAL' }, 'rhsvar24' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'rhsvar28' => { 'type' => 'REAL', 'ntimelevels' => '1', 'impl' => 'REGCHECK' }, 'rhsvar6' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'rhsvar27' => { 'impl' => 'REGCHECK', 'ntimelevels' => '1', 'type' => 'REAL' }, 'var19' => { 'ntimelevels' => '1', 'type' => 'REAL', 'impl' => 'REGCHECK' }, 'rhsvar13' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'rhsvar25' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'var24' => { 'ntimelevels' => '1', 'type' => 'REAL', 'impl' => 'REGCHECK' }, 'rhsvar16' => { 'impl' => 'REGCHECK', 'type' => 'REAL', 'ntimelevels' => '1' }, 'var16' => { 'ntimelevels' => '1', 'type' => 'REAL', 'impl' => 'REGCHECK' }, 'var1' => { 'ntimelevels' => '1', 'type' => 'REAL', 'impl' => 'REGCHECK' }, 'var28' => { 'ntimelevels' => '1', 'type' => 'REAL', 'impl' => 'REGCHECK' }, 'rhsvar12' => { 'ntimelevels' => '1', 'type' => 'REAL', 'impl' => 'REGCHECK' }, 'rhsvar26' => { 'type' => 'REAL', 'ntimelevels' => '1', 'impl' => 'REGCHECK' } }; make[1]: *** No rule to make target '/autofs/nccs-svm1_home1/haas/ET/Cactus/configs/sim/config-data/make.thornlist', needed by '/autofs/nccs-svm1_home1/haas/ET/Cactus/exe/cactus_sim'. Stop. make: *** [Makefile:265: sim] Error 2 ``` ? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2743/debug-output-from-rdwrpl-when-it-cannot -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 30 14:20:17 2023 From: trac-noreply at einsteintoolkit.org (Vikram Manikantan) Date: Fri, 30 Jun 2023 19:20:17 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Vikram Manikantan): I will set `update_Tmunu=yes` and see if that fixes it for me - at least we?ll be on the same page then. However, in the long term, this will make the simulation more expensive. Shouldn?t Con2Prim work regardless of the update\_Tmunu setting? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac-noreply at einsteintoolkit.org Fri Jun 30 15:47:03 2023 From: trac-noreply at einsteintoolkit.org (Samuel Cupp) Date: Fri, 30 Jun 2023 20:47:03 +0000 Subject: [ET Trac] #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Message-ID: #2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): Well, I don't really know what you're doing, but update\_Tmunu=?no? means that IGM will _never_ set Tmunu. I'm guessing you want it to be set at least at initialization. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-incompatible-with-setting -------------- next part -------------- An HTML attachment was scrubbed... URL: