Trac February 2023

trac@lists.einsteintoolkit.org

1 participants
41 discussions

#2697: Include BBH+scalar field initial data code from Canuda in ET
by Roland Haas 16 Feb '23

16 Feb '23

#2697: Include BBH+scalar field initial data code from Canuda in ET Reporter: Cheng-Hsin Cheng Status: new Milestone: Version: Type: enhancement Priority: major Component: Changes (by Roland Haas): priority: major (was minor) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2697/include-bbh-scala…

1 0

#2692: Inclusion of FUKA importer thorns
by Roland Haas 16 Feb '23

16 Feb '23

#2692: Inclusion of FUKA importer thorns Reporter: tootle Status: new Milestone: ET_2023_05 Version: ET_2023_05 Type: proposal Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): priority: major (was trivial) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2692/inclusion-of-fuka…

1 0

#2692: Inclusion of FUKA importer thorns
by Roland Haas 16 Feb '23

16 Feb '23

#2692: Inclusion of FUKA importer thorns Reporter: tootle Status: new Milestone: ET_2023_05 Version: ET_2023_05 Type: proposal Priority: trivial Component: EinsteinToolkit thorn Changes (by Roland Haas): responsible: [] (was ) assignee: tootle (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2692/inclusion-of-fuka…

1 0

#2696: Update kuibit to 1.4.0
by Roland Haas 16 Feb '23

16 Feb '23

#2696: Update kuibit to 1.4.0 Reporter: Gabriele Bozzola Status: new Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Changes (by Roland Haas): responsible: [] (was ) assignee: Gabriele Bozzola (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2696/update-kuibit-to-…

1 0

#2689: Include NRPyLeakage in next ET release
by Roland Haas 16 Feb '23

16 Feb '23

#2689: Include NRPyLeakage in next ET release Reporter: Leonardo Werneck Status: new Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): Terrence Pierre Jacques will review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2689/include-nrpyleaka…

1 0

#2692: Inclusion of FUKA importer thorns
by Roland Haas 16 Feb '23

16 Feb '23

#2692: Inclusion of FUKA importer thorns Reporter: tootle Status: new Milestone: ET_2023_05 Version: ET_2023_05 Type: proposal Priority: trivial Component: EinsteinToolkit thorn Comment (by Roland Haas): Konrad Topolski will review -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2692/inclusion-of-fuka…

1 0

#2619: include Ellipitca (reader) in Einstein Toolkit
by Roland Haas 16 Feb '23

16 Feb '23

#2619: include Ellipitca (reader) in Einstein Toolkit Reporter: Roland Haas Status: open Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): @{5e8f32efacb63e0b834ed007} will review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2619/include-ellipitca…

1 0

#2696: Update kuibit to 1.4.0
by Gabriele Bozzola 15 Feb '23

15 Feb '23

#2696: Update kuibit to 1.4.0 Reporter: Gabriele Bozzola Status: new Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Comment (by Gabriele Bozzola): > Let me add this as a discussion item, though really $my personal opinion$ the _authors_ should spend time on coming up with solutions. Part of having things > included in the ET means that they must make some effort in keeping things working with the ET. If they want to do whatever they want then having it in a toolkit used by many and with a statement of supported clusters then they should not include it. "it works for me" is not good enough anymore, it has to work for others. Only two in the set \{kuibit supports Python 3.6, kuibit supports Python 3.11, the dependency tree of kuibit is vetted and verified consistent and compatible\}, so I decided to raise the minimum version required because depends heavily on the NumPy ecosystem, which has a tight support schedule and sometimes introduces breaking changes that ripple through all the downstream packages $for example, in 1.20, NumPy deprecated the names `np.int`, `np.float` and so on$. I presented the community with the statement that the next version of kuibit will depend on Python>=3.8, and the problem I raised is “what do we want to do in this situation?” Among the options are: * We require Python 3.8 and build it when it is not available * We require Python 3.8 and claim the clusters that don’t have it “not supported” * We maintain both kuibit 1.3.X and 1.4.X * We require as minimum ET dependency Python 3.7 and reject this kuibit update. Note that the latest Fedora $one of the supported machines$ defaults to Python 3.11, so kuibit 1.3.6 cannot be installed there. That’s why I feel this is more of a policy issue than a technological one $that I could solve myself$. ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2696/update-kuibit-to-…

1 0

#2696: Update kuibit to 1.4.0
by Roland Haas 15 Feb '23

15 Feb '23

#2696: Update kuibit to 1.4.0 Reporter: Gabriele Bozzola Status: new Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): Having been poked to comment. Here’s my comment: Oh right, it still says "new version of kuibit". In the call Gabriele suggested to use the old version either in the ET in general $not so great$ or add a warning for the affected machines $somewhat better$. If I recall correctly then what will happen is that if one does say: ``` pip install kuibit==1.4.0 ``` on a system without Python 3.8 loaded $not present, loaded$ then pip will report that not suitable kuibit is found. Eg on Stampede2 right now: ``` $ module load python3 Lmod is automatically replacing "python2/2.7.15" with "python3/3.7.0". $ pip install kuibit==1.4.0 Collecting kuibit==1.4.0 Could not find a version that satisfies the requirement kuibit==1.4.0 (from versions: 1.0.0b0, 1.0.0, 1.1.0, 1.1.1, 1.2.0b0, 1.2.0, 1.2.1, 1.3.0, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6) No matching distribution found for kuibit==1.4.0 ``` while leaving out the version number will pick the newest available version. A workaround for the same command to work on all clusters is actually to use: ``` $ pip install --upgrade 'kuibit<=1.4.0' ``` which will pick the newest version possible $and update if possible$. This is better than ``` $ pip install --upgrade 'kuibit' ``` since it avoids going to a newer version that may be released on PyPi after the a ET release. Let me add this as a discussion item, though really $my personal opinion$ the _authors_ should spend time on coming up with solutions. Part of having things included in the ET means that they must make some effort in keeping things working with the ET. If they want to do whatever they want then having it in a toolkit used by many and with a statement of supported clusters then they should not include it. "it works for me" is not good enough anymore, it has to work for others. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2696/update-kuibit-to-…

1 0

#2698: Misner_2.2_80_3D.par in EHFinder/par cannot be run
by Roland Haas 10 Feb '23

10 Feb '23

#2698: Misner_2.2_80_3D.par in EHFinder/par cannot be run Reporter: Gabriele Bozzola Status: open Milestone: Version: Type: bug Priority: trivial Component: EinsteinToolkit thorn Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2698/misner_22_80_3dpa…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac February 2023