Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #2034: CarpetLib's defs.hh and defs.cc file don't encapsulate defintions in a namespace
by Einstein Toolkit 25 Apr '17

25 Apr '17

#2034: CarpetLib's defs.hh and defs.cc file don't encapsulate defintions in a namespace --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- CarpetLib's defs.hh and defs.cc do not (as far as I can tell) contain any namespace enclosing the defined functions so that they all end up in the global namespace eg its ipow and also its get_poison_value function. It should however either put them into a CarpetLib namespace or prefix them by CarpetLib_ like other symbols with global linkage. This apparently has always been the case at least far back as importing carpet-5 into git (5 years ago). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2034> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #2033: BBH gallery page has missing images
by Einstein Toolkit 24 Apr '17

24 Apr '17

#2033: BBH gallery page has missing images -------------------------------------+-------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: development version Keywords: | -------------------------------------+-------------------------------------- The BBH gallery page (http://einsteintoolkit.org/gallery/bbh/index.html) on the new website has two images (hright.jpg and Strain_sm.png) missing. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2033> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #2031: Option to disable Piraha
by Einstein Toolkit 24 Apr '17

24 Apr '17

#2031: Option to disable Piraha ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | ---------------------+------------------------------------------------------ On the 4/24/2017 it was discussed whether we should have both Piraha and the old parser in the new release. It was decided that it should be possible to disable Piraha, otherwise doing it twice provdes little benefit. Therefore, it should be possible to disable Piraha. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2031> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #2028: ADMConstraints param.ccl fails to parse
by Einstein Toolkit 21 Apr '17

21 Apr '17

#2028: ADMConstraints param.ccl fails to parse ----------------------+----------------------------------------------------- Reporter: hinder | Owner: Type: task | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- arrangements/EinsteinAnalysis/ADMConstraints/param.ccl fails to parse with the new parser, giving the error {{{ CST ERROR IN FILE '/home/ianhin/Cactus/EinsteinToolkitGit/arrangements/EinsteinAnalysis/ADMConstraints/param.ccl' ERROR ON LINE 70: string excision_mask_name "The name of the bitfield chosen for excision" { :: "Anything goes" ^ | here FOUND CHARACTER: ':' EXPECTED CHARACTER(S): DOUBLE_QUOTE, 'A' to 'Z', '\', '_', 'a' to 'z', '}' Parse Error at /home/ianhin/Cactus/EinsteinToolkitGit/lib/sbin/parameter_parser.pl line 51. main::create_parameter_database('TwoPunctures', '/home/ianhin/Cactus/EinsteinToolkitGit/arrangements/EinsteinI...', 'pciutils', '/home/ianhin/Cactus/EinsteinToolkitGit/arrangements/ExternalL...', 'CoordBase', '/home/ianhin/Cactus/EinsteinToolkitGit/arrangements/CactusBas...', 'ADMConstraints', '/home/ianhin/Cactus/EinsteinToolkitGit/arrangements/EinsteinA...', 'OpenBLAS', ...) called at /home/ianhin/Cactus/EinsteinToolkitGit/lib/sbin/CST line 142 make[1]: *** [/home/ianhin/Cactus/EinsteinToolkitGit/configs/gw150914 /config-data/make.thornlist] Error 255 make: *** [gw150914] Error 2 }}} I'm pretty sure this violates the description of the allowed values for "parameter values" in http://einsteintoolkit.org/usersguide/UsersGuidech12.html#x17-191000D2.3. I have corrected the param.ccl file. I am mentioning it here in case anyone thinks that the parser should be extended to support this incorrect usage, since it was accepted by the previous version. I don't think that this is worth doing. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2028> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1916: GetComponents checks out git repositories serially
by Einstein Toolkit 12 Apr '17

12 Apr '17

#1916: GetComponents checks out git repositories serially ---------------------------+------------------------------------------------ Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2016_11 Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ When called with --parallel, GetComponents still checks out git repositories serially. This may have been introduced with #83, but there is no information in that ticket about what was done. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1916> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[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] #2024: Commits to the CTThorns repository do not get reported to the ET commits mailing list
by Einstein Toolkit 18 Mar '17

18 Mar '17

#2024: Commits to the CTThorns repository do not get reported to the ET commits mailing list -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Server Infrastructure | Version: development version Keywords: | -----------------------------------+---------------------------------------- Commits to the CTThorns repository do not get reported to the ET commits mailing list. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2024> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #2000: support radial boundary conidtion with Llama in NewRad
by Einstein Toolkit 17 Mar '17

17 Mar '17

#2000: support radial boundary conidtion with Llama in NewRad -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: NewRad | -----------------------------------+---------------------------------------- This implements the radially outgoing boundary condition on Llama's spherical grid. I (Roland) checked that the expressions agree with what CTGamma implements in its CTGRadiativeBC/src/calc_rhs.h, Ian checked that the physics makes sense. To use the this the user needs to set the parameter z_is_radial explicitly rather than in CTGamma where CTGRadiativeBC decides this on its own based on its knowledge of Llama's coordinate systems. If one really wanted to risk being clever one could likely try and auto-detect this like so: {{{ z_is_radial = (r[CCTK_GFINDEX3D(cctkGH, 0,0,1)] != r[CCTK_GFINDEX3D(cctkGH, 0,0,0)]) && (r[CCTK_GFINDEX3D(cctkGH, 0,1,0)] == r[CCTK_GFINDEX3D(cctkGH, 0,0,0)]) && (r[CCTK_GFINDEX3D(cctkGH, 1,0,0)] == r[CCTK_GFINDEX3D(cctkGH, 0,0,0)]); }}} though this is obviously not fully safe as it only tests at a single point. Pull request is here: https://bitbucket.org/einsteintoolkit/einsteinevolve /pull-requests/9/newrad-add-simple-support-for-llama-outer/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2000> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac