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