Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2532: try and auto-detect "system" directories to strip from THORN_INC_DIRS and THORN_LIB_DIRS
by Roland Haas 20 May '21

20 May '21

#2532: try and auto-detect "system" directories to strip from THORN_INC_DIRS and THORN_LIB_DIRS Reporter: Roland Haas Status: new Milestone: Version: development version Type: enhancement Priority: minor Component: Cactus Currently we use two utilities `strip-inc-dirs.sh` and `strip-lib-dirs.sh` to remove “system” libraries from `THORN_INC_DIRS` and `THORN_LIB_DIRS` in ExternalLibraries. However the list used is hard-coded and not always correct $see eg #2528$. It may be better to: 1. make the list of directories to strip option list variables 2. try to auto-detect them in the Cactus know-architectures files To auto-detect on GNU/Linux with gcc/ld one can try and use the suggestion on [https://stackoverflow.com/questions/9922949/how-to-print-the-ldlinker-searc… and [https://stackoverflow.com/questions/17939930/finding-out-what-the-gcc-inclu… namely ``` gcc -print-search-dirs ``` and ``` echo | gcc -E -Wp,-v - ``` ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2532/try-and-auto-dete…

1 0

#2527: Perl undefined variables warnings when tyring to inherit from a non existing thorn
by Roland Haas 20 May '21

20 May '21

#2527: Perl undefined variables warnings when tyring to inherit from a non existing thorn Reporter: Roland Haas Status: open Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2527/perl-undefined-va…

1 0

#2527: Perl undefined variables warnings when tyring to inherit from a non existing thorn
by Roland Haas 20 May '21

20 May '21

#2527: Perl undefined variables warnings when tyring to inherit from a non existing thorn Reporter: Roland Haas Status: open Milestone: Version: development version Type: bug Priority: minor Component: Cactus Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2527/perl-undefined-va…

1 0

#2527: Perl undefined variables warnings when tyring to inherit from a non existing thorn
by Roland Haas 20 May '21

20 May '21

#2527: Perl undefined variables warnings when tyring to inherit from a non existing thorn Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): Pull request is here: [https://bitbucket.org/cactuscode/cactus/pull-requests/123](https://bitbucke… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2527/perl-undefined-va…

1 0

#2531: remove non piraha parser from Flesh
by Roland Haas 20 May '21

20 May '21

#2531: remove non piraha parser from Flesh Reporter: Roland Haas Status: new Milestone: Version: development version Type: enhancement Priority: trivial Component: Comment (by Roland Haas): Removing the parser code would resolve [https://bitbucket.org/cactuscode/cactus/pull-requests/103/cactus-avoid-comp… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2531/remove-non-piraha…

1 0

#2531: remove non piraha parser from Flesh
by Roland Haas 20 May '21

20 May '21

#2531: remove non piraha parser from Flesh Reporter: Roland Haas Status: new Milestone: Version: development version Type: enhancement Priority: trivial Component: Similarly to #2452 In the Turing release announcements: [http://einsteintoolkit.org/about/releases/ET\_2020\_05\_announcement.html](… we are deprecating the non-Piraha parser which increasingly no longer parses all existing parfiles $eg the non-piraha parfile parser does not handle `$foo = 42` types of variable assignments$. It should thus be removed from the code. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2531/remove-non-piraha…

1 0

#2499: New machine thornyflat at WVU
by Roland Haas 20 May '21

20 May '21

#2499: New machine thornyflat at WVU Reporter: Erik Schnetter Status: open Milestone: Version: development version Type: enhancement Priority: minor Component: SimFactory Comment (by Roland Haas): Pull request is here: [https://bitbucket.org/simfactory/simfactory2/pull-requests/50](https://bitb… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2499/new-machine-thorn…

1 0

#2413: Include "POWER" code to extrapolate waveforms to scri+ into ET
by Roland Haas 20 May '21

20 May '21

#2413: Include "POWER" code to extrapolate waveforms to scri+ into ET Reporter: Roland Haas Status: open Milestone: Version: Type: task Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Documentation and command line options for overriding f0, M\_ADM, M\_final and a\_final were added in git hash [a39f1e8](https://git.ncsa.illinois.edu/elihu/Gravitational_Waveform_Extract… "power: fix typo in docs" of [Gravitational\_Waveform\_Extractor](https://git.ncsa.illinois.edu/elihu/Gra… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2413/include-power-cod…

1 0

#2530: Thorn Vectors fails to compile using gcc 8.X on POWER9
by Roland Haas 18 May '21

18 May '21

#2530: Thorn Vectors fails to compile using gcc 8.X on POWER9 Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: minor Component: EinsteinToolkit thorn Vectors provides SIMD instructions for doubles on POWER9 using the `vec_st` intrinsic for aligned stores. However that intrinsic seems to differ in gcc 8 and gcc 9. This demo code: ``` #if 0 g++ -mcpu=power9 -mvsx $0 exit #endif #include <altivec.h> #define CCTK_REAL8 double typedef vector double CCTK_REAL8_VEC; static inline void vec8_store(CCTK_REAL8 &p, CCTK_REAL8_VEC x) { vec_st(x, 0 , &p); } int main(void) { CCTK_REAL8 p[2]; CCTK_REAL8_VEC x; vec8_store(p[0], x); return 0; } ``` demonstrates the issue and fails to compile when using eg `module load gcc/8.1.0` on summit but is fine with `module load gcc/9.1.0`: ```plaintext $ bash vec.cc vec.cc: In function 'void vec8_store(double&, CCTK_REAL8_VEC)': vec.cc:13:19: error: invalid parameter combination for AltiVec intrinsic '__builtin_vec_st' vec_st(x, 0 , &p); ``` Replacing `vec_st` by `vec_vsx_st` compiles the code with gcc 8.1.0 and gcc 9.1.0 on Summit $which allows unaligned loads$. Though no matter how much alignment I try to specify, `vec_st` never compiles for me: ```c++ #if 0 g++ -mcpu=power9 -mvsx $0 exit #endif #include <altivec.h> int main(void) { double p[8] __attribute__((aligned(16))); vector double x __attribute__((aligned(16))); vec_st(x, 0 , p); return 0; } ``` This is not a very worrysome issue right now since gcc 9.X is usually available, however it would be nice to not fail in this manner but rather check something to detect this issue or find out a workaround. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2530/thorn-vectors-fai…

1 0

#2529: Flang error in Cactus/src/util/PointerTo.F90
by Roland Haas 17 May '21

17 May '21

#2529: Flang error in Cactus/src/util/PointerTo.F90 Reporter: Erik Schnetter Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Roland Haas): uh ` f18 failed with exit status 0` is not very great behaviour of flang. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2529/flang-error-in-ca…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac