#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…
#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-…
#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-…
#2698: Misner_2.2_80_3D.par in EHFinder/par cannot be run
Reporter: Gabriele Bozzola
Status: new
Milestone:
Version:
Type: bug
Priority: trivial
Component: EinsteinToolkit thorn
Changes (by Roland Haas):
responsible: [] (was )
assignee: Peter Diener (was )
Comment (by Roland Haas):
@{557058:f7fd5133-6eee-4385-a5e5-3e03342a0b24} for once I can assign a ticket to a specific author and maintainer as by the README file :-\)
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2698/misner_22_80_3dpa…
#2698: Misner_2.2_80_3D.par in EHFinder/par cannot be run
Reporter: Gabriele Bozzola
Status: new
Milestone:
Version:
Type: bug
Priority: trivial
Component: EinsteinToolkit thorn
I realize this is an extremely trivial and insignificant issue, but I’ll open it for the sake of tidying things up a tiny tiny bit.
The parameter file included in the `einsteinanalysis/EHFinder` thorn cannot be run with the thorns included in the `Einstein Toolkit`. It also contains a series of hard-coded paths. The file has not been touched for more than 20 years and I wonder if it provides any value \(except historical\).
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2698/misner_22_80_3dpa…
#1842: clang-format options not valid for versions <=3.5
Reporter: Frank Löffler
Status: wontfix
Milestone:
Version: development version
Type: bug
Priority: minor
Component: Cactus
Changes (by Roland Haas):
status: wontfix (was new)
The current .clang-format file is not valid for clang-format versions 3.5 and below. The attached patch would 'fix' this by removing key words not known in version 3.5, but still wouldn't work for versions below that. I do not suggest to apply the patch - it should just show that this is quite some number.
Looking at the .clang-format file it seems that it does not use one of the pre-defined styles, but rather creates it's own (even if it is based on one given the comment in the file). I wonder if all of this is really necessary, or if we could not simply use one of the pre-defined styles, possibly with a few changes that work across clang-format versions.
**Keyword:**
Comment (by Roland Haas):
clang-format's output or options are not stable across versions. We currently (2023-02-03) require us of clang-format 9.0.1-16 for reproducible results.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1842/clang-format-opti…
#2691: New features to particle_tracerET
Reporter: Leonardo Werneck
Status: new
Milestone: ET_2023_05
Version:
Type: enhancement
Priority: major
Component:
Comment (by Leonardo Werneck):
@{557058:8bc23f2a-45c0-477d-8ac4-a5a16c734278} will be the reviewer.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2691/new-features-to-p…
#2693: Adding read/write support to Baikal and BaikalVacuum
Reporter: Samuel Cupp
Status: new
Milestone: ET_2023_05
Version:
Type: enhancement
Priority: minor
Component: EinsteinToolkit thorn
Comment (by Leonardo Werneck):
@{5bae587b96242d2e2b6110a4} will be the reviewer.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2693/adding-read-write…
#2690: Include new IllinoisGRMHD with tabulated and hybrid EOS support
Reporter: Leonardo Werneck
Status: new
Milestone: ET_2023_05
Version:
Type: enhancement
Priority: major
Component:
Comment (by Leonardo Werneck):
@{557058:088051f9-5b94-4b5e-bfbe-71137030b9c1} will be the reviewer.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2690/include-new-illin…
#2694: include CarpetX prerelease in Einstein Toolkit
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: enhancement
Priority: major
Component: EinsteinToolkit thorn
Comment (by Samuel Cupp):
After discussion, CarpetX will be included in the November 2023 release, but the code review will begin during the 2023\_05 release due to the complexity of a driver thorn and its importance as a core component for future work in the Toolkit.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2694/include-carpetx-p…
#2695: Inclusion of AsterX pre-release in the Einstein Toolkit
Reporter: Jay Kalinani
Status: new
Milestone:
Version:
Type: enhancement
Priority: minor
Component: EinsteinToolkit thorn
Comment (by Samuel Cupp):
After discussion, the AsterX developers decided to delay the addition of AsterX into the Toolkit until the November 2023 release to align with the planned CarpetX full release.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2695/inclusion-of-aste…