#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
#984: SimFactory should store the optionlist used when building in the simulation
directory
------------------------+---------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
SimFactory should store the optionlist used in the simulation directory
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/984>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#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
#1390: parameter file parser aborts when findeing first error
--------------------+-------------------------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Cactus | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
The attached parfile contains multiple errors (one per line).
However the parameter file parser only reports the first one, then stops.
This makes verifying parfiles for correctness hard. It might be good to
defer aborting until the end of the file or until a larger number of
parsing errors were encountered.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1390>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1172: Remove unnecessary exp/log calls in EOS_Omni
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
EOS_Omni seems to call exp/log more often than necessary in the nuc_eos
table lookup routines. Use algebraic identities to remove them.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1172>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#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
#1276: Intel 2013.1.117 mis-compiles NewRad
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: NewRad |
-----------------------------------+----------------------------------------
Intels compiler fails (with -O2) to push values for bmin onto the stack in
lines 316 of newrad.cc and line 126 of extrap.cc. Adding printf's for bmin
perturbs the bug out of existence, but adding a printf of the address of
bmax and reveals that at the time extrap_kernel is call the integer just
before this address is still the initialization value of bmin[2] and not
the correct value.
The attached patch disables optimization for the two driver functions
affected (but not the actual kernel).
The patch is specific (via an #if) for this particular compiler and
version. What is the best way of handling this? Target any intel version
starting from the known failing one until we know of known good one? Or
starting from an older known good one (that would be intel 11 in my case).
Hopefully no similar bug is triggered by Carpet's use of the same idiom.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1276>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1439: SSL certificate check failing
--------------------+-------------------------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Other | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
The check for SSL certificates in line 535:
{{{#perl
# check for svn SSL problems
if ( $rec{"TYPE"} eq "svn" && defined $rec{"AUTH_URL"} ) {
my $base = $rec{"AUTH_URL"};
$base =~ s/(https\:\/\/[\w\.]+)\/(.*)$/$1/i;
unless ( defined $svn_servers{$base} ) {
my $ret = `$svn --non-interactive info $rec{AUTH_URL} 2>&1`;
if ( $ret =~ /Server certificate verification failed/ ) {
$svn_servers{$base} = 0;
}
else {
$svn_servers{$base} = 1;
}
}
}
}}}
is incorrect since eg for the ET manifest where
{{{
AUTH_URL=https://svn.einsteintoolkit.org/$1/trunk
}}}
the executed svn command is:
{{{
svn --non-interactive info https://svn.einsteintoolkit.org/$1/trunk 2>&1
}}}
which actually returns and error:
{{{
svn: E175002: Unable to connect to a repository at URL
'https://svn.einsteintoolkit.org/trunk'
svn: E175002: The OPTIONS request returned invalid XML in the response:
XML parse error at line 1: Extra content at the end of the document
(https://svn.einsteintoolkit.org/trunk)
}}}
but the code does not test for svn failures at all at this point.
The simplest fix would be to move the check further down where {{{$1}}}
has been replaced by an actual value, eg into the loop:
{{{
# we are splitting each group of components into individuals
# to check for existence. they will now be passed individually to
# the checkout/update subroutines. this will take up more memory,
# but it should make it easier if the user decides to add another
# component from the same repository later
my @checkouts = split( /\s+/m, $rec{"CHECKOUT"} );
foreach my $checkout (@checkouts) {
}}}
in line 565 which however causes the test to run for every single CHECKOUT
item.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1439>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#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
#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