#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
#2027: testsuite page is not avaiable on website
-------------------------------------+--------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit website | Version: development version
Keywords: |
-------------------------------------+--------------------------------------
The testsuite overview page
http://einsteintoolkit.org/release-info/parse_testsuite_results.php
does not currently work (since the website changed).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2027>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#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
#2078: thorn vectors fails if vectorizatin is disabled
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: Vectors |
-----------------------------------+----------------------------------------
At least in one case (gcc 7.2) thorn Vectors seems to fail with a message
that overloading is not allowed in line 671 of vectors.h
{{{
explicit constexpr vectype(scalar_t const &a) : v(props::set1(a)) {}
}}}
if vectorization is disabled (VECTORISE=no). My guess would be that in
this case scalar_t and vector_t are the same and a conflict exists (or
some other assumption is violated).
I'll provide more details once I have a a nicer testcase.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2078>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2080: Backports for the June 2017 release to compile on the NDS machine
-------------------------+--------------------------------------------------
Reporter: sbrandt | Owner:
Type: enhancement | Status: new
Priority: critical | Milestone:
Component: Other | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
I would like to backport the following files from master to the June 6th
release of the ET. The files are
repos/simfactory2:
bin/sim
mdb/machines/jupyteret.ini
mdb/optionlists/generic.cfg
mdb/runscripts/generic.run
Also, a small modification to the PAPI thorn:
{{{
Index: src/detect.sh
===================================================================
--- src/detect.sh (revision 42)
+++ src/detect.sh (working copy)
@@ -27,7 +27,7 @@
# libraries might have different file extensions
for libext in a dll dll.a dylib lib so; do
# libraries can be in lib or lib64 (or libx32?)
- for libdir in lib64 lib; do
+ for libdir in lib64 lib lib/x86_64-linux-gnu; do
# These files must exist
FILES="include/papi.h ${libdir}/libpapi.${libext}"
# assume this is the one and check all needed files
}}}
With these changes, the ET builds on the NDS machine. Moreover, it should
more easily build on machines which have no explicit entry in Simfactory.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2080>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2029: GW150914 example should be updated to work with the Einstein Toolkit
thornlist
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: optional | Milestone:
Component: Other | Version: development version
Keywords: gallery |
-------------------------+--------------------------------------------------
The GW150914 example currently uses its own thornlist, because Llama was
not part of the ET when it was created. Llama has now been added to the
ET. The GW150914 thornlist uses WaveExtractCPM and ADMConstraints. These
can probably be removed, for the sake of having a parameter file which
works with the ET thornlist. ADMConstraints can be replaced with
ML_ADMConstraints. WaveExtractCPM is an "in-development" code which has
not been extensively tested. It gives the GW strain directly from
Schwarzschild perturbation theory, without needing to go via fixed-
frequency integration of Psi4, so is good for quick plots. However, it
seems to give worse results than Psi4 for the ringdown, and possibly has
bugs in some of the l > 2 modes, so I don't think it is ready for
inclusion in the toolkit just yet.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2029>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#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
#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
#2072: Carpet: Disable OpenMP parallelization of transport operators
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner: eschnett
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Carpet | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
This disables the OpenMP parallelization of Carpet's transport operators.
I have observed that this leads to a significant speedup when many threads
are used.
The likely reason is that the regions which are parallelized are typically
small. A typical reason would e.g. be the lower x-boundary of one
component of one grid variable. The OpenMP thread startup overhead and the
cache misses caused by parallelizing this are then larger than any
benefit.
See <https://bitbucket.org/eschnett/carpet/pull-requests/18/carpet-
disable-openmp-parallelization-of/diff>.
In a next step (not proposed here), we can parallelize transport operators
again, but at a much higher level, e.g. at the level of the loop over all
variables that need to be prolongated. However, Carpet currently (and
quite unfortunately) uses static variables to hold pointers to timers, and
these are not thread-safe. (Neither the static variables nor the timer
implementation itself are.) This needs to be either corrected or disabled,
which will be the topic of a further pull request.
At this time, I ask some of those who are interested in performance in
trying this pull request on a few iterations of a production simulation
that uses many OpenMP threads and report back here.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2072>
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