Error reading huge file: did something change between ifort 9.0 and 10.0?

[laurent_nguyen]

Hello,

here an example of program:

program ecriture
implicit none
integer, parameter :: nx = 512
integer, parameter :: ny = 512
integer, parameter :: nz = 512

complex*16, dimension(nx,ny,nz) :: u,v

u = CMPLX(1.D0,1.D0)
v = CMPLX(2.D0,2.D0)

open(unit=1,file='essai.dat',status='replace',form='unformatted')
write(1) u
write(1) v
close(1)

open(unit=1,file='essai.dat',status='old',form='unformatted')
read(1) u
read(1) v
close(1)

write(6,*) 'fin'


end program

I compile it like this: ifort -c -r8 main.f90
My system is IA64.
When I use ifort 9.1.045 or gfortran 4.1, it runs. But since ifort 10.0 (and 10.1), I've got this error:

forrtl: severe (67): input statement requires too much data, unit 1, file essai.dat
Image PC Routine Line Source
exe 40000000000D9150 Unknown Unknown Unknown
exe 40000000000D6A60 Unknown Unknown Unknown
exe 4000000000050690 Unknown Unknown Unknown
exe 4000000000009DD0 Unknown Unknown Unknown
exe 4000000000008DA0 Unknown Unknown Unknown
exe 4000000000028A00 Unknown Unknown Unknown
exe 4000000000023DC0 Unknown Unknown Unknown
exe 4000000000003830 Unknown Unknown Unknown
exe 4000000000002A50 Unknown Unknown Unknown
libc.so.6.1 2000000000439430 Unknown Unknown Unknown
exe 4000000000002880 Unknown Unknown Unknown

I set my uilimit at unlimited.

Thank you for your help.

[Steven_L_Intel1]

Lots of things changed between 9.0 and 10.0. Did any of them deliberately affect this program? Hard to say. Have you tried 11.0?

Can you do a "od -t x4 -N 256" on the data file and post the output?

[laurent_nguyen]

Quoting - Steve Lionel (Intel)

Lots of things changed between 9.0 and 10.0. Did any of them deliberately affect this program? Hard to say. Have you tried 11.0?

Can you do a "od -t x4 -N 256" on the data file and post the output?

I don't have ifort v11 (but when I got it, I will try).

Here the output for the data file:

0000000 80000009 00000000 3ff00000 00000000
0000020 3ff00000 00000000 3ff00000 00000000
*
0000400

Thenk you for your help.

[Steven_L_Intel1]

Ok, that's interesting. Your record has exactly 2GB of data which is just over the threshold where it will be split into two subrecords. I admit I don't understand what I am seeing with 11.0 or even 9.0 (which gives me the same data) for how the subrecords are created - I need to study this some more.

[Steven_L_Intel1]

Minor update - I am now convinced that the file is written correctly, though the documentation for the subrecord layout needs improvement. Now to see what's going on with the reads...

[laurent_nguyen]

Quoting - Steve Lionel (Intel)

Minor update - I am now convinced that the file is written correctly, though the documentation for the subrecord layout needs improvement. Now to see what's going on with the reads...

Ok, it seems this problem doesn't occurs with ifort v11. We will soon receive this version. It's a good news for our cluster. I'm curious about this problem.

[Steven_L_Intel1]

I could reproduce it with 11.0.074, though that's not the latest version. I'll try a newer one.

[Steven_L_Intel1]

I still see the error with 11.0.081. I have escalated this to development - the issue ID is DPD200119568.

[laurent_nguyen]

Quoting - Steve Lionel (Intel)

I still see the error with 11.0.081. I have escalated this to development - the issue ID is DPD200119568.

Can you read it with ifort 9.0? I thought it was some improvements in the newest versions but I didn't see it on release notes.

[Steven_L_Intel1]

When I tried with 9.1, I got an "out of memory" error. Apparently I could not configure that system with enough memory to deal with this. Unfortunately, the current design of the library is to create a separate buffer of the whole record. The developers are looking into this.

[draceswbell_net]

Quoting - laurent.nguyen

Hello,

here an example of program:

program ecriture
implicit none
integer, parameter :: nx = 512
integer, parameter :: ny = 512
integer, parameter :: nz = 512

complex*16, dimension(nx,ny,nz) :: u,v

u = CMPLX(1.D0,1.D0)
v = CMPLX(2.D0,2.D0)

open(unit=1,file='essai.dat',status='replace',form='unformatted')
write(1) u
write(1) v
close(1)

open(unit=1,file='essai.dat',status='old',form='unformatted')
read(1) u
read(1) v
close(1)

write(6,*) 'fin'


end program

I compile it like this: ifort -c -r8 main.f90
My system is IA64.
When I use ifort 9.1.045 or gfortran 4.1, it runs. But since ifort 10.0 (and 10.1), I've got this error:

forrtl: severe (67): input statement requires too much data, unit 1, file essai.dat
Image PC Routine Line Source
exe 40000000000D9150 Unknown Unknown Unknown
exe 40000000000D6A60 Unknown Unknown Unknown
exe 4000000000050690 Unknown Unknown Unknown
exe 4000000000009DD0 Unknown Unknown Unknown
exe 4000000000008DA0 Unknown Unknown Unknown
exe 4000000000028A00 Unknown Unknown Unknown
exe 4000000000023DC0 Unknown Unknown Unknown
exe 4000000000003830 Unknown Unknown Unknown
exe 4000000000002A50 Unknown Unknown Unknown
libc.so.6.1 2000000000439430 Unknown Unknown Unknown
exe 4000000000002880 Unknown Unknown Unknown

I set my uilimit at unlimited.

Thank you for your help.

From brief experiments, you can work around this bug using the following two code modifications.

#ifdef BINARY
open(unit=1,file='/mnt/panfs/INTEL-IOTEST/essai.dat',status='replace',form='binary')
#else
open(unit=1,file='/mnt/panfs/INTEL-IOTEST/essai.dat',status='replace',form='unformatted',access='stream')
#endif
write(1) u
write(1) v
close(1)

u = CMPLX(0.D0,0.D0)
v = CMPLX(0.D0,0.D0)
#ifdef BINARY
open(unit=1,file='/mnt/panfs/INTEL-IOTEST/essai.dat',status='old',form='binary')
#else
open(unit=1,file='/mnt/panfs/INTEL-IOTEST/essai.dat',status='old',form='unformatted',access='stream')
#endif
read(1) u
read(1) v
close(1)

If you happen to be sharing files with c programs, then this may be your expected structure anyway. I believe these two structures do not include the record formats. gfortran supports is style of file also, so you can communicate between these if necessary.

[laurent_nguyen]

Quoting - draceswbell.net

From brief experiments, you can work around this bug using the following two code modifications.

#ifdef BINARY
open(unit=1,file='/mnt/panfs/INTEL-IOTEST/essai.dat',status='replace',form='binary')
#else
open(unit=1,file='/mnt/panfs/INTEL-IOTEST/essai.dat',status='replace',form='unformatted',access='stream')
#endif
write(1) u
write(1) v
close(1)

u = CMPLX(0.D0,0.D0)
v = CMPLX(0.D0,0.D0)
#ifdef BINARY
open(unit=1,file='/mnt/panfs/INTEL-IOTEST/essai.dat',status='old',form='binary')
#else
open(unit=1,file='/mnt/panfs/INTEL-IOTEST/essai.dat',status='old',form='unformatted',access='stream')
#endif
read(1) u
read(1) v
close(1)

If you happen to be sharing files with c programs, then this may be your expected structure anyway. I believe these two structures do not include the record formats. gfortran supports is style of file also, so you can communicate between these if necessary.

Hello,

thank you for your advices. I've already rewritten my codes. I wanted to know the changes between both version of Intel Fortran, because I didn't find any indications in the release notes.

[Steven_L_Intel1]

This has been confirmed to be a bug which is being fixed. I don't yet know when the fix will appear. It was not a deliberate change so would not have appeared in the release notes. It was possibly a side effect of an attempt to give a better message when there was insufficient memory to hold such a large record.

[Steven_L_Intel1 · Accepted solution]

This issue was fixed in 11.1.

[laurent_nguyen]

Hello Steve,

I forgot this thread since long.

Then, another user got this problem on x86_64 Nehalem with compilers 10.1. So, I remember this thread.

I tried on our both system (ia64 and x86_64) with compilers v11.1.056 and it seems this problem to be fixed.

Thank you for your support.