Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

gfortran.exe 9/10/2015 932kb

Status
Not open for further replies.

zmth

Technical User
Aug 5, 2015
57
PH
all the sudden strange behavior using above compiler. For illustration My source file is named U1.f95 with the following code
------------------
open (1, file="modinc395.t",status="old",position="rewind",&
action="read",iostat=ierror)
read(1,'(2(i3))') nps,npmx ; print*,"nps,npmx",nps,npmx
close(1) ; open (1, file="modinc395.t",status="old",position="append",&
action="readwrite",iostat=ierror)
write(1,*)" U1.f95" ; write(1,'("nps",(i2)," npmx",(i2))')nps,npmx
end
---------------------------
and named the file U1.f95
The source file modinc395.t which it reads is
-------------
5 1
-------------

on the top and only line of the file.

And at the dos command line I type

gfortran u1.f95

NOw as per above it is supposed to write, append to
the same file modinc395.t which it has been doing for over the last couple years properly but all the sudden now instead of writing to this file it writes to a created file fort.1 which i have nowhere told it to create or anything about this name. It writes
-----------
U1.f95
nps 5 npmx 1
-----------------
which is correct but it should be appending the file modinc395.t instead. Why all the sudden this change ? As far as i know i haven't changed anything. If i did something accidently what could it be ?

Note I have been using on a much longer source file with more writing. The above is just a simplified example. It does the same on the much longer file.







 
Don't use in read() the formst '(2(i3))' until you are sure that the input file is really so formatted - in your case it's not!
 
It uses fort.1 because it doesn't find modinc395.t
 
Now I created the I/O file with this content
modinc395.t
Code:
5 1

then modified little bit your source - removed the formatting from read statement, removed multiple statements per line and inserted close(1) which you forgot after the second open().
Please use only one statement per line - don't use more statements separated by semicolons - it's bad practice!

U1.f95
Code:
open (1, file="modinc395.t",status="old",position="rewind",&
      action="read",iostat=ierror)
read(1,*) nps,npmx
print*,"nps,npmx",nps,npmx
close(1)
open (1, file="modinc395.t",status="old",position="append",&
      action="readwrite",iostat=ierror)
write(1,*)" U1.f95"
write(1,'("nps",(i2)," npmx",(i2))')nps,npmx
close(1)
end

Now I compiled it
Code:
$ gfortran U1.f95 -o U1

After running it the file is changed
Code:
$ cat modinc395.t
5 1
$ ./U1
 nps,npmx           5           1
$ cat modinc395.t
5 1
  U1.f95
nps 5 npmx 1
 
And when you post the sources, please for the better readability insert it between the marks

[pre]
Code:
[/pre][/b]
and

[b][pre]
[/pre]
 

mikrom (Programmer)
10 Aug 17 20:16
Don't use in read() the formst '(2(i3))' until you are sure that the input file is really so formatted - in your case it's not!
"
Yea I just left out a space or two above. but that is not the problem as even so it reads it correctly and i have made sure of exactly the format to put in. That is not the problem as i use old copies of files of the ones that prior wrote to modinc395.t exactly the same as they were and now all the sudden even all those create a new file fort.1.
And by the way the other files all had nps,npmx as declared integer*1 and still the same
writing to a new file fort.1 when before they did NOt. NOthing is changed in those old files.

" t uses fort.1 because it doesn't find modinc395.t "

But it certainly had to find it in the read because it always prints it correctly for various different nps, npmx combinations. No matter what i use within reason.
AND where does it get that name ' fort.1 ' ?

"
then modified little bit your source - removed the formatting from read statement, removed multiple statements per line and inserted close(1) which you forgot after the second open().
Please use only one statement per line - don't use more statements separated by semicolons - it's bad practice! "

I used exactly what you wrote above. Still the same incorrect behavior- not writing to modinc395.t but to the newly created name fort.1 file just as always now no matter what now while just hours before all exactly original old files wrote to modinc395.t prior.

I even tried using.
" $ gfortran U1.f95 -o U1 "
but it would not accept this. I just removed the ' $ ' sign and it did accept but still the same incorrect behavior writing to the newly created file fort.1.
 
Or maybe the file modinc395.t could not be opened, because it was not closed after previous writing (you forgot the second close(1)) and so the program used fort.1
For example if I remove or rename file modinc395.t so the program U1 could not find it and try to run the program I get this error with the file fort.1:
Code:
$ ./U1
At line 3 of file U1.f95 (unit = 1, file = [highlight]'fort.1'[/highlight])
Fortran runtime error: End of file
It's default behaviour. The file name will be composed from fort and unit number. So for example If you would use in your program that file as unit number 10. i.e.:
Code:
open (10, file="modinc395.t",status="old",position="rewind",&
      action="read",iostat=ierror)
read(10,*) nps,npmx
print*,"nps,npmx",nps,npmx
close(10)
...
then when the file doesn't exist and you try to run your program, you will get this error with the file fort.10:
Code:
$ ./U1
At line 3 of file U1.f95 (unit = 10, file = [highlight]'fort.10'[/highlight])
Fortran runtime error: End of file
Note: The $ is only prompt on my command line in Linux. You should not write it. If you are on windows, then you have something like this: >


But now I thing, when you exactly copy the source U1.f95 from my previous post and the file modinc395.t, create them in the same directory, compile the program and run it, then it must work. Or do you have still some problem ?
 
Interesting so these fort.1 , fort.10 are kind of 'reserved' or standard names.
Anyway about 3 hours after my last post then it all the sudden went back to the usual
correct way of writing to the same modinc395.t file for ALL files many months old with absolutely no change in the files nor command line. They all are in the same directory. No changes at all.

" But now I thing, when you exactly copy the source U1.f95 from my previous post and the file modinc395.t, create them in the same directory, compile the program and run it, then it must work. Or do you have still some problem ? "

Like I said that is exactly what i did and it still had the problem. NOw it doesn't have that problem,issue, but neither do all the other 10 or more prior files many months old with no changes in those files. All changed to the same usual correct way when compiled a few hours after my last post - had nothing to do with the different formatting , leaving off a ' close ' statement etc. And I usually did not get any run time error when it wrote to fort.1 always with the correct text it got from modinc395.t so it had to read the first and only pertinent line of modinc395.t for reading except for maybe the first time when it first switched from the correct to incorrect behavior writing to fort.1.


There could be many other reasons depending upon the state of the computer or what's in the cache etc. etc. or what all else may be open not related to fortran I know since outputs to modinc395.t are always appended it got very long,maybe that's why it started? because it timed out or something and made a note somewhere to follow that same till it checked again after a few more trials, so i renamed it and made a fresh very short file and it still had that same writing to fort.1 issue till a few hours after that. Thanks for your trials anyway - may think of something else in light of that.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top