Trac August 2023

trac@lists.einsteintoolkit.org

1 participants
55 discussions

#2748: Inclusion of SpaceTimeX in Einstein Toolkit
by Samuel Cupp 17 Aug '23

17 Aug '23

#2748: Inclusion of SpaceTimeX in Einstein Toolkit Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): @{557058:56049c54-f8c2-4b6c-9b88-ab697c967495} Please provide the list of thorns to be included in the release as soon as possible. The deadline for reviews is only a month away, so this will be quite difficult to meet if reviews do not start soon. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2748/inclusion-of-spac…

1 0

#2748: Inclusion of SpaceTimeX in Einstein Toolkit
by Samuel Cupp 17 Aug '23

17 Aug '23

#2748: Inclusion of SpaceTimeX in Einstein Toolkit Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): @{557058:d079f9c2-ad27-47b2-bf4b-ecc6bbe288b0} is a reviewer. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2748/inclusion-of-spac…

1 0

#2748: Inclusion of SpaceTimeX in Einstein Toolkit
by Samuel Cupp 17 Aug '23

17 Aug '23

#2748: Inclusion of SpaceTimeX in Einstein Toolkit Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn SpaceTimeX is an arrangement containing a collection of thorns for spacetime initial data, evolution, and analysis with CarpetX. ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2748/inclusion-of-spac…

1 0

#2695: Inclusion of AsterX in the Einstein Toolkit
by tootle 17 Aug '23

17 Aug '23

#2695: Inclusion of AsterX in the Einstein Toolkit Reporter: Jay Kalinani Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by tootle): I can offer being a reviewer if need be -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2695/inclusion-of-aste…

1 0

#2747: Inclusion of sgrid importer in Einstein Toolkit
by Samuel Cupp 17 Aug '23

17 Aug '23

#2747: Inclusion of sgrid importer in Einstein Toolkit Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn SGRID is a code for generating binary neutron star data with arbitrary masses, spins and orbital eccentricities. This thorn provides an interface to import SGRID initial data into the Einstein Toolkit. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgri…

1 0

#2653: Carpet PreSync triggering syncs for all refinement levels unnecessarily
by Samuel Cupp 10 Aug '23

10 Aug '23

#2653: Carpet PreSync triggering syncs for all refinement levels unnecessarily Reporter: Samuel Cupp Status: new Milestone: Version: Type: bug Priority: major Component: Carpet Comment (by Samuel Cupp): Thinking about this problem again, I think that this PR is not the proper solution. The recursive syncs are not the core problem if I remember correctly. It has been some time since I’ve looked at this, but as I recall the core issue was when I had no BCs registered for a variable. I had another PR $accepted a while ago$ that added a warning for this, but originally there was a silent issue when trying to sync \+ apply BCs to a variable with no BCs registered. Carpet PreSync sees that it is valid in the interior and schedules these routines, but the BC call is effectively empty because nothing is registered. It silently returns to the function and then continues on. This means that it syncs every time something tries to read it because it is always at best `interior+ghosts`, and applying BCs always includes syncs. This ticket comes from the fact that the recursive part of the code accumulates these syncs, recursively syncs everything all the time, which is terrible. There should be something in Carpet or Boundary that properly warns/errors due to this, but that doesn’t seem to be the case. Once this behavior is fixed, we can see if we need this change to the recursive part of the code or not. However, my current thinking $having admittedly not looked at this for quite some time$ is that this is more a mitigation of the issue than a true fix. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2653/carpet-presync-tr…

1 0

#2745: Inclusion of GRHayL library and associated MHD thorns
by Samuel Cupp 07 Aug '23

07 Aug '23

#2745: Inclusion of GRHayL library and associated MHD thorns Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): The CarpetX thorns are also in the GRHayLET repo, but require CarpetX to compile. They are ``` GRHayLET/GRHayLIDX GRHayLET/GRHayLHDX ``` `GRHayLET/IllinoisGRMHDX` is still in a separate branch being debugged, and I will update when it is merged or if it won’t make it in time for the release. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2745/inclusion-of-grha…

1 0

#2745: Inclusion of GRHayL library and associated MHD thorns
by Samuel Cupp 07 Aug '23

07 Aug '23

#2745: Inclusion of GRHayL library and associated MHD thorns Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): To check out the Carpet-based thorns, simply add ``` !TARGET = $ARR !TYPE = git !URL = https://github.com/GRHayL/GRHayL.git !REPO_BRANCH = main !REPO_PATH= implementations/$2 !CHECKOUT = GRHayL/GRHayLib !TARGET = $ARR !TYPE = git !URL = https://github.com/GRHayL/GRHayLET.git !REPO_BRANCH = main !REPO_PATH= $2 !CHECKOUT = GRHayLET/GRHayLHD GRHayLET/GRHayLMHD #GRHayLET/IllinoisGRMHD GRHayLET/GRHayLID ``` Note that `GRHayLMHD` is the current name of `IllinoisGRMHD` on the main branch, as I am still comparing with `IllinoisGRMHD` and wanted to compile them together. In the release, it will be `IllinoisGRMHD`, and the thorn in the WVUThorns arrangement will be removed. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2745/inclusion-of-grha…

1 0

#2706: Update default TwoPunctures parameters, or at least default parameters in BBH gallery example
by Zach Etienne 07 Aug '23

07 Aug '23

#2706: Update default TwoPunctures parameters, or at least default parameters in BBH gallery example Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit website Changes (by Zach Etienne): title: Update default TwoPunctures parameters, or at least default parameters in BBH gallery example (was increase TwoPunctures resolution in BBH gallery example) Comment (by Zach Etienne): There are two major improvements I would recommend. The first is for TwoPunctures, and the second for the BBH gallery example: 1. For most binary black hole simulations, the early evolution constraint violations are dominated by the initial data, when using the default TwoPunctures grid resolution of 30x30x16. I strongly recommend increasing the default resolution to at least 48x48x20. 2. The BBH gallery example has a rather unusual choice of initial lapse, setting it to the average value of 1 - m\_i / $2r\_i$ for both punctures i. More typically the initial lapse is set to the “pre-collapsed” value of psi^\{-2\} which goes like 1 - M/r at large radii for total binary mass M. This is the same asymptotic behavior that the will lapse relax to, and so this choice results in less gauge dynamics than the “averaged lapse” value. TwoPunctures supports `initial_lapse = "psi^n"` and chooses a perfectly fine default value of `n=initial_lapse_psi_exponent=-2` . Note that the BBH gallery example is negatively impacted by $1$ as well. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2706/update-default-tw…

1 0

#2308: SummationByParts: Use centred stencils on multipatch symmetry boundaries
by Roland Haas 07 Aug '23

07 Aug '23

#2308: SummationByParts: Use centred stencils on multipatch symmetry boundaries Reporter: Roland Haas Status: open Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): @{557058:ae98ab72-3754-49e1-9230-5c814d4c790b} is this still relevant? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2308/summationbyparts-…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2023