Error with reading in of unformatted files

[Wee_Beng_T_]

Hi,

I have problems reading in unformatted binary files. I am using ifort 11 with vs2005. When I run the code in linux using ifort, there is no problem. However, in the windows environment (win7, 64bit), the error reported is :

forrtl: severe (98): cannot allocate memory for the file buffer - out of memory,
unit 119, file d:\\Postdoc\\Ocean\\TIMCOMGLO\\EXAMPLES\\CASE5_ORG\\TEMP_TAI\\SVTAI
Image PC Routine Line Source
Timcom_vs2005.exe 006C354A Unknown Unknown Unknown
Timcom_vs2005.exe 005F60A0 Unknown Unknown Unknown
Timcom_vs2005.exe 005F527A Unknown Unknown Unknown
Timcom_vs2005.exe 00623CF2 Unknown Unknown Unknown
Timcom_vs2005.exe 004A64FC _RESTART_TAI_mp_R 57 restart_TAI.f90
Timcom_vs2005.exe 004A61AF _RESTART_TAI_mp_R 38 restart_TAI.f90


My code is :

FN=TRIM(WORKDIR)//TRIM(TDIR)//'SVTAI'
OPEN(119,CONVERT='BIG_ENDIAN',FILE=FN,form='unformatted')

READ(119) ITF,DAYS,AV,d_r_var1,PBAR,...

I tried to remove the "CONVERT='BIG_ENDIAN'" or change from BIG to LITTLE but it's still the same. I also tried to increase the stack reserve size but it's of no use.

Is there any other option I can try? I need to debug in windows and hence I am not able to proceed. Btw, I'm using the 32bit compiler with the 64bit win7 because some of the libraries are only 32bit.

Thanks!

[mecej4]

You have given insufficient information to answer your question.

Please show the full READ statement and the declarations of the variables in that statement.

On what system was your unformatted file written? What is the reason for adding CONVERT='BIG_ENDIAN'? Was the file written on a big-endian system? Can you reproduce the error on a machine running 32-bit Windows?

I hope you are aware that unformatted files are most often not portable.

[Wee_Beng_T_]

Hi mecej4,

the full statement is

READ(119) ITF,DAYS,AV,PBAR,PVAR,XBAR,SBAR,TBAR,UCLI,VCLI,RMSV,SSURFM,TSURFM,U1,U2,&
V1,V2,S1,S2,T1,T2,U,V,W,P0,P,RHO,X

Part of the declaration statements are:

REAL,ALLOCATABLE :: U1(:,:,:),U2(:,:,:),V1(:,:,:),V2(:,:,:),S1(:,:,:),S2(:,:,:)

allocate (U1(I0,J0,K1),STAT=status(1)); allocate (U2(I0,J0,K1),STAT=status(2)); allocate (V1(I0,J0,K1),STAT=status(3)); allocate (V2(I0,J0,K1),STAT=status(4))

if (status(1)/=0 .or. status(2)/=0 .or. status(3)/=0 .or. status(4)/=0) STOP "Cannot allocate memory"

There are too many in different places so I didn't list them.

But the strange thing I just found is that if I read the file in linux and writes them out in 4 seperate files. After that in windows, I read in the files like this:

READ(119) ITF,DAYS,AV,PBAR,PVAR,XBAR,SBAR,TBAR,UCLI,VCLI,RMSV,SSURFM,TSURFM,U1,U2
CLOSE(119)
FN=TRIM(WORKDIR)//TRIM(TDIR)//'SVTAI_new2'
OPEN(199,CONVERT='BIG_ENDIAN',FILE=FN,form='unformatted')
READ(199) V1,V2,S1,S2,T1
CLOSE(199)
FN=TRIM(WORKDIR)//TRIM(TDIR)//'SVTAI_new3'
OPEN(799,CONVERT='BIG_ENDIAN',FILE=FN,form='unformatted')
READ(799) T2,U,V,W,P0,P
CLOSE(799)
FN=TRIM(WORKDIR)//TRIM(TDIR)//'SVTAI_new4'
OPEN(799,CONVERT='BIG_ENDIAN',FILE=FN,form='unformatted')
READ(799) RHO,X
CLOSE(799)

Then it worked. Also, 4 files are needed cos if I read in too many variables at one time, it will give the error:

forrtl: severe (98): cannot allocate memory for the file buffer - out of memory,
unit 119, file d:\Postdoc\Ocean\TIMCOMGLO\EXAMPLES\CASE5_ORG\TEMP_TAI\SVTAI

Is it due to insufficient memory? Iniitally, there's the stack overflow problem and I tried to change the stack reserve size to 5x10^7. I also tried to change the stack commit size and the heap commit/reserve size but it doesn't seem to work. I'm also not sure what value to change to since my memory is limited.

I have the same problem with win7 32bit as well.

[mecej4]

UNFORMATTED files are non-portable until proven otherwise. Usually, unformatted Fortran files contain a number of records, with some book-keeping information in additional bytes before/between/after records.

Consequently, almost always there has to be a one-to-one match between the sequence, types and sizes of items in the I/O lists of the READ statements that read a file and the WRITE statements that produced that file. If this requirement is violated, then the bookpeeping bytes may be read as data or, conversely, your data bytes may be read as a record length. For example, an integer*2 data with a value of -1 could be read as a record length of 32768, if record lengths are 2-byte integers. Such an error may manifest itself as seemingly unrelated errors.

Your code is rather complex (with allocated arrays written using unformatted WRITEs, etc.). I am afraid that you will have to go through it and check that the requirements of matching READs and WRITEs have been met. Until this issue has been taken care of, messages as to stack-overflow, etc., should be taken with a grain of salt.