#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
#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
#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
#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
#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
#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
#1919: have make newthorn create a functioning thorn
-------------------------+--------------------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: optional | Milestone:
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
Currently the newthorn make target does not create a functioning thorn. It
would be good if it produced a skeleton thorn that compiled.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1919>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2022: thorn guide on et website links to pdf pages
-------------------------------------+--------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit website | Version: development version
Keywords: |
-------------------------------------+--------------------------------------
This is a continuation #2010 which was about the thorn guide being
missing. This one is about the link behind "Thorn Guide" on
http://einsteintoolkit.org/documentation.html, namely
http://einsteintoolkit.org/thornguide/ points to an auto-generated index
page of a directory of pdf files. Instead of the correct HTML page for a
table of content pointing to html pages of documentation.
Likely requires web server access to fix.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2022>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2030: Multi-block boundaries leave uninitialized boundary points
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
Applying multi-block boundaries can leave uninitialized boundary points.
This happens when multi-block boundaries are used in combination with
another boundary condition that looks at the interior of the grid, such as
e.g. a symmetry condition or radiative / extrapolating boundaries.
There is another bug currently in McLachlan that applies its "scalar"
boundary conditions to too few grid points (it uses "BoundaryNoSync"
instead of "Boundary"), which means there are uninitialized boundary
points for {{{initial_boundary_condition = "scalar"}}} as well in multi-
block systems.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2030>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#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