Trac April 2012

trac@lists.einsteintoolkit.org

1 participants
196 discussions

[Einstein Toolkit] #64: Refactory/redesign archiving
by Einstein Toolkit 29 Aug '17

29 Aug '17

#64: Refactory/redesign archiving ------------------------+--------------------------------------------------- Reporter: mthomas | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- Implement archiving using archive machines with an iomethod key. Provide another key like rsync-excludes for people to exclude files from being archived. Provide a lightweight archive-like method for copying a simulation from one machine to another machine. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/64> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #583: PITTNullCode lacks test case outputs
by Einstein Toolkit 13 Jun '17

13 Jun '17

#583: PITTNullCode lacks test case outputs -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The PITTNullCode arrangement has several test parameter files without associated output. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/583> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #614: relative tolerence in test.ccl of QuasiLocalMeasures very high
by Einstein Toolkit 12 Apr '17

12 Apr '17

#614: relative tolerence in test.ccl of QuasiLocalMeasures very high -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- LSUThorns/QuasiLocalMeasures/test/test.ccl curerntly reads: {{{ ABSTOL 1.e-7 RELTOL 1.e+5 }}} I am curious: is the relative tolerance of 10,000 intentional or should it have been 1e-5 instead? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/614> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #394: Testsuite log file should contain more information
by Einstein Toolkit 12 Dec '16

12 Dec '16

#394: Testsuite log file should contain more information -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: testsuites | -------------------------+-------------------------------------------------- It is useful to look at the testsuite log file for information about how the tests were run. For example, which compiler was used, and with what compiler options. We need to balance this against providing information which will always change, making diffs hard to read. The most extreme case would be to output all make variables. Maybe better would be to output CC, CFLAGS, CXX, etc. Another option would be to parse these and say "intel compiler", "gcc", "pgi" etc. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/394> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

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

[Einstein Toolkit] #702: Tests should use IO::out_fileinfo = "none"
by Einstein Toolkit 18 Apr '16

18 Apr '16

#702: Tests should use IO::out_fileinfo = "none" -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- The Cactus User Guide (http://einsteintoolkit.org/documentation/UsersGuide/UsersGuidech9.html#x13-…) recommends that test output files should always be the same, and hence use IO::out_fileinfo = "none". I would like to implement this for the tests in the ET, as it makes comparing test output using standard (non-Cactus testsuite mechanism) diff tools possible. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/702> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #706: External Library Support
by Einstein Toolkit 12 Nov '15

12 Nov '15

#706: External Library Support -------------------------+-------------------------------------------------- Reporter: sbrandt | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Cactus_4.1.0 Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- We should remove support for all external library support that's wired into the flesh (except maybe MPI) in favor of the newer more generic mechanism. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/706> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #641: Parameter files and thornlists could be tested as part of the release process
by Einstein Toolkit 11 Nov '15

11 Nov '15

#641: Parameter files and thornlists could be tested as part of the release process -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: ET_2012_05 Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- There are a number of parameter files and thornlists included as examples with thorns in the ET, and in Cactus. Would it be feasible to have these tested as part of the release process? For example, they should run without crashing or missing thorns, should not trigger NaNs etc, and we should minimise any warnings that are emitted. It would be nice to automate this, though it probably requires a cluster, so would be distinct from the usual test suite procedure, due to requiring more memory than tests. Something to think about for the next release. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/641> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #697: Repository and thorn names cannot be different
by Einstein Toolkit 10 Nov '15

10 Nov '15

#697: Repository and thorn names cannot be different ---------------------------+------------------------------------------------ Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: critical | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ I am accessing some thorns stored in git repositories at bitbucket.org, which insists that all repository names are all lower case. I don't know how to specify this in GetComponents. When I say !TARGET = $ARR !TYPE = git !URL = git@bitbucket.org:user/thorn.git !AUTH_URL = git@bitbucket.org:user/thorn.git !CHECKOUT = Arrangement/Thorn then GetComponents does not create a symbolic link from Thorn to ../../repos/thorn, but to ../../repos/thorn/Arrangement/Thorn instead. How do I avoid this? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/697> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac April 2012