Trac June 2012

trac@lists.einsteintoolkit.org

1 participants
175 discussions

[Einstein Toolkit] #900: GRHydro: do not use the Slopelimiter function
by Einstein Toolkit 05 Jun '12

05 Jun '12

#900: GRHydro: do not use the Slopelimiter function -----------------------------------+---------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: minor | Milestone: ET_2012_05 Component: EinsteinToolkit thorn | Version: Keywords: GRHydro slopelimiter | -----------------------------------+---------------------------------------- This patch was generated by Josh Faber in response to the discussion at http://lists.einsteintoolkit.org/pipermail/users/2012-January/001710.html but it wasn't ever applied. It essentially deprecates the use of slopelimiter function. In the future it should be completely removed from the code. At the moment it is only commented out. Ok to apply? it is a bug fix... -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/900> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #937: CCTK_RegexMatch does not return a distinguishable error condition when the regular expression is invalid
by Einstein Toolkit 04 Jun '12

04 Jun '12

#937: CCTK_RegexMatch does not return a distinguishable error condition when the regular expression is invalid --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- CCTK_RegexMatch right now returns 1 if the pattern matches the string and 0 if either the pattern does not match or could not be compiled via regcomp. It would be useful if user code could distinguish between these two cases. The attached patch changes the return value in the "does not compile" case to -1 and updates all source files that I could find that use it. Note that this patch changes behaviour of a routine. It used to return 0 for non-compiling patterns so thorns that test for C-like true would interpret invalid patterns as does-not-match, but will interpret the -1 return value as does-match. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/937> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #821: avoid allocting temp memory twice in EOS Omni
by Einstein Toolkit 04 Jun '12

04 Jun '12

#821: avoid allocting temp memory twice in EOS Omni -------------------+-------------------------------------------------------- Reporter: rhaas | Type: enhancement Status: new | Priority: minor Milestone: | Component: Other Version: | Keywords: -------------------+-------------------------------------------------------- instead of storing a copy of the data in the Fortran module store Fortran pointers. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/821> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #943: Redesign ADMBase
by Einstein Toolkit 02 Jun '12

02 Jun '12

#943: Redesign ADMBase -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- I believe it is time to redesign ADMBase. The interface it offers has accumulated certain features that are all but unused today. Thorns such as ADMCoupling, ADMMacros, CoordGauge, StaticConformal should be removed. The scheduling interaction with the prestep and analysis bins and with MoL should be cleaned up. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/943> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #939: NullEvol_InitialData.F90 triggers Fortran exception
by Einstein Toolkit 01 Jun '12

01 Jun '12

#939: NullEvol_InitialData.F90 triggers Fortran exception -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: NullEvolve | -----------------------------------+---------------------------------------- I ran the SphericalHarmonicReconn testsuite (regression_test.par) with a Lovelace executable compiled via simfactory build --debug and get Fortran out-of bounds exceptions from NullEvolve when running the test (2 processes 2 threads each): {{{ INFO (NullInterp): the guard point shell is set for a max. stencil size of 3 INFO (NullSHRExtract): CCE world-tube index range is 4 4 20.404040404040405 20.404040404040405 INFO (NullEvolve): Null Initial Data At line 269 of file /mnt/data/rhaas/postdoc/gr/ET_Lovelace/arrangements/PITTNullCode/NullEvolve/src/NullEvol_InitialData.F90 Fortran runtime error: Array bound mismatch for dimension 1 of array 'jcn_rad' (15/31) At line 269 of file /mnt/data/rhaas/postdoc/gr/ET_Lovelace/arrangements/PITTNullCode/NullEvolve/src/NullEvol_InitialData.F90 Fortran runtime error: Array bound mismatch for dimension 1 of array 'jcn_rad' (16/31) }}} This happens when compiling with gcc 4.6.3 but does not seem to happen when using the intel compiler (though I am not quite sure how to turn on all the bounds checks in it). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/939> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac June 2012