Trac November 2014

trac@lists.einsteintoolkit.org

1 participants
159 discussions

[Einstein Toolkit] #1481: Hidden hard-coded limits on max_l_modes and max_vars in Multipole
by Einstein Toolkit 10 Nov '14

10 Nov '14

#1481: Hidden hard-coded limits on max_l_modes and max_vars in Multipole --------------------------------------+------------------------------------- Reporter: bernard.j.kelly@… | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2013_11 Component: EinsteinToolkit thorn | Version: ET_2013_05 Keywords: Multipole | --------------------------------------+------------------------------------- The EinsteinAnalysis/Multipole thorn has hard-coded limits (in src/multipole.cc) on the number of grid functions that can be decomposed (max_vars) and how high in polar quantum number this decomposition can go (max_l_modes). However, these are not reflected in the thorn's param.ccl. In fact, param.ccl contains a parameter "l_max", allowing it to be *any* positive value, and doesn't test this against max_l_modes until execution of this source. Wouldn't it make more sense to impose max_l_modes immediately at PARAMCHECK? To make the actual limit on interpolated functions explicit, a number of desired interpolants could be set in param.ccl (like "n_variables") --- limited if necessary to a hard-coded number that appears as a limit in the range. If the user tries to set n_variables too high, it gets caught at PARAMCHECK; if (s)he accidentally includes too many entries in the "variables" parameter, the extra ones would just be silently ignored. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1481> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1360: TAT/TATPETSc has no (ET-only) testsuite
by Einstein Toolkit 10 Nov '14

10 Nov '14

#1360: TAT/TATPETSc has no (ET-only) testsuite -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: ET_2013_11 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- It would be nice if TATPETSc, being part of the ET, would have at least one testsuite that can actually run using the ET only. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1360> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1317: GRHydro should provide _one_ mechanism to set a GP to atmosphere
by Einstein Toolkit 10 Nov '14

10 Nov '14

#1317: GRHydro should provide _one_ mechanism to set a GP to atmosphere -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- GRHydro should provide _one_ mechanism to set a GP to atmosphere which should then be used whenever that should be the case. Right now, this is copied in several places. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1317> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1692: change paths in manifest/einsteintoolkit.th to be able to use GetComponents to restore missing symbolic links
by Einstein Toolkit 05 Nov '14

05 Nov '14

#1692: change paths in manifest/einsteintoolkit.th to be able to use GetComponents to restore missing symbolic links ---------------------------+------------------------------------------------ Reporter: rhaas | Owner: eric9 Type: defect | Status: new Priority: minor | Milestone: Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ This patch changes the CHECKOUT path description of the git repos that are checked out whole into directories (manifest, utils, CoreDoc among them). Most likely due to way GetComponents decides if a component is already checked out, the previous version would not succeed in actually restoring a missing "manifest" symbolic link when it was deleted manually and GetComponents used to restore it. Ie. GetComponents https://bitbucket.org/einsteintoolkit/manifest/raw/master/einsteintoolkit.th cd Cactus rm manifest bin/GetComponents repos/manifest/einsteintoolkit.th will not restore manifest. Pull request is here: https://bitbucket.org/einsteintoolkit/manifest/pull- request/3/einsteintoolkitth-change-checkout-so-that/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1692> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1685: Access of freed memory in CarpetIOHDF5 during 1-Proc test of recoverML-EE.par
by Einstein Toolkit 05 Nov '14

05 Nov '14

#1685: Access of freed memory in CarpetIOHDF5 during 1-Proc test of recoverML- EE.par ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: | ---------------------+------------------------------------------------------ I originally found the problem with clang, but have verified it with valgrind. A parameter is being freed by CCTK_SetString() in Misc.c, but is reused by CarpetIOHDF5. To reproduce, I build with clang, after commenting out the papi and hwloc thorns. Commenting out the call to free in CCTK_SetString() reveals alignment errors in LoopControl. I'm attaching the cfg file I used to build with clang. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1685> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1688: Nonexistent thorns should trigger an immediate fatal error
by Einstein Toolkit 05 Nov '14

