Trac March 2017

trac@lists.einsteintoolkit.org

1 participants
100 discussions

[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] #1875: SetMask_SphericalSurface: retain mask
by Einstein Toolkit 19 May '17

19 May '17

#1875: SetMask_SphericalSurface: retain mask ------------------------------------+--------------------------------------- Reporter: cott@… | Owner: Type: enhancement | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | ------------------------------------+--------------------------------------- SetMask_SphericalSurface sets a mask based on SphericalSurface information. At every invocation, it wipes the mask, then resets it. Old behavior: mask is set from surface only if surface is active and valid. However, sometimes finding a horizon with AHFinderDirect may fail, but the mask info (i.e. the radius) may be perfectly valid. Mask is still not set in the old behavior, because AHFinderDirect makes the mask invalid (-1) if it does not find a horizon. New behavior: set mask from surface is surface is active and its minimum radius is > 0. Pull request: https://bitbucket.org/einsteintoolkit/einsteinutils/pull- requests/1/setmask_sphericalsurface-retain-mask/diff Pull request also adds verbose output (default: off). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1875> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[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] #2003: piraha_everywhere Zelmani stress test
by Einstein Toolkit 10 May '17

10 May '17

#2003: piraha_everywhere Zelmani stress test --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: piraha | --------------------+------------------------------------------------------- Hello all, Zelmani contains a number of ccl files that make the perl based piraha parser abort with errors but that parsed fine with the old parrser. Some ccl files are clearly incorrect while others are correct and the parser should accept them. The major such issue is that the parser requires that that there is a private/public/protected setting at the beginning of a param.ccl which is not required by the docs since parameters are supposed to default to private. I attach all ccl files both in their original version as well as version that can be parsed without errors (hopefully). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2003> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 43

[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

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac March 2017