Fortran Issues with porting Fortran code

AI Thread Summary
A user encountered issues with a Fortran (F77) code when transitioning from using ifort on Fedora to g77 on Red Hat. The initial problem involved g77 not automatically initializing variables, leading to crashes, which was resolved by using specific compiler switches. However, a new issue arose with an "illegal unit number" error when attempting to open a file with unit number 87. Despite the unit number being within the valid range, the error persisted, prompting extensive troubleshooting. The user also faced a "file not found" error when reading a filename from an input file, which worked when hardcoded.After seeking assistance, the user discovered that the underlying issue was related to file encoding. The input file had been inadvertently changed to DOS format, which Fortran could not read. Switching the encoding back to Unix resolved the problem, allowing the code to function correctly. The discussion highlighted the importance of verifying file formats and encodings when dealing with file input/output in Fortran.
WD_star
Messages
5
Reaction score
0
I have a Fortran (F77) code which I used to use at my previous institution that I am having trouble with at my new job. I used to compile it with ifort on computers running Fedora (14 if I recall correctly). At my new job they don't have ifort so I have had to revert to the use of g77 (f77) on systems running Red Hat.

It took awhile, and a little help, to figure out that one of my codes would compile but crash once executed because g77 didn't automatically initialize all variables to zero. Luckily switches do exist to make g77 do this and I thought I was home free. This week, I tried running what is essentially the same code, but I get an ''illegal unit number error" when opening a file. I have Googled extensively to both understand the problem and find a solution but have ultimately been unsuccessful. I know illegal unit numbers can come from choosing things out of the range of 0 to 99, but in this case the unit number in question is 87! Furthermore, the other code I had trouble with previously includes the exact same subroutine where that file is opened and it doesn't cause a problem!

Any and all suggestions are useful. Please let me know if I can supply any additional information that might help pinpoint the problem.

Thanks.
 
Technology news on Phys.org
It's a simple open statement:

Code:
      open(87,file='data/fort_HALPHA.22')

And yes I have tried adding a status='old' statement but I get the same error which is as follows:

open: illegal unit number
apparent state: unit 87 (unnamed)
last format: list io
lately reading sequential formatted external IO
Abort (core dumped)
 
Maybe the problem is not when opening the file...looks like that already worked...maybe the problem is at some reading statement somewhrw else where somehow the unit number is not correct. Is the code long? May want to post it
 
The whole code is quite long, here is the portion where the file is read(it coincides with the end of the subroutine):

Code:
      nxbal=0
      read(87,*) nxbal,stnnec,stnchc,vneuc,vchac
      do i=1,nxbal
         read(87,*) xlbal(i),(plbal(i,j),j=1,NNMAX)
      end do
      close(87)
      stnnec=10.0**stnnec
      stnchc=10.0**stnchc
      iwarnc=0
      return
      end

There is also a related issue that I didn't mention in my first post because I found a way to solve it even though it shouldn't be a problem at all. There is an input file that the code cannot find (''file not found'' type of error). The name of the input file is read as a string in another input file. However, if I hardcode the filename in the open command, then there is no problem. The relevant code for that follows:

Code:
      read(iunit1,100) file
c      open(iunit4,file=file,status='old')
      open(iunit4,file='data/grid_DA_FINAL',status='old')
 
Bump

Anybody have any suggestions??
 
You did not post much about the "open" statement for unit 87...maybe that statement is not working out too good...did you verify that it worked? You can use one of the arguments to the OPEN statement and inspect that upon return from the OPEN statement to see if it worked or not.

As far as that other file name being read from a file vs hardcoded...did you verify what you are reading from the file? You need to read the filename and write it back out and see what you are reading, THEN if that does match the actual filename.

Also, if the file you are trying to read is not in the exact same directory where you are running from, I wonder if you can work with relative path or you need full path, etc.
 
gsal, thanks for taking the time to try and help me.

I have actually solved my problem and it wasn't related to Fortran (at least not exactly). I read your last post and started running some tests. In the process, I noticed that at the bottom of the emacs window for the input file where the other input filename was read, it was written 'DOS'. After a quick Google search, I understood that I had somehow inadvertently changed the buffer encoding system of that file from Unix to DOS! (http://edivad.wordpress.com/2007/04/03/emacs-convert-dos-to-unix-and-vice-versa/) I switched it back to Unix and presto, the code works! Clearly Fortran could not read the file with the DOS buffer encoding.

In any case, thanks again gsal!

Case closed!
 

Similar threads

Replies
8
Views
1K
Replies
2
Views
2K
Replies
8
Views
4K
Replies
3
Views
5K
Replies
14
Views
5K
Replies
17
Views
6K
Back
Top