Trac September 2014

trac@lists.einsteintoolkit.org

1 participants
133 discussions

[Einstein Toolkit] #1338: Rename Carpet output files
by Einstein Toolkit 25 Nov '14

25 Nov '14

#1338: Rename Carpet output files ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | ----------------------+----------------------------------------------------- Windows does not allow colons in file names. Output files produced by Carpet's should therefore not use colons. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1338> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 36

[Einstein Toolkit] #1537: Deprecate complex number functions
by Einstein Toolkit 25 Nov '14

25 Nov '14

#1537: Deprecate complex number functions -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: ET_2014_11 Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- The complex number functions in Cactus are not necessary any more since all languages (Fortran, C, C++) have built-in support that should rather be used. These functions should be marked "deprecated" in the documentation (but not removed). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1537> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1642: GRHydro should not depend on ADMMacros
by Einstein Toolkit 24 Nov '14

24 Nov '14

#1642: GRHydro should not depend on ADMMacros --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2014_11 Component: Other | Version: development version Keywords: | --------------------+------------------------------------------------------- At the moment GRHydro uses ADMMacros::spatial_order to decide about how to calculate the source terms. ADMMacros is deprecated. There should be another mechanism to do this, and the dependence should be removed. Note that even the C++ code uses this parameter. The simplest solution would probably be a GRHydro parameter, and this is what I suggest (sources_spatial_order). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1642> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1555: Simfactory: intel optionlists with rdynamic option
by Einstein Toolkit 10 Nov '14

10 Nov '14

#1555: Simfactory: intel optionlists with rdynamic option -------------------------+-------------------------------------------------- Reporter: bmundim | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: ET_2014_05 Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- Hi, While reviewing some options in my config file I noticed that the -rdynamic gcc option for the linker is applied also to the intel compiler option lists in symfactory. However there seems to have no such an option when using icc or icpc. Wouldn't be better then to pass this option as --export-dynamic directly to the linker ld instead? Maybe as follows: LDFLAGS = -Wl,--export-dynamic -Wl,-rpath,/path/to/whatever instead of LDFLAGS = -rdynamic -Wl,-rpath,/path/to/whatever Thanks, Bruno. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1555> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1490: ExternalLibraries/PAPI contains testsuite, but no data
by Einstein Toolkit 10 Nov '14

10 Nov '14

#1490: ExternalLibraries/PAPI contains testsuite, but no data -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: ET_2014_05 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- ExternalLibraries/PAPI contains testsuite, but no data. This means the testsuite mechanism (currently) will count it always as succeeding, which is not helpful. Also, it contains a README file which only says that this directory is empty - which is not only not helpful, but also wrong, given that there is this README inside.. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1490> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[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] #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 September 2014