[ET Trac] [Einstein Toolkit] #938: out of bounds array access in thorn ADM

[Einstein Toolkit]

#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