Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1059: simfactory silent error
by Einstein Toolkit 13 Aug '15

13 Aug '15

#1059: simfactory silent error --------------------------------------+------------------------------------- Reporter: anonymous | Owner: eschnett Type: enhancement | Status: new Priority: optional | Milestone: Component: SimFactory | Version: Keywords: simfactory error message | --------------------------------------+------------------------------------- When sim submit -remote ... fails to queue a job because the allocation has been overdrawn, simfactory does not print any error message to screen (it is only hidden in the log file). Could it be made to print an error message to screen? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1059> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #959: Move pthreads to ExternalLibraries
by Einstein Toolkit 13 Aug '15

13 Aug '15

#959: Move pthreads to ExternalLibraries -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- We should move pthreads support to ExternalLibraries (or to the flesh). I have asked CCT to create the respective repository. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/959> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

[Einstein Toolkit] #1579: GRHydro does not build on Blue Gene/Q
by Einstein Toolkit 09 Aug '15

09 Aug '15

#1579: GRHydro does not build on Blue Gene/Q ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: development version Keywords: | ----------------------+----------------------------------------------------- Some of the C++ source files in GRHydro do not build on a Blue Gene/Q with IBM's compiler. The problem is that the compiler takes a very long time (>8h) even without (sic!) optimization. "The usual" playing with compiler options or changes to the source files had no effect. I consider this to be a bug in the compiler. A work-around may be to switch to Clang as C++ compiler. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1579> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1797: allow new timelevels to be created at runtime
by Einstein Toolkit 09 Aug '15

09 Aug '15

#1797: allow new timelevels to be created at runtime --------------------------------+------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: Cactus Carpet PUGH | --------------------------------+------------------------------------------- The set of patches in https://bitbucket.org/cactuscode/cactus/branch/rhaas%2FunlimitedTimelevels https://bitbucket.org/cactuscode/cactuspugh/branch/rhaas%2FunlimitedTimelev… https://bitbucket.org/eschnett/carpet/branch/rhaas%2FunlimitedTimelevels extend the flesh and the PUGH and Carpet drivers such that user thorns can enable more timelevels than the TIMELEVELS attribute in interface.ccl specifies. This separates the number of {{{_p}}} and {{{_p_p}}} etc. variables, which continues to be controlled by interface.ccl's TIMELEVELS attribute, from the number of timelevels that are accessible via {{{CCTK_VarDataPtr()}}}. This means that evolution thorns can ask for only ask many timelevels as they need for their own evolution algorithm (so 2 of MoL based thorns) and don't have to worry about how many timelevels Carpet may require for time interpolation. Similarly some MoL evolution methods (for example AB type methods) require multiple past timelevels of the RHS variables which MoL can enable by its own when using this functionality. Their should be very little user visible changes, mostly since few thorns actually needed to know the number of timelevels. The exisiting flesh functions {{{CCTK_MaxTimeLevels}}} continue to return the value set in TIMELEVELS while new functions {{{CCTK_MaxActiveTimeLevels}}} return the maximum number of timelevels that were ever activated or {{{CCTK_MaxTimeLevels}}}, whichever is larger. A possible improvement would be to make the existing {{{CCTK_MaxTimeLevels}}} return what {{{CCTK_MaxActiveTimeLevels}}}, yet no user code should ever need knowledge of {{{CCTK_MaxTimeLevels}}} anyway since it only ever returned the value set in {{{interface.ccl}}} so only drivers etc. should have used it to check for invalid timelevel parameters. The downside of that approach is that it changes the meaning of an existing flesh function rather than introducing a new one and deprecating the old one. This is fine if the meaning of {{{CCTK_MaxTimeLevels}}} really is "upper bound on {{{CCTK_ActiveTimeLevels}}} that could have been seen" rather than "the value of TIMELEVELS from interface.ccl". The patches pass all tests. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1797> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #816: include SphericalHarmonicReconASCII from incoming in PITTNULLCode
by Einstein Toolkit 04 Aug '15

04 Aug '15

#816: include SphericalHarmonicReconASCII from incoming in PITTNULLCode -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Christian Reisswig provided a copy of SphericalHarmonicReconASCII and alternative thorn that reads in CCE boundary data (similar SphericalHarmonicRecon) but supporting a wider variety of input file formats (HDF5 among them, irrespective of the name). Used by SpEC and Llama. There are no docs or test cases as of now. Test data would be welcome (SpEC, Llama or Cactus provided, I don't think it makes a difference). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/816> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 17

[Einstein Toolkit] #1799: Missing braces in test.ccl make Cactus tests hang
by Einstein Toolkit 03 Aug '15

03 Aug '15

#1799: Missing braces in test.ccl make Cactus tests hang ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- This file {{{ TEST kasner { NPROCS 2 } TEST kasner_amr { NPROCS 2 } TEST no-overlap { NPROCS 2 } TEST outer-buffers { NPROCS 1 } TEST overlap { NPROCS 2 } TEST 64k2 }}} makes the Cactus test suite mechanism hang. I believe the problem is that {{{ParseTestBlock}}} does not handle the case of missing braces well. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1799> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1798: add backtrace script to cactus utils
by Einstein Toolkit 28 Jul '15

28 Jul '15

#1798: add backtrace script to cactus utils -------------------------+-------------------------------------------------- Reporter: sbrandt | Owner: Type: enhancement | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- The script converts backtraces generated by carpet to readable output with file and line number. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1798> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac