# abnormal value change

## abnormal value change

Hi,

I am using the intel fortran compiler for mac os x to calculate a computational fluid dynamic problems. Here is a very simple subroutine to generate the mesh.

```subroutine make_grid()
use global_parameters
use flow_parameters
use grid_arrays
implicit none
! local variable
integer :: i,j
! --- x direction ---
if (xgrid_unif == 1) then
dx1 = (xOut-xOrigin)/real(nx-1,KIND=CGREAL)
do i=1,nx
x(i) = xOrigin + real(i-1,KIND=CGREAL)*dx1
enddo
else
endif
x(0) = xOrigin*2.0_CGREAL - x(2)
x(nx+1) = x(nx)*2.0_CGREAL-x(nx-1)
! --- y direction ---
if (ygrid_unif == 1) then
dy1 = (yOut-yOrigin)/real(ny-1,KIND=CGREAL)
do i=1,ny
y(i) = yOrigin + real(i-1,KIND=CGREAL)*dy1
enddo
else
endif
!debug
do i=12,17
write(*,*) i,x(i)
end do
y(0) = yOrigin*2.0_CGREAL - y(2)
y(nx+1) = y(ny)*2.0_CGREAL-y(ny-1)
write(*,*) '-------------------------------------'
!debug
do i=12,17
write(*,*) i,x(i)
end do
stop
do i=0,nx
xc(i) = 0.5_CGREAL*(x(i+1)+x(i))
end do
do i=0,ny
yc(i) = 0.5_CGREAL*(y(i+1)+y(i))
end do
! --- write grid file for tecplot ---
open(unit=14,file='grid_plot.plt')
write(14,*)'variables="x","y"'
write(14,*)'zone f=point, i=',nx+1,', j=',ny+1
do j=0,ny
do i=0,nx
write(14,'(2(2x,e14.7))') xc(i),yc(j)
enddo
enddo
close(14)
return
end subroutine make_grid
```

In line 26 and 33, I output the value of the same variables twice. But the value of x(16) changes out of no reason, since the operation between these two outputs has nothing to do with x.

```12 -0.225000000000000
13 -0.200000000000000
14 -0.175000000000000
15 -0.150000000000000
16 -0.125000000000000
17 -0.100000000000000
-------------------------------------
12 -0.225000000000000
13 -0.200000000000000
14 -0.175000000000000
15 -0.150000000000000
16 0.525000000000000
17 -0.100000000000000
```

However, the same program works fine on ubuntu+intel fortran compiler.

Can someone help me with this?

8 posts / 0 new
For more complete information about compiler optimizations, see our Optimization Notice.

>>y(nx+1) = y(ny)*2.0_CGREAL-y(ny-1)

Don't you mean to say "y(ny+1)=..."

Also, it would help if we could see the array declarations.

I suggest you use "implicit none" and enable all runtime checks.

Jim Dempsey

Seconding Jim's comment.  It would be helpful to see your declarations of x, y, ny, yx to see if it is possible your y(nx+1) reference is exceeding its bounds and writing to the memory location where x(16) resides.

Thanks for all the answers. It runs correctly now. You guys are awesome. I got this program from somebody else, and it runs perfectly on the linux cluster with intel fortran compliler (not all y components are used in the program). This is why I never doubted about the program itself. Is this because intel fortran compiler compiles the same program differently on different systems?

You could look for differences among various compiler versions by comparing with -opt-report-file and -S.  Chances are there wouldn't be any differences when using the same compile options.  If there are latent bugs, they still may affect the results differently when you link against different operating system libraries.

Chi Z.

>>I got this program from somebody else, and it runs perfectly on the linux cluster with intel fortran compliler (not all y components are used in the program). This is why I never doubted about the program itself.

From your recent experience, I suggest you rephrase your above statement to:

I got this program from somebody else, it did not crash on the Linux cluster with Intel FORTRAN compiler, and the results looked reasonable, therefore I assumed the program was error free.

What I am contemplating is what was done with the potentially incorrect data on the linux cluster?

I strongly suggest you inform whomever you obtained the program from to make a set of output files using their current code and save the files for reference. Then apply your fix and run a new set of output files. Then compare the sets of output files. Without performing this test, you (and your colleague) will never know if the coding error was benign (harmless) or catastrophic.

Jim Dempsey

Mr. Jim Dempsey,

Thanks a lot. Your rigorous expression is very impressive. We test the program with a problem which has a analytical solution. The numerical solution from linux cluster matches the analytical solution perfectly, because only part of the y direction is inclued in the calculation process. In my opinion, y(nx+1) overwrites a useful memory location in mac os but ,somehow, not in linux; this may result from different features of these two systems. Further explanation may need something beyond my current knowledge.

There's no way of predicting the effect of array over-runs or undefined variables, for example, hence the suggestions that you try to find any such, using tools on linux or Mac or both.  The fact that you didn't notice a problem on linux doesn't prove that some unrelated change in the future won't surface a problem.