Trac July 2018

trac@lists.einsteintoolkit.org

1 participants
55 discussions

[Einstein Toolkit] #2008: NaNs when running static tov on >40 cores
by Einstein Toolkit 22 Aug '18

22 Aug '18

#2008: NaNs when running static tov on >40 cores -----------------------------------+---------------------------------------- Reporter: allgwy001@… | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: ET_2016_05 Keywords: | -----------------------------------+---------------------------------------- I've been trying to run the static tov example parameter file on an HPC cluster using >40 cores, but this results in NaNs in the data. I can't remember whether the issue first appears at 40 or 41 cores (and won't be able to check this for the next few days), but using 41+ cores definitely gives me NaNs. I remember testing with 39 cores and several other lower values (down to 4), but these runs all seemed fine. So far, I've been able to run larger simulations (e.g. BBHs) on more than 40 cores (same cluster) without any apparent issues. I'll attach the static tov parameter file I used (I think I changed one or two outdated parameters), as well as the PBS script and error/output files from a static tov run on 44 cores. The static tov runs were intended for speed test purposes. The results of the speed tests I've run so far (on fewer than 40 cores) seem quite strange to me, so I'm going to attach a text file with walltimes and CPU times for these runs, too. Any comments would be appreciated! -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2008> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

2 13

[Einstein Toolkit] #2175: Test "Single, stable neutron star" example
by Einstein Toolkit 17 Aug '18

17 Aug '18

#2175: Test "Single, stable neutron star" example -------------------------------------+--------------------------------- Reporter: Roland Haas | Owner: Roland Haas Type: task | Status: assigned Priority: major | Milestone: ET_2018_08 Component: EinsteinToolkit website | Version: development version Keywords: | -------------------------------------+--------------------------------- Before each release, check that http://einsteintoolkit.org/gallery/ns/index.html still works and produces correct output. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2175> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #2167: clean up CT_MultiLevel to avoid warnings and fix a small memory leak
by Einstein Toolkit 13 Aug '18

13 Aug '18

#2167: clean up CT_MultiLevel to avoid warnings and fix a small memory leak ---------------------------------+--------------------------- Reporter: anonymous | Type: defect Status: new | Priority: minor Milestone: | Component: Other Version: development version | Keywords: CT_MultiLevel ---------------------------------+--------------------------- Pull request is here: https://bitbucket.org/eloisa/ctthorns/pull-requests/1/clean-up- ct_multilevel-to-avoid-warnings/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2167> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #2178: PITTNull can take a very long time to compile with the Intel compiler
by Einstein Toolkit 13 Aug '18

13 Aug '18

#2178: PITTNull can take a very long time to compile with the Intel compiler ---------------------------------+----------------------------------- Reporter: Roland Haas | Type: defect Status: new | Priority: minor Milestone: | Component: EinsteinToolkit thorn Version: development version | Keywords: NullConstr ---------------------------------+----------------------------------- Compiling on stampede2-skx (2018_02 simfactory files, so ifort 18.0.0) the file {{{NullConstr/src/NullConstr_R00.F90}}} takes a very long time (103 minutes an counting) to compile. My guess is that one has to translate its array operations to loops (similar to what was done for other source files in PITTNull), otherwise the compiler just takes too long to try and optimize the code. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2178> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 15

[Einstein Toolkit] #1263: Multipole does not handle variable names correctly
by Einstein Toolkit 13 Aug '18

13 Aug '18

#1263: Multipole does not handle variable names correctly -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: Multipole | -----------------------------------+---------------------------------------- When you specify variables for Multipole to decompose, you have the option of giving it a "name" for the variable to be used in the output filename. This is useful if you are decomposing Psi4r, with imaginary part Psi4i, and want the file to just be named "Psi4". If you don't specify a name, it is supposed to use the original variable name. However, at the moment, this last part seems to be broken. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1263> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1201: Incorrect dtshift in Exact with shift_add_{x, y, z} parameters
by Einstein Toolkit 09 Aug '18

09 Aug '18

#1201: Incorrect dtshift in Exact with shift_add_{x,y,z} parameters -----------------------------------+---------------------------------------- Reporter: barry.wardell | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The Exact thorn has shift_add_{x,y,z} parameters for adding a constant to the shift. Considering these as a coordinate transformation using a vector v^i = [shift_add_x, shift_add_y, shift_add_z], such a transformation should affect both the shift and its time derivative. This is because the time derivative in the new coordinates differs from the time derivative in the old coordinates by a term v^j d(beta^i)/dx^j. This is correctly implemented as a 4D coordinate transformation in the EinsteinExact thorns and I have verified that the difference relative to the Exact thorn is given by this missing term. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1201> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1097: Describe Tmunu in GRHydro
by Einstein Toolkit 09 Aug '18

