Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2485: include complex and real scalar evolution code from Canuda in ET
by Roland Haas 21 Dec '22

21 Dec '22

#2485: include complex and real scalar evolution code from Canuda in ET Reporter: Roland Haas Status: open Milestone: Version: Type: task Priority: major Component: Comment (by Roland Haas): Yes, those are enough. Not sure why I thought they were missing \(given that they have commit dates 4 months ago\). So only a closer look at documentation would be needed. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2485/include-complex-a…

1 0

#2485: include complex and real scalar evolution code from Canuda in ET
by Miguel Zilhão 21 Dec '22

21 Dec '22

#2485: include complex and real scalar evolution code from Canuda in ET Reporter: Roland Haas Status: open Milestone: Version: Type: task Priority: major Component: Comment (by Miguel Zilhão): Sure, I’ll update the docs right after the Christmas break. Concerning the test cases, these have been added already. @Giuseppe\_Ficarra added them here: [https://bitbucket.org/canuda/scalar/src/master/ScalarEvolve/test/](https://… Are these not enough? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2485/include-complex-a…

1 0

#2615: Riemann release not compiling with intel 2021.6.0
by Roland Haas 20 Dec '22

20 Dec '22

#2615: Riemann release not compiling with intel 2021.6.0 Reporter: Wolfgang Kastaun Status: closed Milestone: Version: ET_2022_05 Type: bug Priority: minor Component: Changes (by Roland Haas): status: closed (was new) Comment (by Roland Haas): Closing due to lack of activity. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2615/riemann-release-n…

1 0

#2485: include complex and real scalar evolution code from Canuda in ET
by Roland Haas 20 Dec '22

20 Dec '22

#2485: include complex and real scalar evolution code from Canuda in ET Reporter: Roland Haas Status: open Milestone: Version: Type: task Priority: major Component: Comment (by Roland Haas): @{557058:65c5f18c-c3ad-4126-bb2b-be0e766b31ef} before the next release \(but as soon as possible\) if you could take a stab a updating the basic docs that I had cobbled together as well as \(and that is actually quite important\) add a test case for the arrangement \(one is enough, pick any thorn to contain it as long as it tests all 3 thorns\), that would be great. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2485/include-complex-a…

1 0

#2662: Try to get email from ~/.gitconfig
by Roland Haas 20 Dec '22

20 Dec '22

#2662: Try to get email from ~/.gitconfig Reporter: Steven R. Brandt Status: new Milestone: Version: Type: enhancement Priority: trivial Component: SimFactory Comment (by Roland Haas): Applied as git hash [f0aaf8c0](https://bitbucket.org/simfactory/simfactory2/commits/f0aaf8c0a515… "simdt: obtain the user's email from git if possible" of [simfactory2](https://bitbucket.org/simfactory/simfactory2) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2662/try-to-get-email-…

1 0

#2662: Try to get email from ~/.gitconfig
by Roland Haas 20 Dec '22

20 Dec '22

1 0

#2677: add -Wl, --rpath, FOO sets RUNPATH rather than RPATH for new linkers
by Roland Haas 16 Dec '22

16 Dec '22

#2677: add -Wl,--rpath,FOO sets RUNPATH rather than RPATH for new linkers Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: minor Component: Cactus The elf RPATH variable has been declared obsolete and instead RUNPATH introduced. The latter only affects the search path of the actual executable and not that of any libraries it loads. While maybe a good idea from the point of view of not having the top level executable changing search path for its libraries, this does not work on all clusters. On frontera the module provided libraries do not set RUNPATH at all and instead rely on a `module load` and `LD_LIBRARY_PATH` to set up correct search paths. Which can be annoying if one wants to avoid simfactory to run simulations \(which would load the modules\). One can pass an options `-Wl,--disable-new-dtags` to make a _new_ linker use the _old_ meaning of `-Wl,--rpath`. This may be something to consider for Cactus' configuration scripts. See [https://stackoverflow.com/questions/70149080/ldd-shows-so-not-found-but-run… for references on this [https://stackoverflow.com/questions/52018092/how-to-set-rpath-and-runpath-w… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2677/add-wl-rpath-foo-…

1 0

#2676: Consolidate/improve support options
by Gabriele Bozzola 13 Dec '22

13 Dec '22

#2676: Consolidate/improve support options Reporter: Gabriele Bozzola Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit website The support page on the website has: * Search bar. This is supposed to search on the website/mailing lists/tickets. I tried searching for “libfabric”, which was in the subject on an email sent last month to users, but no result popped out, so maybe something is not working as expected. Personally, I remember that I had tried using the search bar in the past but found that it was unhelpful \(I cannot really put my finger on why exactly\). * User mailing list. The description invites people to ask questions. * Commits mailing list. Should this really in the “support” page? * Cactus mailing list. The link is broken. * Bug tracker. * IRC. Half the links in this section are broken and it is not possible to look at the logs. Is anyone actually using this \(except Roland\)? * Gitter. The description says that “we are currently exploring” this option. The chat room received only a handful of messages over the past year and doesn’t look particularly active. * Weekly calls. I feel that there are too many open support channels, resulting in \(1\) information being dispersed/made harder to find, \(2\) difficulty for users to ask questions and receive an answer \(I think that this is barrier for users that are unfamiliar with our community and those that are just getting started\). I think that there is benefit in consolidating the support channels, as currently the places where one could ask a question are 6 \(ET user mailing list, Cactus mailing list, Bug tracker, IRC, Gitter, weekly call\). In this, I feel that a platform like gitter has a lot of potential and chatting in real-time can be a very effective way to quickly get questions answered. However, users might think that the forum is dead when they see that the last message was sent 6 months ago, if we prune ineffective support channels, we can also consider emphasizing gitter more. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2676/consolidate-impro…

1 0

#2675: Several broken links on the website
by Roland Haas 13 Dec '22

13 Dec '22

#2675: Several broken links on the website Reporter: Gabriele Bozzola Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit website Comment (by Roland Haas): Thank you for reporting these. I had not quite realized there were that many. A link checker would have to be part of a Bitbucket pipeline or GitHub action. Right now there is no pipeline that produces the website, it is plain, unprocessed HTML site. For the [www.cactuscode.org](http://www.cactuscode.org) website \(which does use github actions\) I run w3c’s linkchecker [https://packages.debian.org/bookworm/w3c-linkchecker](https://packages.debi… and I guess a similar thing could be tied to a pipeline triggered whenever the web-server pulls a fresh copy from the repo. The missing png ones are most likely a failure in the HTML thorndoc documentation scripts. Those seem somewhat error prone and dependent on OS version unfortunately. The many links to dead clusters should be updated, yes. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2675/several-broken-li…

1 0

#2675: Several broken links on the website
by Gabriele Bozzola 13 Dec '22

13 Dec '22

#2675: Several broken links on the website Reporter: Gabriele Bozzola Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit website I was browsing the website, and I found three broken links in the support page \(in the IRC section\). So, I ran a full analysis with [https://www.deadlinkchecker.com/website-dead-link-checker.asp](https://www.… and found quite a few broken links. I am attaching an html page with the full list \(excluded the ones that returned 403, e.g., arXiv, which doesn’t want to be visited by robots\). Maybe a dead link checker could be added to the website pipeline? attachment: broken_no403.html (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2675/several-broken-li…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac