Trac May 2016

trac@lists.einsteintoolkit.org

1 participants
117 discussions

[Einstein Toolkit] #1471: Cactus should auto-detect newer versions of GCC from MacPorts
by Einstein Toolkit 30 Apr '18

30 Apr '18

#1471: Cactus should auto-detect newer versions of GCC from MacPorts -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Currently, during Cactus configuration without an optionlist on Mac OS, I get {{{ checking for gcc-mp-4.4... no checking for gcc-mp-4.3... no checking for gcc-mp-4.2... no checking for gcc... gcc checking whether the C compiler (gcc ) works... yes }}} I have gcc-mp-4.6, and 4.7 and 4.8 are also available in macports. The configure script should be updated to detect these versions. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1471> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

2 11

[Einstein Toolkit] #1170: ExtrenalLibraries handle XXX_DIR XXX_INC_DIRS and XXX_LIB_DIRS incosistently
by Einstein Toolkit 20 Mar '18

20 Mar '18

#1170: ExtrenalLibraries handle XXX_DIR XXX_INC_DIRS and XXX_LIB_DIRS incosistently -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: ExternalLibraries | -----------------------------------+---------------------------------------- This is a companion ticket to #1006. Different thorns (eg. MPI and HDF5 and LAPACK) handle XXX_DIR and XXX_INC_DIRS etc differently. MPI for example sets the include path to $MPI_DIR/include if MPI_INC_DIRS is not explicitly set and to MPI_INC_DIRS if it is set. HDF5 has no HDF5_INC_DIRS option and always sets the include path to HDF5_DIR/include. LAPACK has not INC_DIRS option and sets the linker path to LAPACK_DIR while the other two thorns set it to XXX_DIR/lib (unless overridden by MPI_LIB_DIRS in the case of MPI). I would be good to present a uniform set of option for all these thorns. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1170> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1769: External libraries: moving towards multiarch library directory structure
by Einstein Toolkit 20 Mar '18

20 Mar '18

#1769: External libraries: moving towards multiarch library directory structure ----------------------------------------------+----------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2015_05 Component: EinsteinToolkit thorn | Version: development version Keywords: ExternalLibraries HDF5 Multiarch | ----------------------------------------------+----------------------------- Several Linux distributions have already started to move their libraries to a new directory structure that reflects the target architecture and allows the installation of packages from multiple architectures in the same system. The following links provide more details of this change: {{{ https://wiki.debian.org/Multiarch/TheCaseForMultiarch https://wiki.ubuntu.com/MultiarchSpec }}} This change potentially affects several of external library scripts shipped with ET. For example the HDF5/src/detect.sh script is not able to detect the hdf5 libraries installed in the directory /usr/lib/x86_64 -linux-gnu for Ubuntu 14.04.2 LTS. I have attached a simple patch to remedy this issue and open a discussion on the best way to proceed here. This patch does depend on the availability of gcc on the system. It currently works fine for me, but we might need a better solution for systems without gcc. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1769> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 40

[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] #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] #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] #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

[Einstein Toolkit] #1599: CarpetInterp/waveinterp_2p tests constant in time initial data
by Einstein Toolkit 27 Dec '17

27 Dec '17

#1599: CarpetInterp/waveinterp_2p tests constant in time initial data --------------------------+------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: CarpetInterp | --------------------------+------------------------------------------------- the test waveinterp_2p sets up initial data using IDWaveMoL (fom CactusExamples) using kx=ky=kz = 0. and slopet = 0.1. Ie the initial data is constant in space and has frequency 0.1. It then evolves this using WaveMoL and interpolates in space and time with CarpetInterp. Since the function is constant in space (exactly so, see eg the output in InterpToArray::array1d_vars[0]) the interpolation in space just tests roundoff errors. The second time derivative (array1d_vars[2]) should be zero and all we measure in the test is truncation errors on the level of 1e-9. This makes the test very sensitive to -Ofast, -O0, gcc vs. intel etc. and not a very good test. I would rather either use a Gausian wave for initial data so that there is some actual data in the result and not just numerical noise, or leave out the 2nd time derivative from the test data. The test fails due to significant errors in a virtual machine using ubuntu.cfg (which usies -ffast-math and -O2). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1599> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #1753: hwloc: move pkg-config based detection into Search phase
by Einstein Toolkit 13 Dec '17

13 Dec '17

#1753: hwloc: move pkg-config based detection into Search phase -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: hwloc | -----------------------------------+---------------------------------------- the attacheched patch changes detect.sh such that pkg-config is treated on the same footing as the search at commonly known places. It also adds the option for the user to specify HWLOC_LIBS rather than hard-coding it to hwloc. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1753> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac May 2016