Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29236 Discussions

Not Really EOF?

michael_m1
Beginner
‎02-25-2005 09:40 PM
1,118 Views
Hi there, thanks in advance for looking at this for me. I'm new to Fortran, so this may be something simple.
I'm trying to recover an old program that was written, and it is causing me some trouble when it runs:
forrtl: severe (24): end-of-file during read, unit 22, file C:Documents and Set
tingscheekenMy DocumentsICAICAdatfile.tmp
Image PC Routine Line Source
drive.exe 00416329 Unknown Unknown Unknown
drive.exe 00416187 Unknown Unknown Unknown
drive.exe 00415364 Unknown Unknown Unknown
drive.exe 00415799 Unknown Unknown Unknown
drive.exe 0040D0C5 Unknown Unknown Unknown
drive.exe 00401100 DRIVER 50 Driv.for
drive.exe 00452269 Unknown Unknown Unknown
drive.exe 004376C9 Unknown Unknown Unknown
kernel32.dll 77E8141A Unknown Unknown Unknown
Press any key to continue
It sounds like it's complaining that it meets an end-of-file when it reads datfile.tmp, but there is most assuredly information in that file (a list of about twenty numbers).
Are other errors interfering with it seeing the data in the file?
Just so you know, I'm using the latest version of Compaq Visual Fortran on Windows XP.
Any insight would be appreciated.
Thank you,
Michael

Message Edited by michael.m on 02-25-2005 01:42 PM

0 Kudos

Link Copied

7 Replies
Steven_L_Intel1
Employee
‎02-25-2005 10:02 PM
1,118 Views
There are many ways this could happen. Can you post the READ statement and the contents of the file? That may help narrow down the causes.
0 Kudos
Copy link
michael_m1
Beginner
‎02-26-2005 02:48 AM
1,118 Views
Code:
open(unit=22,file='datfile.tmp')	
	read(22,*) tol
	read(22,*) tmax
	read(22,*) nres
	read(22,*) z0
	read(22,*) Q
	read(22,*) choice
	read(22,*) bla
	read(22,*) omegac
	read(22,*) omegae
	read(22,*) ramp
	read(22,*) kc
	read(22,*) w	
	read(22,*) R
	read(22,*) K	
	read(22,*) ratio
	read(22,*) conmech
	read(22,*) nonconmech
	read(22,*) chcramp
	read(22,*) Deq
	read(22,*) thick
	read(22,*) break
	read(22,*) cura
	read(22,*) ratio2
	read(22,*) Vol
	read(22,*) www
	read(22,*) qq
	read(22,*) miu
	read(22,*) rho
	close(22)

Certainly. Thank you for responding. The READ code is above, and I've attached the offending data file (note that I appended .txt to the file name in order for the message boards to allow me to upload it).

Thanks again!

Michael

0 Kudos
Copy link
Steven_L_Intel1
Employee
‎02-26-2005 11:42 AM
1,118 Views
Which READ is causing the problem? Are any of the variables declared as arrays?
0 Kudos
Copy link
michael_m1
Beginner
‎02-27-2005 12:25 AM
1,118 Views
The first read (read(22,*) tol)is causing the problem. None of the involved varaibles are arrays. To be clear, below you'll find all of the code from the beginning ofprogram until I close the file I am trying to read from (excluding comments).
Code:
	program driver
	
	integer*4 nresmax
	real*8 pi,xi0,xi1
	parameter(nresmax=300002,pi=3.141592654,xi0=8.854D-03,
     +                                        xi1=3.897D-02)
	real*8 t,tmax,tstep,tout
	real*8 sa(nresmax,4),d0
	real*8 d(2),work(142),phase,amplitude,a2,www,qq,miu,rho
	real*8 tol,bla,Q,Dnorm,break,thick,cura,betaw,ratio2
	real*8 z0,z1,omegac,omegae,ramp,ratio,dmax,pnorm,Vol,wqq,wqp
	real*8 betac,kc,mc,Aa1,Aa2,R,K,F0,w,a0,betai,Deq,lambda
	integer*4 nres,choice,contact,capflag
	integer*4 i,ii,conmech,nonconmech,chcramp,tnres
	integer*4 iflag,iwork(5)
	
	common /step/ tmax,tstep,nres
	common /excit/ z0,z1,omegac,omegae
	common /excit2/ ramp
	common /dataeq/ betac,kc,mc,R,K,F0,w,a0,betai,Deq,tol
	common /res/ sa
	common /model/ conmech,nonconmech,d0,dmax
 	common /rampchoi/ chcramp
	common /maugisdat/ Dnorm,lambda
	common /flags/ contact,capflag
	common /radcon/ a2
	common /forces/ Aa1,Aa2
	common /capi/ break,cura,thick,betaw
	common /chafiel/ qq,miu,rho
	
	external equa,resul,ode

	open(unit=22,file='datfile.tmp')	
	read(22,*) tol
	read(22,*) tmax
	read(22,*) nres
	read(22,*) z0
	read(22,*) Q
	read(22,*) choice
	read(22,*) bla
	read(22,*) omegac
	read(22,*) omegae
	read(22,*) ramp
	read(22,*) kc
	read(22,*) w	
	read(22,*) R
	read(22,*) K	
	read(22,*) ratio
	read(22,*) conmech
	read(22,*) nonconmech
	read(22,*) chcramp
	read(22,*) Deq
	read(22,*) thick
	read(22,*) break
	read(22,*) cura
	read(22,*) ratio2
	read(22,*) Vol
	read(22,*) www
	read(22,*) qq
	read(22,*) miu
	read(22,*) rho
	close(22)

Curiously, if I run the executable from the command prompt (instead of the debugger) I get the following, differenterror:

C: ... >drive
forrtl: severe (157): Program Exception - access violation
Image PC Routine Line Source
drive.exe 0042D104 Unknown Unknown Unknown
drive.exe 0041F093 Unknown Unknown Unknown
drive.exe 0040D52F Unknown Unknown Unknown
drive.exe 0040D0DB Unknown Unknown Unknown
drive.exe 0040114A DRIVER51 Driv.for
drive.exe 00452269 Unknown Unknown Unknown
drive.exe 004376C9 Unknown Unknown Unknown
kernel32.dll 77E8141A Unknown Unknown Unknown

Line 51 is the second read statement. (I'm puzzled as to why I get two different errors; perhaps the EOF error closes the file but still runs, and the second statement gets an access violation because the file is now closed?)

Michael

Message Edited by michael.m on 02-2 6-2005 04:26 PM

Message Edited by michael.m on 02-26-2005 04:27 PM

0 Kudos
Copy link
michael_m1
Beginner
‎02-27-2005 12:56 AM
1,118 Views
I've found part of the problem.
The reason the debugger is producing an EOF error is because it actually was meeting an EOF - it does something strange with relative file-referencing. When I run the program from the command line, I don't encounter this problem.
In any case, the problem I have in reality is the access violation error, which I noted above. For some reason, read(22,*) tmax is giving me an access violation.
Michael
0 Kudos
Copy link
Steven_L_Intel1
Employee
‎02-27-2005 12:57 AM
1,118 Views
Ok, you provided some useful additional information.

The reason you are getting the EOF error is that the input file is not where the program expects it to be. When you run the program from within the Developer Studio IDE, the default directory is set to the project directory, NOT the directory containing the EXE. So the OPEN is creating a new, empty file, which when read from gets an EOF. You see a different behavior when run from the command line because the input file is in the same directory as the EXE.

You can set the default directory for the debugger in Project..Settings..Debug or put a copy of the input file in the project folder.

The access violation is trickier. I don't see anything directly in the source that would cause this, but I can think of two things that could make this happen:

- You have a common block and a routine of the same name
- The common blocks are not the same length in all the source files

Either of these is illegal in Fortran.
0 Kudos
Copy link
michael_m1
Beginner
‎02-27-2005 01:42 AM
1,118 Views
In another file, I had a function named step - the same name as one of my common spaces.
This appears to have been the problem. Thank you!
0 Kudos
Copy link
Reply

Community support is provided Monday to Friday. Other contact methods are available here.

Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

For more complete information about compiler optimizations, see our Optimization Notice.