#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
#1771: Improve performance of CarpetInterp2 interpolation
-------------------------+--------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Carpet | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
The branch
https://bitbucket.org/eschnett/carpet/branch/ianhinder/fasterp_opt#diff
contains an optimisation to the CarpetInterp2 interpolation routine which
improved the performance of Llama interpatch interpolation in my test by a
factor of 5. I did this a while ago, and haven't looked at it recently.
Before merging, the following should be done:
1. Check that is applies cleanly to the current version of Carpet
2. Decide whether the vectorisation pragmas need to be protected by Cactus
preprocessor guards
Or any other changes which people think might be necessary.
This should wait until after the upcoming (May 2015) release of the ET.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1771>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1743: Reduce number of output files per directory
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: unset | Milestone:
Component: Other | Version: development version
Keywords: |
----------------------+-----------------------------------------------------
Reduce the number of output files per directory in CarpetIOHDF5 by
creating a hierarchy of subdirectories.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1743>
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
#1717: hwloc: lnuma & lltdl *really* required?
-----------------------------------+----------------------------------------
Reporter: zachetie@… | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
I downloaded the ET devel version (ca. Nov 26) on my (ubuntu) laptop and
compiled it, using gcc.
I compiled to the linker stage, and the linker complained:
ld: cannot find -lnuma
ld: cannot find -lltdl
I found references to these libraries in:
configs/[buildname]/bindings/Configuration/Capabilities/make.HWLOC.defn
After removing these references, the code compiled and seemed (on the
surface) to run okay. Are these libraries really necessary?
I ask because every time I need to install ET on a new machine, it would
be more convenient if the step "apt-get install libnuma-dev libltdl-dev"
were left out, particularly since reliable Internet access may not exist
at that time.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1717>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1656: CarpetInterp and MoL do not work properly together
--------------------+-------------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: Carpet | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
I am trying to integrate interpolated quantities using MoL. I call the
interpolator in MoL_CalcRHS, and want it to perform only a spatial
interpolation of the current content of timelevel 0. This current content
is what has been set by MoL; it is not the final value that will be at
t_{n+1} or was at t_N, but is the intermediate value that should be used
when computing the RHS at a given MoL substep. Since MoL does not set the
Carpet time hierarchy values, CarpetInterp seems to get confused about how
to do the interpolation. I need to tell CarpetInterp not to interpolate
in time at all, but to use timelevel 0 only. Unfortunately, setting the
interpolator option to use only one timelevel does not work. There is
commented-out code to "use cctk_time to decide whether to interpolate",
which essentially guarantees that no time interpolation will happen (since
the interpolation is requested for cctk_time, and the current time is
cctk_time, so they are always equal). Re-enabling this code allowed me to
achieve 4th order convergence for integrated interpolated quantities,
though I am not sure I understand everything that is going on in
CarpetInterp. I have added a parameter which controls this, and with this
parameter set to the default, nothing changes (i.e. it is not going to
change anyone's results unless they set the parameter). I would like to
commit this, so that collaborators can work off the same version. Since
the patch is very small, I hope this will not add too much unneeded
complexity. Is it OK to commit? Patch is attached.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1656>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1791: Allow aligning the interior of grid functions in looping macros
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
Currently, when grid functions are aligned, Cactus expects their origin to
be aligned. These changes update the looping macros to allow aligning the
interior of grid functions instead.
Whether and how grid functions are aligned is still determined by the
driver -- this only makes it possible to still use the looping macros in
this case.
Implemented in <https://bitbucket.org/cactuscode/cactus/pull-request/16
/allow-aligning-the-interior-of-grid/diff> and
<https://bitbucket.org/cactuscode/cactustest/pull-request/1/allow-
aligning-the-interior-of-grid/diff>.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1791>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit