Trac April 2016

trac@lists.einsteintoolkit.org

1 participants
107 discussions

[Einstein Toolkit] #382: SimFactory home directory on Kraken is too specific
by Einstein Toolkit 01 Jun '16

01 Jun '16

#382: SimFactory home directory on Kraken is too specific ------------------------+--------------------------------------------------- Reporter: hinder | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: ET_2011_05 Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- The mdb entry for Kraken in SimFactory has 'sourcebasedir' => '/nics/b/home/@USER@', My home directory is '/nics/d/home/@USER@' Either we could leave the source base dir as unset to force the user to set it, or we could automatically detect the location of the user's home directory (better). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/382> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 19

[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] #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] #912: Use CACTUS_CONFIGS_DIR in Formaline
by Einstein Toolkit 23 May '16

23 May '16

#912: Use CACTUS_CONFIGS_DIR in Formaline -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Formaline assumes that configurations are stored in a "configs" subdirectory of $CCTK_HOME. Use $CACTUS_CONFIGS_DIR instead. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/912> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1870: ET_2015_11_v0 of McLachlan does regenerate code for ca6fe74 "McLachlan_BSSN.m: Make evolveA steerable"
by Einstein Toolkit 19 May '16

19 May '16

#1870: ET_2015_11_v0 of McLachlan does regenerate code for ca6fe74 "McLachlan_BSSN.m: Make evolveA steerable" -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: McLachlan backport | -----------------------------------+---------------------------------------- the release branch claims to make ML_BSSN::evolveA steerable but fails to actually do so in the generated code. Commit 0b38cba1f9ee9fce3f1ed2543295266efb86107e of McLachlan fixes this on master. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1870> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1595: Is {{{*)}}} allowed as upper boundary for a parameter range?
by Einstein Toolkit 19 May '16

19 May '16

#1595: Is {{{*)}}} allowed as upper boundary for a parameter range? ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- I sometimes see these warnings when Cactus starts: {{{ WARNING[L1,P0] (Cactus): Invalid end of real-valued parameter range; range descriptor is "(0.0 : *)" (value is 1) }}} Presumably the warning depends on which thorns are active. This warning looks as if the syntax {{{*)}}} was accepted by the CST when parsing a param.ccl file, but was later not recognized by the flesh when checking a parameter value against this range. (The flesh uses HUGE_VAL as fallback, which happens to be correct in this case.) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1595> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 40

[Einstein Toolkit] #1872: test system does not detect extra lines in output files
by Einstein Toolkit 13 May '16

13 May '16

#1872: test system does not detect extra lines in output files -----------------------+---------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: critical | Milestone: ET_2016_11 Component: Cactus | Version: development version Keywords: testsuite | -----------------------+---------------------------------------------------- I accidentally removed some lines of output from the stored test suite data in git hash [https://bitbucket.org/eloisa/ctthorns/commits/79c5e0d32fb1e3d6b219d7b55211f… 79c5e0d32fb1e3d6b219d7b55211fa3c388f7268] of ctthorns in the files {{{CT_MultiLevel/test/constraints_spherical/*_norm_eqn?.asc}}}. Yet the test all passed. I have since restored the changed files. This I would consider quite serious since extra output lines should always cause the test to fail rather than being silently ignored. I am marking this as critical since it potentially renders the test suites useless when detecting changes. If we fell we can "document away" this then, it can be downgraded to "major". -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1872> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1842: clang-format options not valid for versions <=3.5
by Einstein Toolkit 08 May '16

08 May '16

#1842: clang-format options not valid for versions <=3.5 --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- The current .clang-format file is not valid for clang-format versions 3.5 and below. The attached patch would 'fix' this by removing key words not known in version 3.5, but still wouldn't work for versions below that. I do not suggest to apply the patch - it should just show that this is quite some number. Looking at the .clang-format file it seems that it does not use one of the pre-defined styles, but rather creates it's own (even if it is based on one given the comment in the file). I wonder if all of this is really necessary, or if we could not simply use one of the pre-defined styles, possibly with a few changes that work across clang-format versions. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1842> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #584: Use of uninitialized value in concatenation
by Einstein Toolkit 07 May '16

07 May '16

#584: Use of uninitialized value in concatenation ------------------------+--------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- After failing to check out a thornlist (the current einsteintoolkit.th) the automated build and test system re-runs GetComponents with --update. On 27-Sep-2011, this gave the error: {{{ Use of uninitialized value in concatenation (.) or string at ./GetComponents line 2514. }}} This line seems to be {{{ $url = "(".$component{"URL"}.")|(".$component{"AUTH_URL"}.")"; }}} Is the problem that SimFactory doesn't have an AUTH_URL? I'm attaching the log of the testsuite script. I don't know if the error is serious or not, since the checkout has already failed. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/584> 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 April 2016