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

open/read issue

Brandon_J_
Beginner
855 Views

Hello all,

I am having some difficulty with what should be very simple, but I am at my whit's end. Unfortunately, my attempts to create a simple test program that reproduce the error were unsuccessful. This software is part of a larger project, so I apologize for being unable to provide all of the code. I did trim down the subroutine to a portion necessary for the error to occur. I understand if anyone attempting to help is unable to duplicate the error, but I would appreciate any advice. I note that I am calling the software package from Python (via C code and SWIG). The erroneous code is being called from another Fortran subroutine, thus, for debugging, I hardcoded the input to ensure there is not an issue with input arguments from the top level. I have never run into an issue like this with other software called from Python, but I cannot claim that this does not cause an issue I am unaware of.

I am attempting to open/read a file in Fortran, which exists (based on calls to inquire()), but the subsequent call to read() fails. open() does not cause a runtime error, and attempts to capture the error via the err/iostat options also indicate no error with the open() call. Unfortunately, calls to inquire() indicate that the unit number is not associated with the file, and, of course, the software fails with the first call to read(). Below, I included the runtime output from the software, and the code itself. What kind of issue could cause open() to not return an error, but not associate the file with a Fortran unit number?

The file was generated using Fortran unformatted I/O, on the same computer with the same compiler. Some online research indicated that any of these inconsistencies could cause a problem, and I wanted to eliminate them before seeking assistance.

Any advice is greatly appreciated,

Brandon

Runtime output:

ggm02c.20v

before open call

file inquire results:

File open?: F

File exisits?: T

File unit number: -1

no error in the open call

after open call

file inquire results:

File open?: F

File exisits?: T

File unit number: -1

unit inquire results:

File open?: F

File name?:

File action:

UNDEFINED

forrtl: No such file or directory

forrtl: severe (29): file not found, unit 87, file fort.87

Image PC Routine Line Source

libintlc.dylib 000000010B84AE04 Unknown Unknown Unknown

libintlc.dylib 000000010B84959E Unknown Unknown Unknown

libifcore.dylib 000000010AD54D81 Unknown Unknown Unknown

libifcore.dylib 000000010ACC43EE Unknown Unknown Unknown

libifcore.dylib 000000010ACC390D Unknown Unknown Unknown

libifcore.dylib 000000010ACFDE82 Unknown Unknown Unknown

_rk78.so 0000000109FD9CF1 _readmodel_shells 79 readmodel_shells.f

_rk78.so 0000000109FCAC83 _readmodel_interf 35 grav_cubef.f

_rk78.so 0000000109FCBDEA _Initialize_CubeV 384 grav_cube.c

_rk78.so 0000000109FB92B2 _DE_drag_SRP_cube 632 DE_drag_SRP_cube_sine2_stm.c

_rk78.so 0000000109F83A10 _findptr 361 findptr.c

_rk78.so 0000000109F7FC54 __wrap_findptr 6817 rk78_wrap.c

Python 00000001000CABB1 Unknown Unknown Unknown

Python...

Code causing the error:

subroutine readmodel_shells(fname)

implicit none

character fname*102

integer nunit

integer shell_length

integer num_shells

integer hdr_length

logical I_open, I_exist

integer I_num, nerr

character I_name*102

character I_action*102

nunit=87

fname="ggm02c.20v"

print *, trim(fname)

inquire(file=trim(fname),opened=I_open,exist=I_exist,number=I_num)

print *, 'before open call'

print *, 'file inquire results:'

print *, 'File open?:', I_open

print *, 'File exisits?:', I_exist

print *, 'File unit number:', I_num

c open(unit=nunit,file=trim(fname),status='old',form='unformatted')

open(unit=nunit,file=fname,status='old',

& form='unformatted',err=450,iostat=nerr)

print *, 'no error in the open call'

goto 460

c I note that this print of the nerr is skipped at runtime (see output)

450 print *, 'iostat = ',nerr

460 inquire(file=trim(fname),opened=I_open,exist=I_exist,number=I_num)

print *, 'after open call'

print *, 'file inquire results:'

print *, 'File open?:', I_open

print *, 'File exisits?:', I_exist

print *, 'File unit number:', I_num

inquire(nunit,opened=I_open,name=I_name,action=I_action)

print *, 'unit inquire results:'

print *, 'File open?:', I_open

print *, 'File name?:', I_name

print *, 'File action:', I_action

read(nunit) shell_length, num_shells, hdr_length

print *, 'after'

close(unit=nunit,status='keep')

return

end

Intel ifort compiler information:

Version 12.1.3.289 Build 20120130

Fortran compile command (for debugging):

ifort -c -W1 -fPIC -g -traceback <>

Running on MacOS 10.6.8 via the command line.

0 Kudos
4 Replies
mecej4
Honored Contributor III
855 Views
Since you have provided only excerpts, the following is speculative.

You opened unit 87 as a file with a FILE= attribute, wrote to the file, and then closed the file.

The file now exists, but the association between unit number 87 and the named file is now broken.

Later, in the same or in a different program, I/O is attempted with unit 87, incorrectly assuming that this unit is still connected to the same named file as before. The I/O runtime finds that unit 87 is not open and, falling back on the legacy behavior of doing an "implicit OPEN", looks for a file called fort.87, which it will not find.

Check that the unit is not closed before all I/O on it has been performed.
0 Kudos
Brandon_J_
Beginner
855 Views

Thank you for your reply.

The main symptom appears before I attempt to read/write. The subroutine I supplied is complete, although I did not supply the calling code. As demonstrated by the traceback, there is quite a lot. The inquire() calls immediately following the open() call indicate that open() failed, yet open() did not detect/return an error. I do not understand what could cause this behavior.

If I understand your suggestion correctly, I should make sure the code does not attempt any I/O before a call to close(). If this interpretation is correct, the inquire() calls are performed immediately following the call to open(), and before any other file I/O functions. This is the only Fortran function that performs file I/O in the package, let alone on unit 87. The file I am attempting to read was generated using another program.

Brandon

0 Kudos
Brandon_J_
Beginner
855 Views

Hello all,

I do not know if this information will help, but when I take the same code and compile it on a different computer with a difference version of ifort, I no longer get the problem. The differences are:

Works on:

Linux RedHat Enterprise 5.8

Intel Compiler: Version 12.0.4.191 Build 20110427

Does not work on:

MacOS X 10.6.8

Intel Compiler: Version 12.1.3.289 Build 20120130

0 Kudos
mecej4
Honored Contributor III
855 Views
>If I understand your suggestion correctly, I should make sure the code does >not attempt any I/O before a call to close().

Rather, this is what I meant: the code should not attempt any I/O without ensuring that the file is open. In particular, if the file was created with an OPEN, written to and closed, the file has to be opened before attempting further I/O.

If the program is running on certain platforms and not on others, I think that my guess as to the bug is wrong. I don't think that much can be done without having a complete example that can be built and run to reproduce the error.
0 Kudos
Reply