#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
#2125: LORENE2: Improve generation of BNS ID for larger mass ratio
---------------------------------------+------------------------------------
Reporter: roberto.depietri@… | Owner: depietri
Type: enhancement | Status: new
Priority: optional | Milestone: ET_2018_08
Component: EinsteinToolkit thorn | Version: development version
Keywords: LORENE2 |
---------------------------------------+------------------------------------
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2125>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2127: add sanity and safety checks to EOS_Omni
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: EOS_Omni |
-----------------------------------+----------------------------------------
The pull request
https://bitbucket.org/einsteintoolkit/einsteineos/pull-requests/4
/eos_omni-add-sanity-checks-when-requesting/diff
adds some safety checks to EOS_Omni's GetHandle function to make sure that
eg a tabulated EOS has loaded its EOS table before it can be used.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2127>
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
#2109: Write the release announcement
----------------------------+-----------------------------------------------
Reporter: hinder | Owner: sbrandt
Type: task | Status: new
Priority: major | Milestone: ET_2018_02
Component: Other | Version: development version
Keywords: ReleaseProcess |
----------------------------+-----------------------------------------------
The release announcement for the upcoming release needs to be written.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2109>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2112: move CCTK_MyHost and friends into flesh
--------------------------------+-------------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version: development version
Keywords: Carpet PUGH driver |
--------------------------------+-------------------------------------------
Currently Carpet provides functions CCTK_MyHost etc that lets a thorn
discover which host it is running on and what its "rank" local to the host
is (ie process N of M processes on a given host).
It would be good to have this information provided by the flesh similar to
{{{CCTK_MyRank()}}} which will require a new set of overloadable functions
(of the same name) for Carpet to hook into.
Not sure what to do about the currently used aliased function names that
would then cause a conflict.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2112>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2093: Show if this machine matches the mdb
-------------------------+--------------------------------------------------
Reporter: sbrandt | Owner:
Type: enhancement | Status: new
Priority: unset | Milestone:
Component: SimFactory | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
It would be useful if Simfactory could tell you whether your machine
matches something in the mdb. This pull request makes that work.
See pull request:
https://bitbucket.org/simfactory/simfactory2/pull-requests/23/show-this-
machine/diff
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2093>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit