Trac June 2023

trac@lists.einsteintoolkit.org

1 participants
81 discussions

#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

#2742: Change Seed_Magnetic_Fields scheduling so it can be used by more thorns
by Samuel Cupp 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 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_magne…

1 0

#2742: Change Seed_Magnetic_Fields scheduling so it can be used by more thorns
by Samuel Cupp 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 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_magne…

1 0

#2742: Change Seed_Magnetic_Fields scheduling so it can be used by more thorns
by Samuel Cupp 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 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_magne…

1 0

#2738: Caunda/Proca and Canuda/Scalar test faiilures after commits that "remove parameter eta_beta_dynamic"
by Roland Haas 13 Jun '23

13 Jun '23

#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://einsteinto… 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… 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-…

1 0

#2742: Change Seed_Magnetic_Fields scheduling so it can be used by more thorns
by Samuel Cupp 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 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_magne…

1 0

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

13 Jun '23

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac June 2023