05 Nov '14

#1688: Nonexistent thorns should trigger an immediate fatal error --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- If Cactus is built with a thornlist that contains thorns which are not present in the Cactus tree, there should be an immediate fatal error indicating this. Currently, the CST continues to run, building external libraries, and finally reporting just the fact that some dependencies are not satisfied, when the real problem is that the thorn has not been checked out. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1688> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1686: remove pciutils from ET list
by Einstein Toolkit 05 Nov '14

05 Nov '14

#1686: remove pciutils from ET list -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: blocker | Milestone: ET_2014_11 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- ExternalLibraries pciutils currently does not compile on OSX (#1658), it hard-codes the compiler to be gcc (#1657), it does not search for a system installed version of itself (those can actually exist on Linux machines, #1669), and mis-behaves in that its VERBOSE setting is the default (ie it outputs all shell commands it executes in configure.sh). libpciutils was added in ticket #1621 and was not part of the last release so we are not bound be the decprecation policy. Since only PAPI makes use of it, and PAPI compiles without, I would suggest to comment out libpciutils for the release thornlist. This is marked "blocker" due to #1658 preventing any ET build on OSX machines. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1686> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1661: ExternalLibraries/PAPI does not build with gcc 4.8.2
by Einstein Toolkit 05 Nov '14

05 Nov '14

#1661: ExternalLibraries/PAPI does not build with gcc 4.8.2 -----------------------------------+---------------------------------------- Reporter: tbode | Owner: tbode Type: defect | Status: new Priority: major | Milestone: ET_2014_11 Component: EinsteinToolkit thorn | Version: development version Keywords: PAPI | -----------------------------------+---------------------------------------- This seems to be a repeat of #1459 whose fix was never re-applied after updating to PAPI-5.3.0. With the newer version of PAPI and newer compiler, there are quite a few newer complaints (see attached make.log). This is done on a machine running Ubuntu 14.04 Trusty. I am attaching an equivalent set of patches to #1459 which seems to work as a workaround for the moment (namely removing the -Werror flags). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1661> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #1598: ExternalLibraries/MPI does not auto-detect openmpi on Debian/testing
by Einstein Toolkit 01 Nov '14

01 Nov '14

#1598: ExternalLibraries/MPI does not auto-detect openmpi on Debian/testing -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: MPI | -----------------------------------+---------------------------------------- configure.sh expects to find libmpi.a in $MPI_DIR/lib however Debian no longer delivers a static libmpi.a but only libmpi.so so the tests fails. The fix is likely similar to what HDF5 already does (ie accept any of .a .so .dylib as extensions for libraries). The fix is a bit complex though, so (given that Debian/stable is still fine) this is a reminder for after the release. Explictly specifying MPI_DIR, MPI_INC_DIRS, MPI_LIB_DIRS and MPI_LIBS allows this to be worked around in the current release. For reference, the fragment from HDF5 looks like this: {{{ # We look in these directories DIRS="/usr /usr/local /usr/local/hdf5 /usr/local/packages/hdf5 /usr/local/apps/hdf5 /opt/local ${HOME} ${HOME}/hdf5 c:/packages/hdf5" # look into each directory for dir in $DIRS; do # libraries might have different file extensions for libext in a so dylib; do # libraries can be in /lib or /lib64 for libdir in lib64 lib; do # These files must exist FILES="include/hdf5.h $(for lib in ${HDF5_CXX_LIBS} ${HDF5_FORTRAN_LIBS} ${HDF5_C_LIBS}; do echo ${libdir}/lib${lib}.${libext}; done)" # assume this is the one and check all needed files HDF5_DIR="$dir" for file in $FILES; do # discard this directory if one file was not found if [ ! -r "$dir/$file" ]; then unset HDF5_DIR break fi done # don't look further if all files have been found if [ -n "$HDF5_DIR" ]; then break fi done # don't look further if all files have been found if [ -n "$HDF5_DIR" ]; then break fi done # don't look further if all files have been found if [ -n "$HDF5_DIR" ]; then break fi done }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1598> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac November 2014