Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2736: consider using git+https together with a branch name or kuibit install
by Gabriele Bozzola 02 Jun '23

02 Jun '23

#2736: consider using git+https together with a branch name or kuibit install Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: trivial Component: Other Comment (by Gabriele Bozzola): I can see another drawback to this. When you install kuibit with `pip install kuibit`, you are served the wheels from PyPI. These are very small files \(460 kB\) and are supposed to work immediately on all the supported architectures/versions. When you install kuibit from git, you have to download the entire repo \(along with the tests, some data files, and so on, and the entire git history\), which can be 100s of MBs - 1 GB. Moreover, you have to recompile the package locally. This should not be a problem for 99 % of the cases, but I would not be surprised if there were incompatibilities in some cases. So, as developer, I would prefer sticking with PyPI for the slightly better user experience, but I do not feel strongly about this. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2736/consider-using-gi…

1 0

#2736: consider using git+https together with a branch name or kuibit install
by Roland Haas 02 Jun '23

02 Jun '23

#2736: consider using git+https together with a branch name or kuibit install Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: trivial Component: Other Each ET release is tied to a specific kuibit version and @{557058:4b0c8315-696b-4d2e-92da-2da5fea9e8d4} allows the ET to create branches and tags in kuibit. Yet to then install kuibit the instruction in the ET use numeric version numbers `1.4.0` or so and thus a code which may not actually match up with the ET branch `ET_YYYY_MM` of any release \(unless special care is taken by the release coordinator to create a release branch of the version \(tag\) that will be used for the release\). It may be interesting to consider instead to use: ```shell pip install git+https://github.com/Sbozzolo/kuibit@ET_2023_05 ``` instead. At least from the point of view of consistent ET versions. The downside of course being that this probably breaks pip’s logic to compare newer versions and may inundate kuibit’s bug tracker with version numbers that are really ET versions and not kuibit version.s -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2736/consider-using-gi…

1 0

#2723: No boundary conditions registered for variables in group LEANBSSNMOL
by Roland Haas 02 Jun '23

02 Jun '23

#2723: No boundary conditions registered for variables in group LEANBSSNMOL Reporter: Vikram Manikantan Status: resolved Milestone: ET_2023_05 Version: ET_2022_11 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Thank you for the fix. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2723/no-boundary-condi…

1 0

#2723: No boundary conditions registered for variables in group LEANBSSNMOL
by Roland Haas 02 Jun '23

02 Jun '23

#2723: No boundary conditions registered for variables in group LEANBSSNMOL Reporter: Vikram Manikantan Status: resolved Milestone: ET_2023_05 Version: ET_2022_11 Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2723/no-boundary-condi…

1 0

#2723: No boundary conditions registered for variables in group LEANBSSNMOL
by Miguel Zilhão 02 Jun '23

02 Jun '23

#2723: No boundary conditions registered for variables in group LEANBSSNMOL Reporter: Vikram Manikantan Status: new Milestone: ET_2023_05 Version: ET_2022_11 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Miguel Zilhão): I’ve now merged the master branch with development, so this change should now be present also in master. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2723/no-boundary-condi…

1 0

#2735: EinsteinBase: storage declaration simplification
by Samuel Cupp 01 Jun '23

01 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 Samuel Cupp): Right now, the PR removed them in ADMBase. They remain in HydroBase because there are many different variables using the same parameter that one may or may not need in a given run. Essentially, the ‘initial\_Y\_e’ and similar parameters are serving to determine whether these variables are active. However, in ADMBase the only variables with this behavior are `dtshift`, `dtlapse`, and `shift`. There’s definitely no need for shift to do this, as its storage is already controlled by `shift_timelevels`. The only question is whether we need to reintroduce the ``` if (! CCTK_Equals(initial_dtlapse, "none")) { dtlapse[lapse_timelevels] } if (! CCTK_Equals(initial_dtshift, "none")) { dtshift[shift_timelevels] } ``` ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2735/einsteinbase-stor…

1 0

#2735: EinsteinBase: storage declaration simplification
by Samuel Cupp 01 Jun '23

01 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 Samuel Cupp): The only question is whether we want to preserve the \(imo strange\) behavior of ADMBase and TmunuBase which ignores the requested timelevels if they aren’t initialized to zero. Zeroing can be an option, but to me it seems like enforcing it prevents people from using poisoning to notice bad behavior. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2735/einsteinbase-stor…

1 0

#2735: EinsteinBase: storage declaration simplification
by Samuel Cupp 01 Jun '23

01 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 Samuel Cupp): The associated PR is [here](https://bitbucket.org/einsteintoolkit/einsteinbase/pull-requests/5). Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2735/einsteinbase-stor…

1 0

#2735: EinsteinBase: storage declaration simplification
by Samuel Cupp 01 Jun '23

01 Jun '23

#2735: EinsteinBase: storage declaration simplification Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: trivial Component: EinsteinToolkit thorn Currently, the various \*Base thorns declare storage like ``` if (timelevels == 1) { STORAGE: stress_energy_scalar[1] STORAGE: stress_energy_vector[1] STORAGE: stress_energy_tensor[1] } else if (timelevels == 2) { STORAGE: stress_energy_scalar[2] STORAGE: stress_energy_vector[2] STORAGE: stress_energy_tensor[2] } else if (timelevels == 3) { STORAGE: stress_energy_scalar[3] STORAGE: stress_energy_vector[3] STORAGE: stress_energy_tensor[3] } ``` We can instead just say ``` STORAGE: stress_energy_scalar[timelevels] STORAGE: stress_energy_vector[timelevels] STORAGE: stress_energy_tensor[timelevels] ``` This, of course, will properly declare the storage depending on the parameter at runtime. As I understand the behavior, this also works for timelevels = 0. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2735/einsteinbase-stor…

1 0

#2663: add an notice about minimum Intel / GCC version required to configure output
by Roland Haas 01 Jun '23

01 Jun '23

#2663: add an notice about minimum Intel / GCC version required to configure output Reporter: Roland Haas Status: resolved Milestone: Version: Type: enhancement Priority: major Component: Changes (by Roland Haas): status: resolved (was new) Comment (by Roland Haas): Thank you. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2663/add-an-notice-abo…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac