Trac March 2022

trac@lists.einsteintoolkit.org

1 participants
48 discussions

#2518: retire BlueGene/Q support in thorn vectors
by Roland Haas 30 Mar '22

30 Mar '22

#2518: retire BlueGene/Q support in thorn vectors Reporter: Roland Haas Status: open Milestone: Version: development version Type: task Priority: minor Component: Comment (by Roland Haas): Unless objected I will apply this after 2022-04-13 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2518/retire-bluegene-q…

1 0

#2172: Test "Binary black hole GW150914" example
by Roland Haas 24 Mar '22

24 Mar '22

#2172: Test "Binary black hole GW150914" example Reporter: Roland Haas Status: open Milestone: ET_2021_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): status: open (was resolved) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2172/test-binary-black…

1 0

#2602: include Regge-Wheeler-Zerilli gauge self-force code in ET
by Samuel Cupp 18 Mar '22

18 Mar '22

#2602: include Regge-Wheeler-Zerilli gauge self-force code in ET Reporter: Samuel Cupp Status: new Milestone: ET_2022_05 Version: development version Type: enhancement Priority: major Component: Other The RWZ self-force code extends Peter Diener’s 1D self-force code to be able to evolve the gravitational self-force in the Regge-Wheeler-Zerilli gauge using master functions. The code is currently capable of handling circular orbits and will be extended to eccentric orbits and inspirals in the future. It also includes observers for metric reconstruction, energy and angular momentum flux, and strain output. The pull request for the new code can be found at [https://bitbucket.org/peterdiener/selfforce-1d/pull-requests/2](https://bit…. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2602/include-regge-whe…

1 0

#2596: EinsteinInitialData/TwoPunctures: Allocated memory is not freed
by Zach Etienne 17 Mar '22

17 Mar '22

1 0

#2596: EinsteinInitialData/TwoPunctures: Allocated memory is not freed
by Zach Etienne 17 Mar '22

17 Mar '22

#2596: EinsteinInitialData/TwoPunctures: Allocated memory is not freed Reporter: Zach Etienne Status: open Milestone: Version: development version Type: bug Priority: major Component: Changes (by Zach Etienne): attachment: Newton.patch (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…) Comment (by Zach Etienne): I attach the patch. Note that 90%\+ of the patch is just updated indentation to account for the update in logic needed for the fix. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2596/einsteininitialda…

1 0

#2601: Add four more parameters for carpet
by Liwei Ji 17 Mar '22

17 Mar '22

#2601: Add four more parameters for carpet Reporter: Liwei Ji Status: new Milestone: Version: development version Type: enhancement Priority: major Component: Carpet Hi all, we have added four more parameters to `carpet`: 1. `uniformly_split_interior_points_x` 2. `uniformly_split_interior_points_y` 3. `uniformly_split_interior_points_z` 4. `symmetrically_distribute_points_y` The first three parameters are used to distribute the grid points across processors uniformly according to interior points only. The fourth parameter is used to distribute the \(even number of\) grid points across \(even number of\) processors with the first and second half being translational symmetric to each other in y-dir, when the grid points are not divisible by the number of processors in y-dir. Attached please find the diff with the `master` branch. Thanks! attachment: diff.out (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2601/add-four-more-par…

1 0

#2600: `CCTK_CENTERING_GF` is applied to grid scalars
by Erik Schnetter 17 Mar '22

17 Mar '22

#2600: `CCTK_CENTERING_GF` is applied to grid scalars Reporter: Erik Schnetter Status: new Milestone: Version: development version Type: bug Priority: major Component: It seems that Cactus applies the `CCTK_CENTERING_GF` macro not just to grid functions, but also to grid scalars. This fails at run time since CarpetX notices that the `GF3D2` class doesn’t work for grid scalars. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2600/cctk_centering_gf…

1 0

#2254: let Cactus thorns register citation requests at runtime
by Roland Haas 14 Mar '22

14 Mar '22

#2254: let Cactus thorns register citation requests at runtime Reporter: Roland Haas Status: open Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): Put back into hackathon pool for now. Current status is that Formaline code is present \(it hash [e948a33](https://bitbucket.org/cactuscode/cactusutils/commits/e948a332269cc…) and produces bibtex files. Would want know requested citations [https://www.einsteintoolkit.org/citation.html](https://www.einsteintoolkit.… added to various ET thorns that list them. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2254/let-cactus-thorns…

1 0

#2599: nsnstohmns cannot be reproduced using LORENE2
by Roland Haas 14 Mar '22

14 Mar '22

#2599: nsnstohmns cannot be reproduced using LORENE2 Reporter: Ken Hui Status: open Milestone: ET_2021_05 Version: ET_2021_05 Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): So based on your tests their seems to be good evidence that indeed the change in constants in `unites.h` is responsible or the failure \(since you can make LORENE1 runs fail but only changing `unites.h`\). Unfortunately, I doubt there is much the ET can do about this since the changes in the constants are all on the <1% level. Other than a warning to use “compatible” versions of LORENE when reading in data files, which in itself is not terribly helpful. If LORENE encodes a version number in its output files, then the ET can try and check the number and warn if the version number in the file disagrees with the runtime version. It will generate a lot of false positive “version does not match, be careful” warnings so most likely will be ignored by most researchers. For the gallery example, it may be possible to make things work by using a slightly higher resolution \(the one the gallery is very low, and really not science-worthy\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2599/nsnstohmns-cannot…

1 0

#963: Improve McLachlan accuracy
by Roland Haas 14 Mar '22

14 Mar '22

#963: Improve McLachlan accuracy Reporter: Erik Schnetter Status: open Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): @{557058:f7fd5133-6eee-4385-a5e5-3e03342a0b24} did you have time to look into this? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/963/improve-mclachlan-…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac March 2022