09 Aug '18

#1097: Describe Tmunu in GRHydro -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Describe in GRHydro's documentation how Tmunu is defined -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1097> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #2158: Without MPI installed, Cactus doesn't build
by Einstein Toolkit 09 Aug '18

09 Aug '18

#2158: Without MPI installed, Cactus doesn't build ---------------------------------+-------------------- Reporter: Steven R. Brandt | Type: defect Status: new | Priority: unset Milestone: | Component: Other Version: development version | Keywords: ---------------------------------+-------------------- I attempted to test our automatic building of Cactus on a system without MPI installed. In principle, thorn MPI should build and the system should work. Instead, I get this: {{{ MPI: Building... Making all in config Making all in contrib Making all in opal Making all in include Making all in asm CC asm.lo ln -s "../../opal/asm/generated/atomic-amd64-linux.s" atomic-asm.S CPPAS atomic-asm.lo CCLD libasm.la ../../libtool: line 6000: cd: NO_BUILD/lib: No such file or directory libtool: link: cannot determine absolute directory name of `NO_BUILD/lib' Makefile:1584: recipe for target 'libasm.la' failed make[6]: *** [libasm.la] Error 1 Makefile:2153: recipe for target 'all-recursive' failed make[5]: *** [all-recursive] Error 1 Makefile:1702: recipe for target 'all-recursive' failed make[4]: *** [all-recursive] Error 1 Died at /home/etuser/Cactus/arrangements/ExternalLibraries/MPI/src/build.pl line 74. /home/etuser/Cactus/arrangements/ExternalLibraries/MPI/src/make.code.deps:9: recipe for target '/home/etuser/Cactus/configs/sim/scratch/done/MPI' failed make[3]: *** [/home/etuser/Cactus/configs/sim/scratch/done/MPI] Error 17 /home/etuser/Cactus/lib/make/make.thornlib:112: recipe for target 'make.checked' failed make[2]: *** [make.checked] Error 2 /home/etuser/Cactus/lib/make/make.configuration:181: recipe for target '/home/etuser/Cactus/configs/sim/lib/libthorn_MPI.a' failed make[1]: *** [/home/etuser/Cactus/configs/sim/lib/libthorn_MPI.a] Error 2 Makefile:256: recipe for target 'sim' failed make: *** [sim] Error 2 The command '/bin/sh -c ./simfactory/bin/sim build -j8 --thornlist ../einsteintoolkit.th' returned a non-zero code: 1 }}} The test system is made from docker {{{ FROM ubuntu RUN apt-get update RUN apt-get install -y python3 RUN apt-get install -y libfftw3-dev libssl-dev libhdf5-dev subversion gcc curl libjpeg-turbo?-dev git make pkg-config g++ libpapi-dev patch libgsl- dev libhwloc-dev python liblapack-dev numactl gfortran RUN adduser etuser USER etuser WORKDIR /home/etuser ENV USER etuser RUN curl -kLO https://raw.githubusercontent.com/gridaphobe/CRL/master/GetComponents RUN chmod a+x GetComponents RUN ./GetComponents --parallel https://bitbucket.org/einsteintoolkit/manifest/raw/master/einsteintoolkit.th RUN echo testme > .hostname WORKDIR /home/etuser/Cactus RUN ./simfactory/bin/sim setup-silent RUN ./simfactory/bin/sim build -j8 --thornlist ../einsteintoolkit.th }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2158> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #660: Make MHD multipatch-aware
by Einstein Toolkit 09 Aug '18

09 Aug '18

#660: Make MHD multipatch-aware -----------------------------------+---------------------------------------- Reporter: tbode | Owner: tbode Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- At least the Con2PrimM routines need to be multipatch-aware. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/660> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1690: The test system should treat a nonzero exit code from Cactus as a failure
by Einstein Toolkit 08 Aug '18

08 Aug '18

#1690: The test system should treat a nonzero exit code from Cactus as a failure --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- The test system seems to ignore the fact that Cactus exits with a nonzero exit code. It displays Cactus exited with error code 1 Please check the logfile... No files created in test directory Success: 0 files identical And in the summary at the end, it treats this as a passing test. In this case, there were no test reference files and no files output, because the test (by design) does not produce any data, it just aborts if the test fails. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1690> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac July 2018