Trac July 2015

trac@lists.einsteintoolkit.org

1 participants
107 discussions

[Einstein Toolkit] #1779: hwloc-utils fails due to missing hwloc-assemlber (and possibly others)
by Einstein Toolkit 27 Jul '15

27 Jul '15

#1779: hwloc-utils fails due to missing hwloc-assemlber (and possibly others) -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: ET_2015_11 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- Currently, make sim-utils fails for me: {{{ make[1]: *** No rule to make target '/home/knarf/ET_dev/exe/sim/hwloc- assembler', needed by 'utils'. Stop. Makefile:870: recipe for target 'sim-utils' failed }}} Indeed, I don't have the tool hwloc-assembler installed, although I do have the hwloc library installed, and it is picked up by the hwloc thorn, and Cactus succeeds in building the executable. In fact, no binary is installed with the standard hwloc library package, there is another package for the utilities. As long as we don't need these utilities I suggest to not depend on them. The following patch follows the example of PAPI and only installs known tools that are actually present in the installation. {{{ Index: make.configuration.defn =================================================================== --- make.configuration.defn (revision 66) +++ make.configuration.defn (working copy) @@ -1,4 +1,5 @@ # make.configuration.defn file for thorn hwloc # Define the hwloc utilities -ALL_UTILS += hwloc-assembler hwloc-assembler-remote hwloc-bind hwloc-calc hwloc-distances hwloc-distrib hwloc-info hwloc-ls hwloc-ps lstopo lstopo- no-graphics +STD_HWLOC_UTILS = hwloc-assembler hwloc-assembler-remote hwloc-bind hwloc-calc hwloc-distances hwloc-distrib hwloc-info hwloc-ls hwloc-ps lstopo lstopo-no-graphics +ALL_UTILS += $(filter $(STD_HWLOC_UTILS), $(notdir $(wildcard $(HWLOC_DIR)/bin/*))) }}} We might even think about backporting this change. I would support this, but would not go ahead without at least one other maintainer approving. Obviously after testing... -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1779> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1787: Generalize fallback definition of C++11 static_assert
by Einstein Toolkit 27 Jul '15

27 Jul '15

#1787: Generalize fallback definition of C++11 static_assert -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- See <https://bitbucket.org/cactuscode/cactus/pull-request/14/cactus- generalize-fallback-definition-of-c/diff>. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1787> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1780: Correct name of Weinberg pseudotensor in QuasiLocalMeasures
by Einstein Toolkit 24 Jul '15

24 Jul '15

#1780: Correct name of Weinberg pseudotensor in QuasiLocalMeasures ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: | ----------------------+----------------------------------------------------- Vassilios Mewes says: [...] the Landau-Lifshitz quantities implemented in the QLM thorn, are not actually using the Landau-Lifshitz pseudotensor, but rather the Weinberg's pseudotensor, which he derived in his book General Relativity, Gravitation and Cosmology. I think it would be good to rename them accordingly, as it (at least for me) caused some confusion when investigating those quantities. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1780> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1637: MoL should automatically allocate storage for sufficient timelevels of evolved variables
by Einstein Toolkit 24 Jul '15

24 Jul '15

#1637: MoL should automatically allocate storage for sufficient timelevels of evolved variables -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: MoL | -------------------------+-------------------------------------------------- The MoL thorn requires that all evolved variables have at least two timelevels of data, even if the integration method (e.g. RK4) does not need any past timelevels. It uses one of these timelevels as scratch space, potentially in addition to any other scratch space variables. In the case where at least two timelevels are needed for other reasons, this is more efficient than allocating an extra scratch space variable. Rather than requiring the evolution thorn to allocate at least two timelevels of storage for these variables, MoL should ensure sufficient timelevels via the flesh API. A related issue is that using timelevels for this purpose is wasteful in situations where the timelevel is not used for any other purpose, since the timelevel will be checkpointed even though it is only being used for temporary storage. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1637> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1792: Pthreads: don't use PTHREADS_DIR to guess PTHREADS_INC_DIRS if PTHREADS_DIR is NO_BUILD
by Einstein Toolkit 23 Jul '15

23 Jul '15

#1792: Pthreads: don't use PTHREADS_DIR to guess PTHREADS_INC_DIRS if PTHREADS_DIR is NO_BUILD --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | --------------------+------------------------------------------------------- this leads to inlcude dirs of the form NO_BUILD/include which makes no sense. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1792> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1786: Switch to C99 semantics for "inline" keyword
by Einstein Toolkit 20 Jul '15

20 Jul '15

#1786: Switch to C99 semantics for "inline" keyword -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- See <https://bitbucket.org/cactuscode/cactus/pull-request/13/switch-to-c99 -semantics-for-inline-keyword>. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1786> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1793: activating 3d output at restart results in unexpected behavior
by Einstein Toolkit 03 Jul '15

03 Jul '15

#1793: activating 3d output at restart results in unexpected behavior --------------------------------+------------------------------------------- Reporter: physik@… | Owner: eschnett Type: defect | Status: new Priority: unset | Milestone: Component: Carpet | Version: ET_2014_05 Keywords: | --------------------------------+------------------------------------------- Hi, I've recently switched on 3D carpetIOHDF5 output when restarting from a checkpoint which was not a multiple of carpetiohdf5::out_every, which in turn corresponds to a multiple of the coarsest timestep. In the resulting files, all but the finest levels where missing. I realized that instead of Carpetiohdf5::out_criterion = divisor I have used Carpetiohdf5::out3D_criterion = divisor A quick grep in the source code resulted in no match for the latter parameter, it seems completely unused. Thus, Carpet was probably using the default for out_criterion, which is "default", which means use IO:out3D_criterion, which was not set, defaulting to "iteration". Now, according to this closed issue https://trac.einsteintoolkit.org/ticket/1053 that should still work as intended. I suppose the problem here is that the 3d output was not activated in previous restarts, so there was no last output time when restarting, and it outputs every so many iterations after the checkpoint. This occurred with the Wheeler release, I have not checked the newest release yet. Cheers, Wolfgang. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1793> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac July 2015