Trac

trac@lists.einsteintoolkit.org

8708 discussions

#1425: git repositories checkout into main tree
by Roland Haas 25 Apr '23

25 Apr '23

#1425: git repositories checkout into main tree Reporter: Frank Löffler Status: duplicate Milestone: Version: development version Type: enhancement Priority: minor Component: GetComponents Changes (by Roland Haas): status: duplicate (was new) Comment (by Roland Haas): Duplicate of #1047. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1425/git-repositories-…

1 0

#1130: Cactus tutorial on cactus website
by Roland Haas 25 Apr '23

25 Apr '23

#1130: Cactus tutorial on cactus website Reporter: Jian Tao Status: resolved Milestone: Version: Type: bug Priority: minor Component: Other Changes (by Roland Haas): status: resolved (was new) Following the instructions on the Cactus website will not lead to a successful run due to the introduction to ash. This frustrates new Cactus users. I would suggest to add !BRANCH = Cactus_4.0.0 to the thorn list to make it work at least. **Keyword:** Comment (by Roland Haas): Fixed by more explicit instructions in the tutorial jupyter notebook. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1130/cactus-tutorial-o…

1 0

#2580: GetComponents assumes that default branch name is "master"
by Roland Haas 25 Apr '23

25 Apr '23

#2580: GetComponents assumes that default branch name is "master" Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: minor Component: GetComponents Comment (by Roland Haas): hmm, this would seem to likely cause failures also when we have the release branches set and this be $much$ more severe than “minor”. Needs testing. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2580/getcomponents-ass…

1 0

#2711: attempting to build KadathThorn assumes a git repository
by Roland Haas 25 Apr '23

25 Apr '23

#2711: attempting to build KadathThorn assumes a git repository Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Ok, there is definitely $at least$ one bug in GetComponent’s. Basically it does not handle symbolic links in paths correctly. I do not want to touch GetComponents this close to the release, so here’s a workaround using a crazy path: ``` # FUKA initial data thorns # the crazy path works round 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 ``` ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2711/attempting-to-bui…

1 0

#2711: attempting to build KadathThorn assumes a git repository
by Roland Haas 25 Apr '23

25 Apr '23

#2711: attempting to build KadathThorn assumes a git repository Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Alright, something is wrong. I will need to see what it actually uses to check dependency. Likely the CHECKOUT and not the TARGET/NAME data. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2711/attempting-to-bui…

1 0

#2619: include Ellipitca (reader) in Einstein Toolkit
by Alireza R. 25 Apr '23

25 Apr '23

#2619: include Ellipitca (reader) in Einstein Toolkit Reporter: Roland Haas Status: open Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Comment (by Alireza R.): Additionally, the resolutions and grid structures of these testing runs between ETK and BAM are different, so we expect some variation at a later time. We plan to perform some gauge-independent tests after completing an entire evolution. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2619/include-ellipitca…

1 0

#2619: include Ellipitca (reader) in Einstein Toolkit
by Pedro Espino 25 Apr '23

25 Apr '23

#2619: include Ellipitca (reader) in Einstein Toolkit Reporter: Roland Haas Status: open Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Comment (by Pedro Espino): I can confirm that both objects begin at the correct locations $i.e., the same as BAM$ on the grid. Below is a view of the trajectories on the equatorial plane for each evolution code $ET is EinsteinToolkit and BA is BAM$. We’ve tried this test with both the `VolumeIntegrals_GRMHD` and `NSTracker` thorns for tracking the NS, and they result in similar results. I suspect the differences in trajectories are due to different gauge conditions. It is difficult to get a 1-to-1 overlap in the gauge conditions between BAM and `ML_BSSN`. ![](https://bitbucket.org/repo/8zBLME5/images/3802443862-image.png) ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2619/include-ellipitca…

1 0

#2711: attempting to build KadathThorn assumes a git repository
by Roland Haas 24 Apr '23

24 Apr '23

#2711: attempting to build KadathThorn assumes a git repository Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): `GetComponents` has code to avoid race conditions. If that does not trigger then there is something wrong. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2711/attempting-to-bui…

1 0

#2711: attempting to build KadathThorn assumes a git repository
by tootle 24 Apr '23

24 Apr '23

#2711: attempting to build KadathThorn assumes a git repository Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by tootle): @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} I’m still working on a solution to this. The issue with the proposed $though not advised$ solution of having a separate checkout to populate the src/fuka directory results in a race condition on the filesystem since a working tree becomes locked when being used by `GetComponents` even without `--parallel`. I also verified, at least on my system, that the submodules of Kranc are not automatically updated via `GetComponents` so possibly this is just a remnant on your system. Is it the case that sim-sync only downloads the repos from the internet and pushes them to a remote system and only on the remote system are the build scripts executed? Within the confines of the use case, I don’t see much of an alternative than to switch to a tarball. I’ll think on it more though. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2711/attempting-to-bui…

1 0

#2712: KadathThorn build script contains GNUisms
by tootle 24 Apr '23

24 Apr '23

#2712: KadathThorn build script contains GNUisms Reporter: Roland Haas Status: new Milestone: ET_2023_05 Version: Type: bug Priority: major Component: Comment (by tootle): @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} It took me a bit, but I think I have all of these issues resolved. The GNUisms was trivial, but updating to allow for different folder names was less so with the main issue being that \`detect.sh\` does not have knowledge of `THORN` even aftering adding it to `make.config.deps`. To alleviate this issues, I have resorted to using a static thorn name `KadathThorn` within the `*.sh` files and `make.config.deps` since i don’t see any reason for conflicts to be of issues unless one tries to build using two different versions of the same thorn $e.g. `KadathThorn` and `KadathThorn-rhaas`$. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2712/kadaththorn-build…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac