topic For what it's worth, if you in Intel® Fortran Compiler

Fortran reading and writing files

Peter_K_7 — Thu, 25 Jul 2013 11:13:19 GMT

Below is some code i made to read data from a text file and then write it to another the line of code that trips it is " read (10,*)i,j " I tried hard to find why it doesnt work but i cant do it. Someone please help!

program xproduct
  implicit none
        integer :: i,j

        open (unit=10,file='C:\\Fort\pete.txt')
        read (10,*)i,j

     open (unit=20,file='C:\\Fort\pete.out',action="write",
     1 status="replace")

  write (20,*) "The product of",i," and",j
  write (20,*) "is",i*j
  close (unit=20)
        close (unit=10)
   end program xproduct

I suppose we would need to

Steven_L_Intel1 — Thu, 25 Jul 2013 14:26:05 GMT

I suppose we would need to see the contents of pete.txt as well as the full text of the error message.

The following adaptation of

John_Campbell — Fri, 26 Jul 2013 00:07:30 GMT

The following adaptation of xprodict should identify the problem:

[fortran]program xproduct
    implicit none
       integer :: i,j, iostat

       open (unit=10,file='C:\\Fort\pete.txt', iostat=iostat)
         call report_error (iostat, 'Opening C:\\Fort\pete.txt')

       read (10,*,iostat=iostat)i,j
         call report_error (iostat, 'Reading i,j')

       open (unit=20,file='C:\\Fort\pete.out',action="write",status="replace", iostat=iostat)
         call report_error (iostat, 'Opening C:\\Fort\pete.out')

       write (20,*, iostat=iostat) "The product of",i," and",j
         call report_error (iostat, 'Writing i,j to 20')
       write (20,*, iostat=iostat) "is",i*j
         call report_error (iostat, 'Writing i*j to 20')

       close (unit=20, iostat=iostat)
         call report_error (iostat, 'Closing C:\\Fort\pete.out')
       close (unit=10, iostat=iostat)
         call report_error (iostat, 'Closing C:\\Fort\pete.txt')

end program xproduct

   subroutine report_error (iostat, comment)
   integer :: iostat
   character comment*(*)
!
!   if (iostat==0) return
   write (*,*) '    iostat =',iostat,' :',comment
   end[/fortran]

Perhaps 'C:\\Fort\pete.txt' should be 'C:\Fort\pete.txt' is all that is wrong ?

John

You might find the following

John_Campbell — Fri, 26 Jul 2013 01:29:26 GMT

You might find the following changes helpful, as I included IOSTAT= reports.

(I could not find a IOSTAT message routine in ifort help, so wrote my own ? Is there one available ?)

Fortran does not use the C/C+

jimdempseyatthecove — Fri, 26 Jul 2013 03:16:39 GMT

Fortran does not use the C/C++ escape character prefix "\" thus no requirement to use "\\" to pass one "\". Your file specification therefore contains a double \. Windows would likely treat this as C:, goto root (\), goto root again (\), ...

Try changing "\\" to "\" and see what happens.

Jim Dempsey

