Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2660: create autoconf test that checks for too old g++ STL in combination with icpc
by Roland Haas 02 Nov '22

02 Nov '22

#2660: create autoconf test that checks for too old g++ STL in combination with icpc Reporter: Roland Haas Status: new Milestone: Version: Type: task Priority: minor Component: Compilation of the ET on clusters regularly fails if icpc is combined with a too old STL from g\+\+. As of [https://www.einsteintoolkit.org/about/releases/ET\_2022\_05\_announcement.h… the ET must be compiled with STL from gcc-6 \(or later\) when using icpc to provide for full C\+\+11 support \(and not technical preview C\+\+11\). Similarly before, using gcc-4.3 \(default on some redhat systems\) will fail to compile vectors due to bad default constructors. We should construct an autoconf test that tests for these issues and reports a useful error message to users setting up Cactus / the ET on their cluster. Note that technically Cactus would work with older C\+\+ compilers but the Einstein Toolkit will not. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2660/create-autoconf-t…

1 0

#2654: PR for ADMAnalysis Trace function with incorrect interface
by Roland Haas 27 Oct '22

27 Oct '22

#2654: PR for ADMAnalysis Trace function with incorrect interface Reporter: Samuel Cupp Status: resolved Milestone: Version: development version Type: bug Priority: minor Component: EinsteinToolkit thorn Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2654/pr-for-admanalysi…

1 0

#2654: PR for ADMAnalysis Trace function with incorrect interface
by Roland Haas 27 Oct '22

27 Oct '22

#2654: PR for ADMAnalysis Trace function with incorrect interface Reporter: Samuel Cupp Status: new Milestone: Version: development version Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): Applied as git hash [7d4a1e95](https://bitbucket.org/einsteintoolkit/einsteinanalysis/commits/7d… "ADMAnalysis: fixed comments" of [einsteinanalysis](https://bitbucket.org/einsteintoolkit/einsteinanalysis) will revert if this actually causes problems. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2654/pr-for-admanalysi…

1 0

#2175: Test "Single, stable neutron star" example
by Roland Haas 27 Oct '22

27 Oct '22

#2175: Test "Single, stable neutron star" example Reporter: Roland Haas Status: open Milestone: ET_2022_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): Before each release, check that http://einsteintoolkit.org/gallery/ns/index.html still works and produces correct output using the current development code: ```shell curl -kLO https://raw.githubusercontent.com/gridaphobe/CRL/master/GetComponents chmod a+x GetComponents ./GetComponents --parallel --shallow https://bitbucket.org/einsteintoolkit/manifest/raw/master/einsteintoolkit.th pip install --user -U kuibit ``` Then upload the results file to [https://bitbucket.org/einsteintoolkit/www/downloads/](https://bitbucket.org… Then update [https://bitbucket.org/einsteintoolkit/www/src/master/gallery/ns/](https://b… with updated image files and updating index.html **Keyword:** None ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2175/test-single-stabl…

1 0

#2175: Test "Single, stable neutron star" example
by Leung, Lisa Jing 26 Oct '22

26 Oct '22

#2175: Test "Single, stable neutron star" example Reporter: Roland Haas Status: open Milestone: ET_2022_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Comment (by Leung, Lisa Jing): Ran and uploaded result on 10/26/2022 with latest update, maximum density plot looks consistent with 5/12/2022 result -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2175/test-single-stabl…

1 0

#2659: ExternalLibrary auto-detection fails on M1 macs using homebrew
by Roland Haas 26 Oct '22

26 Oct '22

