Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D
by Roland Haas 09 Jun '23

09 Jun '23

#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-…

1 0

#2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D
by Gabriele Bozzola 09 Jun '23

09 Jun '23

#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-…

1 0

#2740: broken links in the Tutorial for New Users webpage
by Roland Haas 09 Jun '23

09 Jun '23

#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-t…

1 0

#2740: broken links in the Tutorial for New Users webpage
by Bruno Giacomazzo 09 Jun '23

09 Jun '23

#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-t…

1 0

#2740: broken links in the Tutorial for New Users webpage
by Roland Haas 09 Jun '23

09 Jun '23

#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-t…

1 0

#2740: broken links in the Tutorial for New Users webpage
by Roland Haas 09 Jun '23

09 Jun '23

#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-t…

1 0

#2740: broken links in the Tutorial for New Users webpage
by Bruno Giacomazzo 09 Jun '23

09 Jun '23

#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-t…

1 0

#2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no"
by Vikram Manikantan 09 Jun '23

09 Jun '23

#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-…

1 0

#2723: No boundary conditions registered for variables in group LEANBSSNMOL
by Samuel Cupp 08 Jun '23

08 Jun '23

#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-condi…

1 0

#2739: change ADMMacros::spatial_order to GRHydro::sources_spatial_order in Hydro_RNSID example parfiles
by Roland Haas 08 Jun '23

08 Jun '23

#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-…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac