Run-time error when compiling with PGI, but not with Intel

Accelerated Computing HPC Compilers Legacy PGI Compilers
1

Hello,

Our site has a user with a fortran code (included below) that compiles fine with pgf90 (PGI), gfortran (GNU), and ifort (Intel). When executed however, only the version compiled with ifort completes successfully. Here is the error received when running the pgf90 version:

$ pgf90 -r8 cylindrical.f90 -o cylindrical.exe
$ ./cylindrical.exe
allocate arrays
Open grid files…
write grid file…
PGFIO/stdio: No such file or directory
PGFIO-F-/unformatted write/unit=120/error code returned by host stdio - 2.
File name = grid3dg.ggFine unformatted, stream access record = 0
In source file cylindrical.f90, at line number 57

FWIW the version compiled with gfortran segfaults, rather than providing the 4 lines of error messages like the pgf90 version provides.

This can be reproduced on multiple systems using anything from PGI 10.9 to PGI 11.10.

Any clues as to what’s going on would be greatly appreciated. Our site has multiple PGI licenses, but an email sent to trs@pgroup.com has not elicited a response.

Thanks in advance!
-Lee


Here is the code in question:

program hexahedronvol


implicit none


real::r
real::pi=3.141592653589793
integer::i,j,k,L,nxg,nyg,nzg
integer::nx,ny,nz,ni,nj,nk
real::aa,rr,phi,x0,y0

real,allocatable,dimension(:,:,:)::xx
!real,allocatable,dimension(:,:,:)::yy
real,allocatable,dimension(:,:,:)::zz



nx=1280
ny=896
nz=1920



nxg=nx
nyg=ny
nzg=nz


r=1.0

print*,“allocate arrays”
!-----------------------------------------------------
allocate(xx(1:nxg+1,1:1,1:nzg+1)); xx = 0.
!allocate(yy(1:nxg+1,1:1,1:nzg+1)); yy = 0.
allocate(zz(1:nxg+1,1:1,1:nzg+1)); zz = 0.

print*,“Open grid files…”
!---------------------------------------------------------

!—just for bump case
! open(120,file=‘bumpEtrdFF.grd’,form=‘formatted’)
! read(120,) L
! read(120,) nk,ni,nj
! read(120,) (((xx(i,j,k),k=1,nk),i=1,ni),j=1,nj)
! read(120,) (((aa, k=1,nk),i=1,ni),j=1,nj)
! read(120,) (((zz(i,j,k),k=1,nk),i=1,ni),j=1,nj)
! close(120)
!---------------------------------------------------------



print,“write grid file…”
!---------------------------------------------------------
open(120,file=‘grid3dg.ggFine’,form=‘unformatted’,access=‘stream’)
write(120) nx+2,ny+2,nz+2
write(120) (((xx(i,1,k),i=1,nx+2),j=1,ny+2),k=1,nz+2) &
, ((((j-1.)*1.015625e-3,i=1,nx+2),j=1,ny+2),k=1,nz+2) &
, (((zz(i,1,k),i=1,nx+2),j=1,ny+2),k=1,nz+2)
close(120)

!---------------------------------------------------------




write(*,‘(f18.16)’) 2.3
end program

2

Hi lwhatley,

I finally had to send this off to one of our compiler engineers to look at. I seems to me that we’re hitting an internal limit since the program only fails when the record size is around 8GB.

So the work around is to reduce the size of ny.

A couple of side notes. Is the “+2” in the write statement correct? This will cause out-of-bounds access since xx and zz are allocated with “+1”, not “+2”.

Second, if the user plans on using ny to size the second dimension, have them add the flag “-Mlarge_arrays” since they will be larger then 2GB.

  • Mat
3

Hi Mat,

Thanks for the response! When you say an “internal limit”, do you mean a limit within the compiler, or some OS ulimit?

I have passed your response on to the user, and will let you know if your suggestions make a difference.

Thanks!
-Lee

4

do you mean a limit within the compiler, or some OS ulimit?

Compiler but this is just a guess.