Trac May 2012

trac@lists.einsteintoolkit.org

2 participants
239 discussions

[Einstein Toolkit] #884: RotatingSymmetry90 lacks ManualCartesian tensor type support
by Einstein Toolkit 07 Jun '12

07 Jun '12

#884: RotatingSymmetry90 lacks ManualCartesian tensor type support --------------------+------------------------------------------------------- Reporter: tbode | Owner: tbode Type: defect | Status: new Priority: major | Milestone: ET_2012_05 Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- RotatingSymmetry90 currently doesn't process the ManualCartesian tensor type. Since WeylScal4 now has more than Psi4, this means WeylScal4 and RotatingSymmetry90 can't both be active. Does anyone have a patch lying around adding ManualCartesian support to RotatingSymmetry90 they wish to contribute? If not, I'll see to writing a patch. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/884> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[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] #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

[Einstein Toolkit] #927: Enable Simfactory to use CACTUS_CONFIGS_DIR
by Einstein Toolkit 31 May '12

31 May '12

#927: Enable Simfactory to use CACTUS_CONFIGS_DIR ------------------------+--------------------------------------------------- Reporter: sbrandt | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- This simple patch enables Simfactory to use CACTUS_CONFIGS_DIR -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/927> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #894: add support for CarpetInterp2 to InterpToArray
by Einstein Toolkit 31 May '12

31 May '12

#894: add support for CarpetInterp2 to InterpToArray -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- the attached patch adds support for CarpetInterp2 to interptoarray. For after the release. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/894> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #938: out of bounds array access in thorn ADM
by Einstein Toolkit 30 May '12

30 May '12

#938: out of bounds array access in thorn ADM -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: ADM | -----------------------------------+---------------------------------------- I just ran the Lovelace test with an executable build via sim build --debug. I get failing testsuites that did not fails with a normal build. One is ADM/test_ADM_2 which fails with (tow threads per process, two processes): {{{ INFO (IDAnalyticBH): setting up Schwarzschild initial INFO (IOBasic): Periodic scalar output requested for 'ADMANALYSIS::grr', 'ADMBASE::gxx', 'ADMBASE::kxx', 'ADMBASE::alp', 'ADMCONSTRAINTS::ham', 'ADMCONSTRAINTS::momx', 'ADMCONSTRAINTS::momy', 'ADMCONSTRAINTS::momz' INFO (ADM): 1+log slicing INFO (ADM): in the kleing style INFO (ADM): but not using the initial lapse coeff INFO (ADM): flat space diffusion .2000000E-04 INFO (ADM): and no curved space diffusion INFO (ADM): Initializing Leapfrog with FTCS Step Using a corrector step At line 23 of file /mnt/data/rhaas/postdoc/gr/ET_Lovelace/arrangements/CactusArchive/ADM/src/DoubleLeap.F Fortran runtime error: Index '0' of dimension 1 of array 'betax' below lower bound of 1 }}} The line number is completely wrong since line 23 is not even inside a function yet but recompiling without F_LINE_DIRECTIVES gives line 4553 of file /mnt/data/rhaas/postdoc/gr/ET_Lovelace/configs/sim- debug/build/ADM/DoubleLeap.f (after preprocessing). The code is {{{ do k=1,nz do j=1,ny do i=1,nx c The right-hand-side for the (conformal) metric evolution equation cdgdt_cdgxxdt = - 2*alp(i,j,k)*kxx(i,j,k) cdgdt_cdgxydt = - 2*alp(i,j,k)*kxy(i,j,k) cdgdt_cdgxzdt = - 2*alp(i,j,k)*kxz(i,j,k) cdgdt_cdgyydt = - 2*alp(i,j,k)*kyy(i,j,k) cdgdt_cdgyzdt = - 2*alp(i,j,k)*kyz(i,j,k) cdgdt_cdgzzdt = - 2*alp(i,j,k)*kzz(i,j,k) IF (conformal_state .gt. 0) THEN cdgdt_ipsi4 = 1D0/(psi(i,j,k)**4) cdgdt_cdgxxdt = cdgdt_cdgxxdt*cdgdt_ipsi4 cdgdt_cdgxydt = cdgdt_cdgxydt*cdgdt_ipsi4 cdgdt_cdgxzdt = cdgdt_cdgxzdt*cdgdt_ipsi4 cdgdt_cdgyydt = cdgdt_cdgyydt*cdgdt_ipsi4 cdgdt_cdgyzdt = cdgdt_cdgyzdt*cdgdt_ipsi4 cdgdt_cdgzzdt = cdgdt_cdgzzdt*cdgdt_ipsi4 END IF IF (shift_state .ne. 0) THEN if (local_spatial_order.eq.2) then dxdb_dxdbx = I2DX*(betax(i+1,j,k) - betax(i-1,j,k)) dxdb_dxdby = I2DX*(betay(i+1,j,k) - betay(i-1,j,k)) dxdb_dxdbz = I2DX*(betaz(i+1,j,k) - betaz(i-1,j,k)) else }}} which comes from line 300 of the unprocessed file. Clearly the limits of the loop should be {{{ do k=2,nz-1 do j=2,ny-1 do i=2,nx-1 }}} instead of {{{k=1,nz}}} etc. ok to apply (given that we want to deprecate ADM anyway)? The change has (surprisingly) no affect on the actual generated test output. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/938> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #930: ADMBase timelevel parameters should be steerable
by Einstein Toolkit 28 May '12

28 May '12

#930: ADMBase timelevel parameters should be steerable -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- It makes e.g. sense to reduce the number of timelevels upon recovery, if e.g. a thorn that requires more timelevels is not active any more, or if that thorn's parameters have been changed and the thorn now requires fewer timelevels, or if some of the timelevels were never needed to begin with. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/930> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #932: Test system should output details of the compiler used
by Einstein Toolkit 28 May '12

28 May '12

#932: Test system should output details of the compiler used -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Certain compiler versions (builds) might cause certain tests to fail. Keeping track of this would be easier if the test system output the build of the compiler used to summary.log. Compiler options might also be useful to have here. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/932> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

← Newer
1
...
12
13
14
15
16
17
18
...
24
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac May 2012