#719: Mailing lists could have a link to the archived version of the message
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Other | Version:
Keywords: |
-------------------------+--------------------------------------------------
It would be useful for the footer of a mailing list posting to contain a
URL to the archived version of the message so that it is easy to point
people to the message in an email. This would apply to both the Cactus
and the ET lists.
It appears that this is not straightforward in MailMan 2, but is expected
in version 3: http://mail.python.org/pipermail/mailman-
users/2011-October/072378.html.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/719>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#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
#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
#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/TheCaseForMultiarchhttps://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
#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
#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
#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
#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