Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1904: HDF5-related tests fail on OS X with HDF5 1.10.0
by Einstein Toolkit 30 May '16

30 May '16

#1904: HDF5-related tests fail on OS X with HDF5 1.10.0 ----------------------+----------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: critical | Milestone: ET_2016_05 Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- I have run the ET tests on OS X. There are 5 failures (https://build.barrywardell.net/view/EinsteinToolkitMulti/job /EinsteinToolkitMulti- sandbox/MACHINE=osx-10.9.5-macports,label=master/1430/testReport/): IOHDF5.test_recover/1procs SphericalHarmonicReconGen.SpEC-h5-test/1procs CT_MultiLevel.boostedpuncture/2procs IOHDF5.test_recover/2procs SphericalHarmonicReconGen.SpEC-h5-test/2procs Several of the test failures seem to be related to HDF5 (see the output pages from the link above). For example, I get these warnings: HDF5-DIAG: Error detected in HDF5 (1.10.0) thread 0: #000: H5Dio.c line 170 in H5Dread(): can't read data major: Dataset minor: Read failed #001: H5Dio.c line 418 in H5D__read(): unable to set up type info major: Dataset minor: Unable to initialize object #002: H5Dio.c line 953 in H5D__typeinfo_init(): not a datatype major: Invalid arguments to routine minor: Inappropriate type WARNING[L1,P0] (IOHDF5Util): HDF5 call 'H5Dread (dataset, rec_info->hdf5type, H5S_ALL, H5S_ALL, H5P_DEFAULT, data)' returned error code -1 and the diffs say phi.xl: substantial differences significant differences on 165 (out of 165) lines maximum absolute difference in column 2 is 1.4849088247045 maximum relative difference in column 2 is 3.18869248642747 for example, in IOHDF5.test_recover/1procs. This might be because MacPorts is now using HDF5 1.10.0, and I don't know how much this has been tested with Cactus. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1904> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1903: McLachlan is missing documentation
by Einstein Toolkit 30 May '16

30 May '16

#1903: McLachlan is missing documentation -------------------------------------+-------------------------------------- Reporter: anonymous | Owner: Type: defect | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: McLachlan documentation | -------------------------------------+-------------------------------------- There seem to be no documentation (e.g. describing the available gauges) in the McLachlan arrangement. In particular, there is no documentation on the webpage: https://einsteintoolkit.org/documentation/ThornDoc/ and the command make ArrangementDoc does not produce a documentation file for McLachlan. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1903> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1850: Severe performance problem on Stampede
by Einstein Toolkit 29 May '16

29 May '16

#1850: Severe performance problem on Stampede ------------------------+--------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- With the ET_2015_11 release, there is a severe performance problem on Stampede. This is when hwloc and SystemTopology are not activated. Activating these thorns causes simulations to run 8 times faster. This suggests that the affinity settings in simfactory for stampede are wrong. stampede-mvapich2.run has {{{ export KMP_AFFINITY=norespect,compact # verbose }}} Is this correct? Looking at the output of "top", we see the expected 16 threads, but each is running at only 50%. There is no migration between cores, as far as we can tell. This 50% should be 100%, and this doesn't explain the factor of 8 slowdown, but it shows that there is something wrong. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1850> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 35

[Einstein Toolkit] #1901: provde aliased functions to query if a reflevel is due for update
by Einstein Toolkit 27 May '16

27 May '16

#1901: provde aliased functions to query if a reflevel is due for update -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: optional | Milestone: Component: Carpet | Version: development version Keywords: | -------------------------+-------------------------------------------------- Carpet decides on whether a routine executes on a given reflevel at a given iteration by computing {{{cctk_iteration%do_every}}} or {{{(cctk_iteration-1)%do_every}}} depending on whether one is in EVOL or ANALYSIS. It would be good to provide helper functions for user thorns that do this computation taking the bin into account. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1901> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #960: Dissipation thorn schedules LOCAL routines after GLOBAL ones
by Einstein Toolkit 27 May '16

27 May '16

#960: Dissipation thorn schedules LOCAL routines after GLOBAL ones ----------------------------------------------+----------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: Dissipation and SphericalSurface | ----------------------------------------------+----------------------------- Dissipation currently contains a schedule item {{{ SCHEDULE setup_epsdis AT cctk_poststep after SphericalSurface_HasBeenSet { LANG: C SYNC: epsdisA_group } "Setup spatially varying dissipation" }}} However SphericalSurface_HasBeenSet is AFTER SphericalSurface_Set which is a GLOBAL routine. Since GLOBAL routines run last in POSTSTEP (which is in EVOL) the AFTER modifier is ignored for all but the last (finest) refinement level. This can lead to the wrong surface shape to be used by the local routines. It might actually make sense to teach the flesh about GLOBAL/LOCAL etc and refuse AFTER/BEFORE statements that span different modes. This of course depends on how much work this is and if we expect the dependency and task based scheduler to be finished soon and if there are legitimate uses for AFTER/BEFORE to span modes. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/960> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1851: HDF5 won't configure on Fedora
by Einstein Toolkit 27 May '16

