Trac April 2023

trac@lists.einsteintoolkit.org

1 participants
128 discussions

#2705: error: more than one instance of overloaded function "isnan" matches the argument list
by Roland Haas 06 Apr '23

06 Apr '23

#2705: error: more than one instance of overloaded function "isnan" matches the argument list Reporter: Miguel Zilhão Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): I am proposing an automated test $and thus better error message$ for this in [#2663](https://bitbucket.org/einsteintoolkit/tickets/issues/2663/add-an-notice-about-minimum-intel-gcc). Feel free to review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2705/error-more-than-o…

1 0

#2663: add an notice about minimum Intel / GCC version required to configure output
by Roland Haas 06 Apr '23

06 Apr '23

#2663: add an notice about minimum Intel / GCC version required to configure output Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2663/add-an-notice-abo…

1 0

#2663: add an notice about minimum Intel / GCC version required to configure output
by Roland Haas 06 Apr '23

06 Apr '23

#2663: add an notice about minimum Intel / GCC version required to configure output Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): Pull request to test for C\+\+11 math for isnan is here: [https://bitbucket.org/cactuscode/cactus/pull-requests/152](https://bitbucke… This is probably better than trying to rely on feature test macros since those may not really tell the truth due to bugs in c\+\+ libraries. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2663/add-an-notice-abo…

1 0

#2705: error: more than one instance of overloaded function "isnan" matches the argument list
by Roland Haas 06 Apr '23

06 Apr '23

#2705: error: more than one instance of overloaded function "isnan" matches the argument list Reporter: Miguel Zilhão Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): uh there may be a way around. Though it would require that we added extra `#ifdef` to the code and the point of this was more or less to not have those around anymore. Nope, no luck. I took a look at the ticket where this was initial discussed: [https://bitbucket.org/einsteintoolkit/tickets/issues/2407/cactus-math-work-… and keeping workarounds was considered optional and since we never ran into issues on “supported” clusters they were not implemented. I think you may stand a good chance asking the admins to install a newer gcc for you since gcc 4.X is really very old. In particular if you can point them to the Intel docs stating that g\+\+'s STL is needed for icpc $see eg [https://www.intel.com/content/www/us/en/developer/articles/release-notes/c-… for intel 2019 and its requirements$. If all else fails, you can also compile your own g\+\+ and use that. Usually following the instructions at [https://gcc.gnu.org/install/download.html](https://gcc.gnu.org/install/down… , [https://gcc.gnu.org/install/configure.html](https://gcc.gnu.org/install/con… , and [https://gcc.gnu.org/install/build.html](https://gcc.gnu.org/install/build.h… $very carefully! note the `build` directory and the `contrib/download_prerequisites` script$ works $it will take a while though$ and afterwards you can pass the `-gxx-name <path-to-g++>` option to `icpc` to make it use the new stdc\+\+ library. You can also experiment with using `spack` to install `gcc` $which is easier, but just as slow$. [https://spack-tutorial.readthedocs.io/en/latest/tutorial\_basics.html](http… ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2705/error-more-than-o…

1 0

#1713: Avoid build-time warning
by Roland Haas 06 Apr '23

06 Apr '23

#1713: Avoid build-time warning Reporter: Erik Schnetter Status: resolved Milestone: Version: development version Type: bug Priority: minor Component: EinsteinToolkit thorn Changes (by Roland Haas): status: resolved (was open) Comment (by Roland Haas): Thank you @{557058:56049c54-f8c2-4b6c-9b88-ab697c967495} -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1713/avoid-build-time-…

1 0

#1713: Avoid build-time warning
by Roland Haas 06 Apr '23

06 Apr '23

#1713: Avoid build-time warning Reporter: Erik Schnetter Status: open Milestone: Version: development version Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): Applied as git hash [a9b65e5](https://bitbucket.org/einsteintoolkit/einsteinevolve/commits/a9b65… "GRHydro\_InitData: check for curvilinear grid at runtime" of [einsteinevolve](https://bitbucket.org/einsteintoolkit/einsteinevolve) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1713/avoid-build-time-…

1 0

#2700: SummationByParts does not ensure unique gobal function names
by Roland Haas 06 Apr '23

