Trac December 2022

trac@lists.einsteintoolkit.org

1 participants
54 discussions

#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

#1066: Implement IMEX integrators in MoL
by Roland Haas 12 Dec '22

12 Dec '22

#1066: Implement IMEX integrators in MoL Reporter: Erik Schnetter Status: open Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): Though @{557058:56049c54-f8c2-4b6c-9b88-ab697c967495} just pointed out a flaw in my thinking. So I no longer have a direct application for this. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1066/implement-imex-in…

1 0

#1066: Implement IMEX integrators in MoL
by Roland Haas 12 Dec '22

12 Dec '22

#1066: Implement IMEX integrators in MoL Reporter: Erik Schnetter Status: open Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit thorn Changes (by Roland Haas): responsible: [] (was ) assignee: Roland Haas (was ) Dana Alic contributed an implementation of IMEX integrators for MoL. I attach the implementation as a patch (based on r133 of MoL). The implementation is well tested. The patch does not apply cleanly, and seems to make some modifications to the schedule etc. as well that have since been superseded by other changes to MoL. **Keyword:** Comment (by Roland Haas): have some renewed interest in this -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1066/implement-imex-in…

1 0

#2626: Multipole is not OpenMP parallelized
by Gabriele Bozzola 05 Dec '22

05 Dec '22

#2626: Multipole is not OpenMP parallelized Reporter: Gabriele Bozzola Status: new Milestone: Version: Type: enhancement Priority: trivial Component: Comment (by Gabriele Bozzola): If I did reach a final conclusion, I forgot about it. I see I have a commit about it: [https://bitbucket.org/Sbozzolo/einsteinanalysis/commits/69b64606b6a1ac35405… I think I claim that this is \(marginally\) faster in production runs. ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2626/multipole-is-not-…

1 0

#2674: Einstein Toolkit != Cactus
by Zach Etienne 05 Dec '22

05 Dec '22

#2674: Einstein Toolkit != Cactus Reporter: Zach Etienne Status: new Milestone: Version: Type: bug Priority: minor Component: Comment (by Zach Etienne): There are a number of modules that don’t depend on Cactus in the Cactus directory, including NRPyPN, and ExternalLibraries. Maybe a directory structure should be created under `EinsteinToolkit/` , including Cactus, SelfForce, NRPyPN etc? Also wouldn’t it be best if the download directions for the Einstein Toolkit downloaded the entire Toolkit, instead of separate instructions for other modules under the ET umbrella? Yeah sorry I was confused of the definition of “blocker”, thanks for clarifying. Still I believe this should be fixed. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2674/einstein-toolkit-…

1 0

#2674: Einstein Toolkit != Cactus
by Roland Haas 05 Dec '22

05 Dec '22

#2674: Einstein Toolkit != Cactus Reporter: Zach Etienne Status: new Milestone: Version: Type: bug Priority: minor Component: Comment (by Roland Haas): Note that what is in the “Cactus” directory _is_ actually Cactus. For the non-cactus based codes \(SelfForce1D and kuibit\) we \(have to, since they do not work well with GetComponents\) provide separate download instructions. So certainly what GetComponents downloads is not all of the Einstein Toolkit. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2674/einstein-toolkit-…

1 0

#2674: Einstein Toolkit != Cactus
by Roland Haas 05 Dec '22

05 Dec '22

#2674: Einstein Toolkit != Cactus Reporter: Zach Etienne Status: new Milestone: Version: Type: bug Priority: minor Component: Changes (by Roland Haas): responsible: [] (was ) assignee: Zach Etienne (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2674/einstein-toolkit-…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac December 2022