Quote:John Campbell wrote:(I

IanH — Fri, 26 Jul 2013 05:42:26 GMT

John Campbell wrote:
(I could not find a IOSTAT message routine in ifort help, so wrote my own ? Is there one available ?)

The IOMSG specifier does something similar, i.e. CHARACTER(100) :: msg ; OPEN(xxx, IOSTAT=stat, IOMSG=msg)

I tried the IOSTAT=reports

Peter_K_7 — Fri, 26 Jul 2013 12:21:56 GMT

I tried the IOSTAT=reports and IOMSG=reports but both of them came up with errors for unpaired right brackets on lines 9 and 10

also I removed a "/" from the

Peter_K_7 — Fri, 26 Jul 2013 12:43:43 GMT

also I removed a "/" from the place in my file path names where I had two instead of one. Nothing changed but i bet its still right coz im just a fortran newbie.

Peter,IOSTAT= assigns to an

Les_Neilson — Fri, 26 Jul 2013 13:50:00 GMT

Peter,
IOSTAT= assigns to an integer variable the value of which you can look up in the help (cf IOSTAT, errors returned to)
IOMSG= assigns to a character variable.
In a post above you say "both of them came up with errors for unpaired right brackets on lines 9 and 10" That sounds like a compile time error rather than a runtime error.

It would help us to help you if you attached the actual (unedited) code.

Is the code fixed or free form ?

Les

Peter,

John_Campbell — Sat, 27 Jul 2013 00:36:37 GMT

Peter,

The latest errors reported could be that the compiler assumes you have a fixed format (.for), rather than free format (.f90) code.

In the first post I did, I can now see that the use of cut/paste again did not work in this windows forum. The paste changed the use of \, removing 2 of the 3 \ in each file name.
( For how long do we continue to have to work around basic things like cut/paste not working and the hastles of soft and hard carriage returns ! Again, this is a "windows" forum)

My best guess of your original problem is the .txt file is either not opened correctly (does not exist or access rights problems) or the first two entries in the file are not the values of the two integers, I & J.

John

Cut/paste works if you follow

Steven_L_Intel1 — Sat, 27 Jul 2013 00:43:51 GMT

Cut/paste works if you follow the instruction for including Fortran code. You do this as follows:

[ fortran ]
your code here
[ /fortran ]

except that there are no blanks in the surrounding tags (if I removed the tags here then they'd be interpreted.) However, I am not aware that it removes backslashes. Why would you have three backslashes in a filename? Maybe you have this wrong in the source - the file you're opening should be specified as ''C:\Fort\pete.txt'. This is Fortran, not C, you don't escape backslashes (unless you're using C strings, which you're not.) In fact, this may be your entire problem.

Steve,

John_Campbell — Sat, 27 Jul 2013 02:09:06 GMT

Steve,

The three \ is not the problem, as I tested it, using Peter's original file names and found that the file opened successfully. Jim offered an explaination of this. However, I would change the name.
The answer might be in Windows 7/8 access rights. Opening the file for readonly access might remove the problem. My recommendation is to check the IOSTAT value of each file access.
A copy of pete.txt might also provide some insight.

John

The reason I wondered about

Steven_L_Intel1 — Mon, 29 Jul 2013 17:49:36 GMT

The reason I wondered about the file name is that he hasn't yet told us what the error is. Often I see cases where the file that is opened is not the one the user wanted, and a new, empty file is created by default. Then a READ will get an end-of-file.

Yes, we are all trying our crystal balls and finding them inadequate...

I disagree that paste works

dboggs — Tue, 30 Jul 2013 04:02:56 GMT

I disagree that paste works if you enclose it in Fortran delimiters. Yes it pastes, but the result is mangled. At the very least, it tends to delete blanks and insert line breaks. And the visual formatting is atrocious; everything appears double-spaced and occasionally triple-spaced if it happened that a real line break was inserted. After pasting, you have to go through the result carefully and fix it up or it won't appear right.

Quote:dboggs wrote:

mecej4 — Tue, 30 Jul 2013 14:19:08 GMT

dboggs wrote:

...At the very least, it tends to delete blanks and insert line breaks..

Not only is the visual appearance affected but one has to "submit" the post, inspect the not-so-pretty results and correct line numbers if they are mentioned in the text of the post. Too often, the line numbers mentioned in the post do not match those in the program listing and one has to edit the post and fix the line numbers.

Quote:Steve Lionel (Intel)

mecej4 — Tue, 30 Jul 2013 14:28:00 GMT

Steve Lionel (Intel) wrote:

However, I am not aware that it removes backslashes. Why would you have three backslashes in a filename?

The syntax highlighting formatter devours characters such as backslash, <, >, [, ]. To compensate for this, one sometimes tries to give it two, with the hope that it will eat only one and leave the other intact so that readers can view it. See this thread to see how the formatter, given a simple C source, ate the angle brackets and the included file names: http://software.intel.com/en-us/comment/reply/402436/1744952 . Even using the "view page source" feature of the browser does not reveal the include file names -- they are gone for ever.

There must be a fairly

John_Campbell — Wed, 31 Jul 2013 03:40:05 GMT

There must be a fairly significant difference between the aims of the developers of this forum and the experiences of it's users. For those of us who are developing Fortran code in a windows environment, the way this forum IDE responds is very frustrating and distracting from what we are trying to do. I am becoming amazed and frustrated at the persistence of Intel in not fixing what is a user interface with significant problems.

The way it handles a simple Enter, and how it devours a basic cut and paste should have been corrected months ago. I suspect this response must be acceptable in some other computer environment, but not one I am familiar with. All other IDE's I use on my Windows system do not behave like this, and you can use a fairly general interpretation of IDE, such as Visual Studio, Word, Notepad, other forums etc. Even booking a flight on-line is easier than this !

Why can't it be fixed.

With regard to the learned approach of posting, then editing; this is only allowed in a response post, as the original post to a new thread can not be edited. There are a few examples there of devoured layouts in a new thread post.

John

For what it's worth, if you

Anthony_Richards — Wed, 31 Jul 2013 09:27:00 GMT

For what it's worth, if you write

CHARACTER(256) STRING
STRING = 'C:\\Fort\pete.txt'C

where the appended C marks the character string as a 'C-string',
and then compile, the COMPILER will treat the first backslash as a control character
telling it that the next backslash is ok and it will not store (i.e. remove) the first backslash,
so STRING will be filled with the string 'C:\Fort\pete.txt' after it is stored somewhere in the executable ready for when the program is executed.

However, suppose you have a concatenation such as

STRING1='C:\\MYPATH'
STRING2=STRING1//'//MYFILE.TXT'C

Then the COMPILER will not remove the extra backslash in STRING1, as it is not marked as a C-string (no appended 'C'),
but during compilation it will remove the extra backslash in the string being concatenated, as it is marked as a C-string and therefore recognised as such. The result will be STRING2 will have an extra backslash in the path and so that may cause a problem later.
Basically, if the compiler can 'see' and therefore 'recognise' a string as a C-string, it will interpret control combinations such as //, /r,/n,/b,/a (backslash, newline,backspace, bell) and store the appropriate ASCII character in the place of the 2-character escape sequence combination.
If it cannot recognise the string as a C-string, it will just take the characters presented and store them.

Anthony,

John_Campbell — Wed, 31 Jul 2013 11:19:06 GMT

Anthony,

The \ removal came about when I copied text from a notepad screen to the forum comment box,via word paste (to try and overcome the hard/soft returns) and enclosed the text with the [ fortran ][ /fortran ], as Steve is suggesting.
I did not notice this change to the post until some time later. ( the later attached file would show the difference.)

It did not come about during a ifort compilation.

My apologies if I did not explain clearly, but it was another frustration with how this forum "IDE" works.

John