06 Apr '23

#2700: SummationByParts does not ensure unique gobal function names Reporter: Roland Haas Status: resolved Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: resolved (was open) Comment (by Roland Haas): Thank you @{557058:f7fd5133-6eee-4385-a5e5-3e03342a0b24} -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2700/summationbyparts-…

1 0

#2707: tests for lean_public are very slow
by Roland Haas 06 Apr '23

06 Apr '23

#2707: tests for lean_public are very slow Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: major Component: Right now, out of the 10 [slowest tests](https://einsteintoolkit.github.io/tests/), 5 are lean\_public and 1 is `twopunctures_kerrproca_c11` . With 339 tests in the ET one tries to encourage each test to run as quickly as possible $[https://docs.einsteintoolkit.org/et-docs/Adding\_a\_test\_case](https://docs.einsteintoolkit.org/et-docs/Adding_a_test_case)$. With about 6 minutes runtime and about 25minutes total test runtime $[https://einsteintoolkit.github.io/tests/plot.html](https://einsteintoolkit.github.io/tests/plot.html) in the time taken tab$ this accounts for almost 1/4 of the test runtime $not including build time$. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2707/tests-for-lean_pu…

1 0

#2619: include Ellipitca (reader) in Einstein Toolkit
by Roland Haas 06 Apr '23

06 Apr '23

#2619: include Ellipitca (reader) in Einstein Toolkit Reporter: Roland Haas Status: open Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): Looking at thornlist fragment included in in manifest: ``` # Elliptic ID reader !TARGET = $ARR !TYPE = git !URL = https://github.com/aup1075/EllipticaID.git !REPO_BRANCH = BHNS_reader !REPO_PATH = $2 !CHECKOUT = EllipticaID/Elliptica_BHNS # required lib for Elliptica BHNS ID reader !TARGET = $ARR !TYPE = git !URL = https://github.com/rashti-alireza/Elliptica_ID_Reader.git !REPO_BRANCH = Cactus !REPO_PATH = ../$2 !CHECKOUT = ExternalLibraries/Elliptica_ID_Reader ``` then both use a non-default branch $not just not named “master” but actually not the default branch$. This is ok as long as those branches are $in the “master” branch manifest$ are the ones that will continue to be the ones that releases will be spun off from and are the ones that are actually used by the authors. That is they should not be branches created _solely_ for this ticket. `https://github.com/rashti-alireza/Elliptica_ID_Reader.git` seems to be ok in that respect since it is the branch containing the Cactus ExternalLibrary like thorn and includes a tar file of the source $though it could have also been included in a subdirectory of the main branch \[and include its own tar-file there\] in the way RePrimAnd does$. However [https://github.com/aup1075/EllipticaID/tree/BHNS\_reader](https://github.co… has what looks like the same `Elliptica_BHNS` thorn also available in `main`. If the copy of the thorn is `BHNS_reader` is just a copy of the one in `main` then it would be preferable to track `main` where presumably the actual updates will happen. In particular in anticipation of a future inclusion of other types of readers. There is no harm in having extra thorns $or other code$ in the repo and branch that is used with Cactus. The extra ones are just ignored as long as they are not actually listed in the thornlist $and are not subject to review$. The added simplicity of not having to maintain multiple branches that need to be kept up to date with bugfixes and $possibly$ improvements may well be worth the larger size on disk when checking out the repo. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2619/include-ellipitca…

1 0

#2619: include Ellipitca (reader) in Einstein Toolkit
by Roland Haas 06 Apr '23

06 Apr '23

#2619: include Ellipitca (reader) in Einstein Toolkit Reporter: Roland Haas Status: open Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): When this was discussed in the ET calls then the argument for inclusion was that there would be a library of initial data files available. Right now I cannot find those anywhere. Are they available? An alternative would be to have the elliptica initial data solver $not just the reader$ available, though right now it is unclear where it is located or if it is available. Having either one available was a condition for inclusion in the ET $open source astro code$: [http://lists.einsteintoolkit.org/pipermail/users/2022-July/008615.html](htt… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2619/include-ellipitca…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac April 2023