Trac February 2015

trac@lists.einsteintoolkit.org

1 participants
109 discussions

[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] #1674: Switch to OpenBLAS
by Einstein Toolkit 02 Jun '17

02 Jun '17

#1674: Switch to OpenBLAS -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- OpenBLAS is a BLAS and LAPACK library that is significantly more efficient that the standard ("reference") BLAS. I suggest we switch the ET thorn list to ExternalLibraries/OpenBLAS instead of ExternalLibraries/BLAS and ExternalLibraris/LAPACK. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1674> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 22

[Einstein Toolkit] #1390: parameter file parser aborts when findeing first error
by Einstein Toolkit 19 May '17

19 May '17

#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

1 10

[Einstein Toolkit] #1172: Remove unnecessary exp/log calls in EOS_Omni
by Einstein Toolkit 18 May '17

18 May '17

#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

1 2

[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] #1276: Intel 2013.1.117 mis-compiles NewRad
by Einstein Toolkit 16 Mar '17

16 Mar '17

#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

1 54

[Einstein Toolkit] #1439: SSL certificate check failing
by Einstein Toolkit 16 Mar '17

16 Mar '17

#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

1 5

[Einstein Toolkit] #1743: Reduce number of output files per directory
by Einstein Toolkit 16 Jan '17

16 Jan '17

#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

1 23

[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] #1717: hwloc: lnuma & lltdl *really* required?
by Einstein Toolkit 06 Dec '16

06 Dec '16

#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

1 35

← Newer
1
2
3
4
5
6
7
8
...
11
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac February 2015