Trac November 2016

trac@lists.einsteintoolkit.org

1 participants
108 discussions

[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] #1985: GetCOmponents does not follow HTTP redirection when downloading via curl
by Einstein Toolkit 15 Mar '17

15 Mar '17

#1985: GetCOmponents does not follow HTTP redirection when downloading via curl ---------------------------+------------------------------------------------ Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ The pull request: https://github.com/gridaphobe/CRL/pull/3 adds {{{--location}}} to curl calls to make curl follow redirects. wget follows the redirect without further options. The branch also contains two cleanup commits that remove unused code. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1985> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1983: Multipole: ouput all hdf5 modes at once
by Einstein Toolkit 15 Mar '17

15 Mar '17

#1983: Multipole: ouput all hdf5 modes at once -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: Multipole | -----------------------------------+---------------------------------------- This change reduces the number of times the same file is opened and closed from once per mode and radius to once per output iteration. This is very beneficial on clusters with slow metadata performance (which currently means all "big" clusters that run lustre). Pull request is: https://bitbucket.org/einsteintoolkit/einsteinanalysis/pull-requests/5 /multipole-ouput-all-hdf5-modes-at-once/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1983> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1771: Improve performance of CarpetInterp2 interpolation
by Einstein Toolkit 06 Mar '17

06 Mar '17

#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

1 5

[Einstein Toolkit] #1801: Certificate for svn.cct.lsu.edu not trusted
by Einstein Toolkit 15 Feb '17

15 Feb '17

#1801: Certificate for svn.cct.lsu.edu not trusted --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | --------------------+------------------------------------------------------- I just tried to check out the ET Hilbert release on my OSX laptop (OSX 10.10.4, subversion version 1.7.19) and get for the LSUThorns: --8<-- Could not checkout module LSUThorns/SummationByParts svn: E175002: Unable to connect to a repository at URL 'https://svn.cct.lsu.edu/repos/numrel/LSUThorns/SummationByParts/branches/ET…' svn: E175002: OPTIONS of 'https://svn.cct.lsu.edu/repos/numrel/LSUThorns/SummationByParts/branches/ET…': Server certificate verification failed: issuer is not trusted (https://svn.cct.lsu.edu) --8<-- https://www.sslshopper.com/ssl- checker.html#hostname=https://svn.cct.lsu.edu reports the certificate to be ok though (with the exception of it using SHA1 as a hash). Doing a manual svn checkout https://svn.cct.lsu.edu/repos/numrel/LSUThorns/QuasiLocalMeasures/branches/… asks me whether I would want to trust the certificate. 1. I thought the LSU certificates were trusted by common OS by default by now (and OSX is certainly common) 2. I thought we had special code in GetComponents to make it automatically not try and verify signatures because of this 3. this is really becoming a nuisance (if indeed caused by an uncommon certificate issuer and not by something odd on my laptop) :-) {{{ openssl ssl_client -connect svn.cct.lsu.edu:443 </dev/null >ssl.out }}} reports a self-signed certficate though this may well be the untrusted certificate. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1801> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 40

[Einstein Toolkit] #1939: Cactus: Add CCTK_VINFO, CCTK_VERROR, CCTK_VWARN
by Einstein Toolkit 08 Feb '17

08 Feb '17

#1939: Cactus: Add CCTK_VINFO, CCTK_VERROR, CCTK_VWARN -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: unset | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- See <https://bitbucket.org/cactuscode/cactus/pull-requests/30/cactus-add- cctk_vinfo-cctk_verror/diff>. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1939> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[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] #1819: CarpetMask: add option to exclude boxes
by Einstein Toolkit 16 Jan '17

16 Jan '17

#1819: CarpetMask: add option to exclude boxes -------------------------------------+-------------------------------------- Reporter: bmundim | Owner: eschnett Type: enhancement | Status: new Priority: unset | Milestone: Component: Carpet | Version: development version Keywords: CarpetMask CarpetReduce | -------------------------------------+-------------------------------------- I would like to be able to exclude boxes in addition to spherical surfaces when setting the CarpetMask::weight (which is used by CarpetReduce to exclude regions when performing reductions). The following pull request implements this functionality: {{{ https://bitbucket.org/eschnett/carpet/pull-requests/5/bcm-carpetmask/diff }}} I have some parameter files I used to test my implementation. I can turn them into testsuites after the revision of this ticket. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1819> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

← Newer
1
...
5
6
7
8
9
10
11
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac November 2016