#1552: Support OS X 10.9.2
---------------------------+------------------------------------------------
Reporter: barry.wardell | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Cactus | Version: development version
Keywords: |
---------------------------+------------------------------------------------
The attached patch adds support for OS X 10.9.2 to the Cactus build
system.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1552>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1545: Parameter file parser errors should be more informative
--------------------+-------------------------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
The following error message produced by the parameter file parser does not
tell me which parameter was being set; the information is there because of
the line number, but it is odd to have an error message which doesn't
output the content of the line with the error.
{{{
WARNING level 0 in thorn ML_BSSN processor 0 host shelob001
(line 158 of bench.par):
->Invalid assignment: Attempting to set a variable of type KEYWORD with
(BOOL)false
}}}
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1545>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1543: hwloc in lib64
-----------------------------------+----------------------------------------
Reporter: barry.wardell | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
Often the hwloc libraries are installed in /usr/lib64. However, several
places in the configure script assumes it is installed in $HWLOC_DIR/lib.
I suggest applying the attached patch to correct this.
Additionally, the script assumes $HWLOC_DIR/lib/libhwloc.la exists. This
causes grep to print a confusing error if it does not exist. The second
patch causes grep to only run if this file exists.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1543>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1533: checkpoint cctk_delta_time in PUGH
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: IOHDF5Util |
-----------------------------------+----------------------------------------
the PUGH driver currently does not checkpoint the stepsize which makes
using it with adaptive timestepping hard. Carpet on the other hand
checkpoints the stepsize.
The attached patch writes cckt_delta_time into checkpoints. When reading a
checkpoint file that does not set the timestep, the user will see level 1
warning that the attribute cctk_delta_time was not found but the code will
not abort and will behave as it does right now otherwise (which is to use
cctk_delta_time based on the values from parameters/set in basegrid).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1533>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1444: CarpetLib does not compile with gcc 4.8 due to static_assert
--------------------+-------------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: Carpet | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
Attempting to compile CarpetLib with gcc 4.8 leads to the error
/Users/ian/Cactus/arrangements/Carpet/CarpetLib/src/prolongate_3d_rf2.cc:501:56:
error: 'static_assert' was not declared in this scope
I had not come across static_assert before. Apparently it is a C++11
feature. gcc 4.6 was able to compile it, but it looks like gcc 4.8 is
stricter. Do we want to require -std=c++11, or should we avoid C++11
features for now?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1444>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1538: Turn CCTK_REAL8 etc. into typedefs
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
Currently, CCTK_REAL8 are #defines. This is inconvenient, since e.g.
CCTK_REAL16 may be "long double", and the C++ syntax
{{{
CCTK_REAL16(x)
}}}
is then illegal, since this expands to "long double(x)". Turning
CCTK_REAL8 and friends into proper typedefs remedies this.
The attached patch also corrects two small issues in cctk_Types.h: (1) The
include guard around "cctk_Config.h" should not be there, and (2) some
#endifs have wrong comments.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1538>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1544: disallow empty value strings when setting numbers in CCTK_ParameterSet
--------------------+-------------------------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
Currently due to the way strtol and strtod work one can do
{{{
CCTK_ParameterSet("cctk_itlast", "Cactus", "")
}}}
which return 0 (all is fine) and sets cctk_itlast to 0 (rather than
failing with -6 "invalid string").
The attached patch checks that the parameter value string is not empty.
This cannot happen from inside of parfiles since the parser disallows it.
It can happen when using the Trigger thorn.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1544>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1509: ExternalLibraries do not check if patch is available
--------------------------------------------+-------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: LORENE hwloc ExternalLibraries |
--------------------------------------------+-------------------------------
some of the ExternalLibraries (LORENE, hwloc for example) use patch to
modify the upstream source. However they do not check if patch is
available and blindly use the flesh supplied $PATCH variable.
Since the flesh does not abort its configuration even when patch is
missing, this fails with an error message of the form "-p0: command not
found".
Either the flesh's configure should require patch to be present, or the
ExternalLibraries need to test for PATCH being empty (there is a bash
expansion that aborts if PATCH is undefined).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1509>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1484: close file handles in CarpetHDF5 reader when VisIt closes files
------------------------+---------------------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Other | Version: development version
Keywords: CarpetHDF5 |
------------------------+---------------------------------------------------
The VisIt plugin contains some caching logic for the HDF5 file metadata
(namely which datasets exist in which file, can be disabled by setting the
environment variable CARPETHDF5_CACHE_METADATA to "no"). There is a design
flaw in this code that causes it to never close the HDF5 file handle which
in turn causes libHDF5 to use up memory and (importantly) to not free the
OS file handle. With large runs and many variables it is quite possible to
run out of file descriptors.
The attached patch tries to correct this by freeing the HDF5 handle when
VisIt closes a file (but keeps the cached metadata in memory).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1484>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1459: ExternalLibraries/PAPI does not build with gcc 4.8.1
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: PAPI |
-----------------------------------+----------------------------------------
not sure if this depends on the gcc version, but I get the following error
when trying to compile PAPI:
{{{
PAPI: Building...
pfmlib_common.c: In function 'pfmlib_parse_event_attr':
pfmlib_common.c:760:10: error: declaration of 'endptr' shadows a previous
local [-Werror=shadow]
char *endptr = NULL;
^
pfmlib_common.c:737:20: error: shadowed declaration is here
[-Werror=shadow]
char *s, *p, *q, *endptr;
^
cc1: all warnings being treated as errors
}}}
I attache the full output of make.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1459>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit