Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D
by Samuel Cupp 15 Jun '23

15 Jun '23

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

1 0

#2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D
by Samuel Cupp 15 Jun '23

15 Jun '23

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

1 0

#2647: incorrect WENO coefficient in GRHydro WENO reconstruction code
by Roland Haas 15 Jun '23

15 Jun '23

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

1 0

#2735: EinsteinBase: storage declaration simplification
by Roland Haas 15 Jun '23

15 Jun '23

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

1 0

#2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no"
by Samuel Cupp 14 Jun '23

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

1 0

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

14 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): [dot]out file from most recent test run -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-…

1 0

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

14 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): 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-…

1 0

#2742: Change Seed_Magnetic_Fields scheduling so it can be used by more thorns
by Samuel Cupp 14 Jun '23

14 Jun '23

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

1 0

#2742: Change Seed_Magnetic_Fields scheduling so it can be used by more thorns
by Roland Haas 13 Jun '23

13 Jun '23

#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\_functionalit… 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… \(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_magne…

1 0

#2741: Some thorns seem to incorrectly use CCTK_GFINDEX4D
by Samuel Cupp 13 Jun '23

13 Jun '23

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

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac