- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page