27 May '16

#1851: HDF5 won't configure on Fedora ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | ---------------------+------------------------------------------------------ The problem is that there's no way to tell it the correct place to look for H5pubconf.h (which is /usr/include/mpich-x86_64). There is an HDF5_INC_DIRS variable, but it's not exposed through configuration.ccl. Even if it's added, it gets overwritten by set_make_vars. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1851> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 22

[Einstein Toolkit] #1894: EinsteinInitialData/TwoPunctures segfaults and miscalcs with SP, maybe DP too.
by Einstein Toolkit 26 May '16

26 May '16

#1894: EinsteinInitialData/TwoPunctures segfaults and miscalcs with SP, maybe DP too. --------------------------------+------------------------------------------- Reporter: koppel@… | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | --------------------------------+------------------------------------------- When using EinsteinInitialData/TwoPunctures with CCTK_REAL set to single- precision memory-access errors and incorrect results were encountered. The incorrect results could potentially affect double-precision code too. The memory access errors occur due to double* / CCTK_REAL* confusion. The incorrect results are due to rounding errors in PunctTaylorExpandAtArbitPosition that push an acos argument outside of [-1,1]. Though this was encountered with single-precision code, perhaps it could occur with DP code too. The attached patch fixes the type mismatch and clamps the acos argument to [-1,1]. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1894> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1880: AHFinderDirect fix on-off issue setting mask when not finding AH every single step
by Einstein Toolkit 25 May '16

25 May '16

#1880: AHFinderDirect fix on-off issue setting mask when not finding AH every single step -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: AHFinderDirect | -----------------------------------+---------------------------------------- when not finding the horizon every single step, the mask is wiped every other step due to interactions of the scheduler and AHFinderDirect storing when the horizon was last found. https://bitbucket.org/einsteintoolkit/einsteinanalysis/pull-requests/1 /fix-on-off-mask/diff Implements a fix for this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1880> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1899: Dissipation
by Einstein Toolkit 25 May '16

25 May '16

#1899: Dissipation -----------------------------------+---------------------------------------- Reporter: knarf | Owner: knarf Type: defect | Status: new Priority: minor | Milestone: ET_2016_05 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- outer_boundary_max_epsdis and ah_max_epsdis, when set to negative values, are supposed to turn the respective maximum off. Both have a negative default value (but also need another parameter to enable dissipation in the respective case). Both don't include a check for negative numbers, and do set the dissipation strength to -1 in those cases. This wasn't observed up until recently due to an incorrect scheduling of the AH routines (which both testsuites use), which masked the output as if no extra dissipation was applied. The fix is to include a check for the maximum being negative, and turning this 'capping' off. This does not only change the output of epsdis itself, as epsdis is now set differently, which causes substantial differences inside the horizon and at the outer boundary. This fix, however, would produce too large values for dissipation with the current parameter files, and the affected parameters are really expected to be set when using these location-dependent dissipation variants. Thus, the testsuites have been adjusted to actually do set a maximum in both cases, now producing different results. Both changes are being prepared for a push. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1899> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1898: Testsuites in QuasiLocalMeasures failing
by Einstein Toolkit 25 May '16

25 May '16

#1898: Testsuites in QuasiLocalMeasures failing -----------------------------------+---------------------------------------- Reporter: knarf | Owner: knarf Type: defect | Status: new Priority: major | Milestone: ET_2016_05 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- At the time of writing, the issue has been fixed. However, I open (and close) this ticket to have some place to save information about it, in case it is of use later. Recently, QuasiLocalMeasures showed its testsuites failing on 2 processes. The problem, as it turns out, was that the output was generated not independent of the number of processes. This is the log from the commit that now fixes the immediate problem: (https://bitbucket.org/einsteintoolkit/einsteinanalysis/commits/76e24130c79d/) Change testsuites to use compact ASCII output and to not output information from within ghostzones. This makes the output independent from the number of processes, and allows the 2-process testsuites to succeed, even with the output generated using 1 process. The testsuites did succeed before this change, but only on one process. They did fail on more than one, due to completely different output format then. However, the testsuite mechanism didn't pick up this failure until only lately, due to multiple factors. One was (and still is) that Cactus has issues detecting errors when values are zero, due to relative errors being non-trivial to define. Ticket #1889 is about that. The other issue was that, while those lines were skipped, the different length of the output files was not detected until a fix for that was introduced recently, uncovering the problem here. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1898> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac