Trac March 2017

trac@lists.einsteintoolkit.org

1 participants
100 discussions

[Einstein Toolkit] #1474: compile ExternalLibraries with other thorns rather than when CST runs
by Einstein Toolkit 20 Mar '18

20 Mar '18

#1474: compile ExternalLibraries with other thorns rather than when CST runs -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Compiling external libraries takes a long time by now. Currently this happens very early in the compilation phase, before the other thorns are compiled. It would be better if the compilation happened at the same time as that of other thorns. This will entail splitting the configuration ie. detecting whether to build the included source or use a system wide copy from the compilation, most likely either using Cactus makefile variables or temporary files to transfer the decisions from the configuration stage to the build stage. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1474> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1946: sim setup should create a section for the current machine
by Einstein Toolkit 26 Feb '18

26 Feb '18

#1946: sim setup should create a section for the current machine -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- When calling sim setup on a machine in the machine data base (eg bluewaters in my case) it it still creates only a {{{[default]}}} section in defs.local.ini which means that the account information and possibly non-default sourcebasedir are not used for bluewaters leading to hard to understand error messages later on. I would thus like to suggest to change sim setup such that instead (or in addition to) a "[default]" section it creates a section for the detected machine if it already knows this machine. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1946> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1911: Hydro_InitExcision sphere_pugh_ppm test fails
by Einstein Toolkit 31 Jan '18

31 Jan '18

#1911: Hydro_InitExcision sphere_pugh_ppm test fails ---------------------------+------------------------------------------------ Reporter: barry.wardell | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | ---------------------------+------------------------------------------------ The Hydro_InitExcision sphere_pugh_ppm test fails for me when run on 1 process on an Ubuntu 16.04 machine. The diffs are attached. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1911> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #1995: McLachlan constraint tests fail
by Einstein Toolkit 26 Jan '18

26 Jan '18

#1995: McLachlan constraint tests fail ---------------------------------------------------------------+------------ Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2016_11 Component: EinsteinToolkit thorn | Version: development version Keywords: McLachlan constraints tests compiler optimization | ---------------------------------------------------------------+------------ Several tests fail on several machines, and the cause seems to be the constraints calculated by McLachlan. Peter is looking into this. We see test failures in the thorns Dissipation and RotatingSymmetry90/180. Indications are that most failures happen with Intel 15, but some are apparently also seen with Intel 16, while others with Intel 16 seem to work fine. Optimization -O1 instead of -O2 seems to prevent the problem, but is not a viable workaround. A simple 'print' statement in the affected (auto-generated) code also makes the problem disappear. Running using one MPI process and one openMP thread reproduces the problem. valgrind does not find anything obvious pointing to memory mess-up. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1995> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 48

[Einstein Toolkit] #1725: Disable Fortran 77 support in Cactus
by Einstein Toolkit 24 Jan '18

24 Jan '18

#1725: Disable Fortran 77 support in Cactus -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- There are no "Fortran 77" compilers any more. Cactus currently distinguishes between FCODE and F90CODE (pure Fortran 77, and Fortran 90). The pure Fortran 77 code has less argument checking etc. and is less safe, and is not needed any more. It should be removed, both from the makefile system as well as from the CST that auto-generates code. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1725> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #2021: compiling Carpet fails with intel 17 and optimisation
by Einstein Toolkit 22 Jan '18

22 Jan '18

#2021: compiling Carpet fails with intel 17 and optimisation -----------------------------------------+---------------------------------- Reporter: wolfgang.kastaun@… | Owner: eschnett Type: defect | Status: new Priority: unset | Milestone: Component: Carpet | Version: Keywords: | -----------------------------------------+---------------------------------- Compiling carpet with intel 17.0.1 and -O2 or -O3 triggers an internal compiler error ("internal error: 0_76"). It only affects the file bbox.cc. Happened on two different clusters. ET version is Payne. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2021> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 22

[Einstein Toolkit] #1784: osx-homebrew.cfg does not work out of the box on Yosemite
by Einstein Toolkit 22 Jan '18

22 Jan '18

#1784: osx-homebrew.cfg does not work out of the box on Yosemite ------------------------+--------------------------------------------------- Reporter: anonymous | Owner: Type: task | Status: new Priority: optional | Milestone: Component: SimFactory | Version: ET_2015_05 Keywords: | ------------------------+--------------------------------------------------- When installing ET anew on Yosemite with the instructions in osx-homebrew.cfg, the build fails because homebrew gets the latest version of gcc (5.1), which is currently not the one then specified in the cactus compilation options (4.9). This problem was encountered by a student who approached ET for the first time. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1784> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1757: Stampede needs to be updated
by Einstein Toolkit 22 Jan '18

22 Jan '18

#1757: Stampede needs to be updated ----------------------+----------------------------------------------------- Reporter: hinder | Owner: Type: task | Status: new Priority: critical | Milestone: Component: Other | Version: development version Keywords: backport | ----------------------+----------------------------------------------------- The SimFactory definition for Stampede currently uses the intel/13.1.1.163 compiler. This compiler will be removed next Tuesday (see https://portal.tacc.utexas.edu/user-guides/stampede/intel15). According to TACC, the current default is the older intel/13.0.2.146, and this is the recommended and default compiler, and will remain so. Both compilers have the "restrict" keyword blacklisted in Cactus (#1276). They will install intel/15.0.1 at the end of April. There is also intel/14.0.1.106 available, but it is labeled as "limited software stack". It is not clear why they are removing a newer compiler, or why they chose to do this a month before installing an even newer one. Our options are: 1. Upgrade to intel/14.0.1.106, which is labeled as "limited software stack" 2. Downgrade to intel/13.0.2.146, which is the default and will remain so for a while This should be done both for the trunk and the release branch. I suggest that option 2 is the most conservative, and probably the easiest, as there might be libraries which are not compiled for intel/14.0.1.106. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1757> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #2007: MoL fails to build with Intel compiler
by Einstein Toolkit 22 Jan '18

22 Jan '18

#2007: MoL fails to build with Intel compiler ---------------------+------------------------------------------------------ Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: blocker | Milestone: Component: Cactus | Version: development version Keywords: | ---------------------+------------------------------------------------------ Compiling MoL gives this error: {{{ /home/ianhin/Cactus/EinsteinToolkitGit/arrangements/CactusNumerical/MoL/src/RK4-RK2.c(60): error: unrecognized OpenMP #pragma #pragma omp /*parallel for*/ ^ compilation aborted for /home/ianhin/Cactus/EinsteinToolkitGit/configs/sim/build/MoL/RK4-RK2.c (code 2) }}} This code was introduced in https://bitbucket.org/cactuscode/cactusnumerical/commits/09a209266daa281a3e…. Removing the commented portion doesn't help. Replacing it with {{{ #pragma omp parallel }}} allows the code to compile. This is on Minerva, with icc (ICC) 16.0.1 20151021. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2007> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #1458: intel 13 2013.1.117 miss-compiles asserts in TwoPunctures tp_utils.c
by Einstein Toolkit 22 Jan '18

22 Jan '18

#1458: intel 13 2013.1.117 miss-compiles asserts in TwoPunctures tp_utils.c -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: TwoPunctures | -----------------------------------+---------------------------------------- this continues the thread in #1429 in particular https://trac.einsteintoolkit.org/ticket/1429#comment:14. Currently we need to determine which versions are affected. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1458> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac March 2017