#2720: Structure of if statements causes test failures on some machines.
Reporter: Peter Diener
Status: new
Milestone: ET_2023_05
Version: development version
Type: bug
Priority: major
Component: EinsteinToolkit thorn
The test for whether multipatch is used breaks on some machines do to speculative execution of all logical sub expressions causes MultiPatch\_MapIsCartesian to be called even when it is not activated.
Pull request is here: [https://bitbucket.org/einsteintoolkit/einsteinevolve/pull-requests/21](http…
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2720/structure-of-if-s…
#2710: Elliptica_ID_reader library not found at runtime on macOS
Reporter: Roland Haas
Status: new
Milestone: ET_2023_11
Version:
Type: bug
Priority: major
Component:
Changes (by Samuel Cupp):
milestone: ET_2023_11 (was ET_2023_05)
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2710/elliptica_id_read…
#2619: include Ellipitca (reader) in Einstein Toolkit
Reporter: Roland Haas
Status: open
Milestone: ET_2023_11
Version:
Type: enhancement
Priority: major
Component:
Changes (by Roland Haas):
milestone: ET_2023_11 (was ET_2023_05)
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2619/include-ellipitca…
#2619: include Ellipitca (reader) in Einstein Toolkit
Reporter: Roland Haas
Status: open
Milestone: ET_2023_05
Version:
Type: enhancement
Priority: major
Component:
Comment (by Leonardo Werneck):
We recommend that the following tasks be completed for inclusion in a future release:
1. Compare Einstein Toolkit simulation results that use LORENE and Elliptica initial data, as comparing results against those from a different infrastructure can be tricky and the results hard to interpret. There are at least two tests that could/should be done:
1\.a Read in both initial data onto the Carpet grid and show that the Hamiltonian and momentum constraints are initially comparable;
1\.b Perform two simulations in the Einstein Toolkit that differ only in the way the initial data is read, and show that e.g., the NS trajectories and the gravitational waves extracted from both simulations overlap. You can use the gallery example parameter file as a guide.
2. Create a reasonably large \(>10\) initial data catalog and make it publicly available. The catalog should include, for example, initial data with different equations of state, initial separations, masses, and/or mass ratios. Without such a catalog, people would not be able to use the Elliptica reader.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2619/include-ellipitca…
#2619: include Ellipitca (reader) in Einstein Toolkit
Reporter: Roland Haas
Status: open
Milestone: ET_2023_05
Version:
Type: enhancement
Priority: major
Component:
Comment (by Leonardo Werneck):
The Elliptica reader will not be in the ET\_2023\_05 Einstein Toolkit release.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2619/include-ellipitca…
#1188: GetComponents should output the total number of components to be downloaded
Reporter: Ian Hinder
Status: wontfix
Milestone:
Version:
Type: enhancement
Priority: minor
Component: GetComponents
Changes (by Roland Haas):
status: wontfix (was new)
If GetComponents outputs the total number of components it is about to download, then Mohave will be able to give a better progress report. This would also be helpful for users as they can see how far through the process they are.
**Keyword:**
Comment (by Roland Haas):
Eclipse (and its Cactus integration) seems no longer in use for the ET. Progress updates with parallel checkouts are tricky, GetComponent does not always know which components it will update vs. download freshly.
This seems lots of work for little gain just to get at Windows like progress bar that gets stuck on the last % value.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1188/getcomponents-sho…
#2719: GetCompnents does not handle symbolic links correctly when checking repository inter-dependencies
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: bug
Priority: minor
Component: GetComponents
GIven two stanzas:
```
# FUKA initial data thorns
# the crazy path works around a bug in GetComponents that does not handly
# symbolic links and ".." correctly
!TARGET = $ARR/Fuka/KadathThorn/src/fuka
!TYPE = git
!URL = https://bitbucket.org/fukaws/fuka
!CHECKOUT = Cmake build_debug build_release codes eos include install_par.sh install_seq.sh src src_par src_seq
!TARGET = $ARR
!TYPE = git
!URL = https://bitbucket.org/fukaws/$2
!REPO_PATH=../$2
!CHECKOUT = Fuka/KadathImporter Fuka/KadathThorn
#DISABLED Fuka/KadathImporter
#DISABLED Fuka/KadathThorn
```
GetComponents detects that the `Cmake`, `build_debug` etc files checked out of `fuka` depend on `KadathThorn` having been checked out by running `$TARGET/$CHECKOUT` for both through `canonpath` then doing a _string_ comparison to check if the path obtained for `fuka` starts with that of `KadathThorn`.
However when creating symbolic links it uses `abs2rel` which walks the directory tree and produces possibly incorrect symbolic links. Namely I get:
```
$ ls repos/KadathThorn/src/fuka/ -l total 44
lrwxrwxrwx 1 rhaas rhaas 31 Apr 25 13:28 Cmake -> ../../../../../repos/fuka/Cmake
lrwxrwxrwx 1 rhaas rhaas 37 Apr 25 13:28 build_debug -> ../../../../../repos/fuka/build_debug
lrwxrwxrwx 1 rhaas rhaas 39 Apr 25 13:28 build_release -> ../../../../../repos/fuka/build_release
lrwxrwxrwx 1 rhaas rhaas 31 Apr 25 13:28 codes -> ../../../../../repos/fuka/codes
lrwxrwxrwx 1 rhaas rhaas 29 Apr 25 13:28 eos -> ../../../../../repos/fuka/eos
lrwxrwxrwx 1 rhaas rhaas 33 Apr 25 13:28 include -> ../../../../../repos/fuka/include
lrwxrwxrwx 1 rhaas rhaas 40 Apr 25 13:28 install_par.sh -> ../../../../../repos/fuka/install_par.sh
lrwxrwxrwx 1 rhaas rhaas 40 Apr 25 13:28 install_seq.sh -> ../../../../../repos/fuka/install_seq.sh
lrwxrwxrwx 1 rhaas rhaas 29 Apr 25 13:28 src -> ../../../../../repos/fuka/src
lrwxrwxrwx 1 rhaas rhaas 33 Apr 25 13:28 src_par -> ../../../../../repos/fuka/src_par
lrwxrwxrwx 1 rhaas rhaas 33 Apr 25 13:28 src_seq -> ../../../../../repos/fuka/src_seq
```
which have an extra `../`
Instead one must use:
```
# FUKA initial data thorns
# the crazy path works around a bug in GetComponents that does not handly
# symbolic links and ".." correctly
!TARGET = $ARR/Fuka/KadathThorn/src/fuka/../../../../../repos/KadathThorn/src/fuka
!TYPE = git
!URL = https://bitbucket.org/fukaws/fuka
!CHECKOUT = Cmake build_debug build_release codes eos include install_par.sh install_seq.sh src src_par src_seq
```
for the first stanza to make sure it does not end up in a symbolic link. Which produces the correct:
```
$ ls repos/KadathThorn/src/fuka/ -l
total 44
lrwxrwxrwx 1 rhaas rhaas 28 Apr 25 13:29 Cmake -> ../../../../repos/fuka/Cmake
lrwxrwxrwx 1 rhaas rhaas 34 Apr 25 13:29 build_debug -> ../../../../repos/fuka/build_debug
lrwxrwxrwx 1 rhaas rhaas 36 Apr 25 13:29 build_release -> ../../../../repos/fuka/build_release
lrwxrwxrwx 1 rhaas rhaas 28 Apr 25 13:29 codes -> ../../../../repos/fuka/codes
lrwxrwxrwx 1 rhaas rhaas 26 Apr 25 13:29 eos -> ../../../../repos/fuka/eos
lrwxrwxrwx 1 rhaas rhaas 30 Apr 25 13:29 include -> ../../../../repos/fuka/include
lrwxrwxrwx 1 rhaas rhaas 37 Apr 25 13:29 install_par.sh -> ../../../../repos/fuka/install_par.sh
lrwxrwxrwx 1 rhaas rhaas 37 Apr 25 13:29 install_seq.sh -> ../../../../repos/fuka/install_seq.sh
lrwxrwxrwx 1 rhaas rhaas 26 Apr 25 13:29 src -> ../../../../repos/fuka/src
lrwxrwxrwx 1 rhaas rhaas 30 Apr 25 13:29 src_par -> ../../../../repos/fuka/src_par
lrwxrwxrwx 1 rhaas rhaas 30 Apr 25 13:29 src_seq -> ../../../../repos/fuka/src_seq
```
The “obvious” solution would be to use `realpath` instead of `canonpath` however that requires that the path actually exists which is not yet the case when dependencies are checked for.
This was triggered by Fuka in #2711
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2719/getcompnents-does…
#206: Add --xml option to GetComponents
Reporter: Eric Seidel
Status: wontfix
Milestone:
Version:
Type: enhancement
Priority: minor
Component: GetComponents
Changes (by Roland Haas):
status: wontfix (was open)
GetComponents should support machine readable output using XML.
**Keyword:**
Comment (by Roland Haas):
This has not been needed in 13 years. We are unlikely to ever need it.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/206/add-xml-option-to-…