#2659: ExternalLibrary auto-detection fails on M1 macs using homebrew Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: With @{6350afe6fe5ff37523587456} I just dug down a bit into compilation failures using HomeBrew on macOS M1. There were three errors reported at CST stage by ExternalLibraries; ``` CST error 1: -> Configuration script for thorn LIBJPEG returned exit code 77 (no error message) CST error 2: -> Configuration script for thorn OPENSSL returned exit code 2 (no error message) CST error 3: -> Configuration script for thorn ZLIB returned exit code 1 (no error message) ``` which turn out to be compilation failures, at least in LIBJPEG’s case. Now libjpeg should not even be attempted to be compiled since the tutorial instructions \(which were followed\) contain `brew install jpeg` and indeed `jpeg` was installed. It turns out that HomeBrew moved from `/usr/local` to `/opt/homebrew` so that the rather limited set of locations checked by many ExternalLibraries no longer match. `pkg-config` is not help here either it seems. Part of this is already broken on x86 macs where HomeBrew does not install `OpenSSL` and `zlib` into `/usr/local` but only into its own `Cellar` hierarchy so that the installed copies are being ignored already on x86 macs \(verified on my own x86 macOS VM\). With this we can no longer claim macOS support using homebrew. If similar issues occur using macports then we can no longer claim any macOS support. Fixes would involve finding out why pkg-config fails and also why compilation attempts fail. Looking at the log files for libjpeg it tried using `gcc` \(ie Apple’s clang-in-disguise\) instead of the correct `gcc-12` from homebrew. This, unsurprisingly failed. Similarly for OpenSSL \(fails due to lack of support of `-fopenmp`\) and similar for zlib. ‌ This will need a M1 owner to step forward as a volunteer to help fix this. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2659/externallibrary-a…

1 0

#2658: change cGroup centeringtable into flat list of integers
by Roland Haas 26 Oct '22

26 Oct '22

#2658: change cGroup centeringtable into flat list of integers Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: minor Component: Currently, and for mostly historical reason, since it started out as a tag, `centeringtable` is a handle making its use less convenient than may be desired. For the most part this data is used by the driver, since user codes normally “know” what centering their grid functions have. However it may also be used by non-driver infrastructure thorns. Also it may be good to define a default centering Cactus wide instead of letting the driver define its defaults so that non-driver infrastructure thorns can be provided with a centering value that matches what the driver uses if none is provided. A more convenient data structure would be just a `const int *` similar to e.g. `cGroupDynamicData.lsh`. This would require that `CCTK_GroupCenteringTableI` uses a calling syntax similar to `CCTK_GroupbboxGI` ie ``` int CCTK_GroupCenteringTableGI(const cGH *cctkGH, int size, int *centeringtable, int groupindex); ``` which copies the data into a user supplied buffer to support C and Fortran callers. While in the flesh all centering code is still considered experimental \(and intentionally not documented yet\) so can be changed. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2658/change-cgroup-cen…

1 0

#2173: Test "Poisson equation" example
by Nadine Kuo 26 Oct '22

26 Oct '22

#2173: Test "Poisson equation" example Reporter: Roland Haas Status: resolved Milestone: ET_2022_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Changes (by Nadine Kuo): status: resolved (was open) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2173/test-poisson-equa…

1 0

#2176: Test "Binary neutron star" example
by Roland Haas 25 Oct '22

25 Oct '22

#2176: Test "Binary neutron star" example Reporter: Roland Haas Status: open Milestone: ET_2022_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Comment (by Roland Haas): Hmm, not any different from my laptop \(which also shows the 1024 open files restriction\). ``` real-time non-blocking time (microseconds, -R) unlimited core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 78729 max locked memory (kbytes, -l) 2526916 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 78729 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited ``` ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2176/test-binary-neutr…

1 0

#2176: Test "Binary neutron star" example
by Bing-Jyun Tsao 25 Oct '22

25 Oct '22

#2176: Test "Binary neutron star" example Reporter: Roland Haas Status: open Milestone: ET_2022_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Comment (by Bing-Jyun Tsao): ``` core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 126665 max locked memory (kbytes, -l) 65536 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 126665 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited ``` Here is the output with `ulimit -a`. You are correct, this is actually ran on a computer that is shared among our group members. ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2176/test-binary-neutr…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac