Note that the wc system utility also thinks that d.txt has 820 lines:
% wc d.txt
820 1642 11402 d.txt
This is because the last “line” of the file is malformed. By checking for iostat .ne. 0 you are tripping on that error, rather than the EOF indicator. If the code is modified to
use,intrinsic :: iso_fortran_env
integer :: i ! counter
integer :: iocheck ! check
integer :: n ! sample size
real :: t ! time
real :: x ! variable
character(len=*),parameter :: file1 = "d.txt"
!
! Determine data size automatically
! =================================
!
open (unit=1, file=file1, status='old')
i=1
do
read (unit=1, fmt=*, iostat=iocheck) t, x
if (iocheck == IOSTAT_END) exit
i=i+1
end do
close (unit=1, status='keep')
n=i-1
print *, n
end
then it prints 821:
% gf d.f90
% ./a.out
821
[gf is my shorthand for gfortran]
Cheers,
Bill
> On May 14, 2018, at 1:59 AM, Mudelsee M <[log in to unmask]> wrote:
>
> Dear colleagues,
>
> I am looking for help in the interpretation and correction of an issue (which seemingly has something to do with the end-of-file situation) that arises when I compile a code under gfortran.
>
> Below code extract shows the while construct used to determine the sample size of a time series. The idea is that after iocheck is .ne. 0 (end reached), the counting is stopped. Automatic sample size determination is convenient in applied time series analysis, so I wish to keep this.
>
> The issue now is that a gfortran-compiled (just the -O2 option) executable may (depending on how the input data file is, see the file description below) yield an n value that is less by one than the true value. From the 5 attached test files (a, b, c, d, e), this happens for file1 = d (which produces n = 820 instead of 821); the other files correctly yield n = 821.
>
> This issue does not occur when the code is compiled under ifort (I do not remember by heart the compiling options).
>
> The 5 files (attached) contain the same data but diverge with regard to the end portion: carriage-return (CR), line-feed (LF), space, decimal point. The ominous file "d" has:
> o no decimal point (i.e., an integer is read for x)
> o no space after the last value
> o no extra line
> The attached scan shows the end portions of the files within Notepad++ editor (the "[NOTE SPACE]" is inserted by me for clarification).
>
> I have the intuition that an added gfortran compiling option may help (i.e., makes also "d" yield correctly n = 821), but I am not an expert on gfortran, and I thought there may be guys out there who quickly spot how to correct this.
>
> I hope that the amount of information is sufficient and that it is possible to understand the issue without being given the full source code.
>
> Many thanks!
>
> Manfred
>
>
> === code extract ===
>
>
> integer :: i ! counter
> integer :: iocheck ! check
> integer :: n ! sample size
> real :: t ! time
> real :: x ! variable
> character(len=*) :: file1
>
> !
> ! Determine data size automatically
> ! =================================
> !
> open (unit=1, file=file1, status='old')
> i=1
> do while (.true.)
> read (unit=1, fmt=*, iostat=iocheck) t, x
> if (iocheck .ne. 0) exit
> i=i+1
> end do
> close (unit=1, status='keep')
> n=i-1
>
> ===================
>
>
>
> --
> Dr. Manfred Mudelsee
>
> Chief Executive Officer
> Climate Risk Analysis
> Kreuzstrasse 27
> Heckenbeck
> 37581 Bad Gandersheim
> Germany
>
> Telephone: +49 5563 9998140
> Email: [log in to unmask]
> URL: http://www.climate-risk-analysis.com
> Skype: mudelsee1
> LinkedIn: https://de.linkedin.com/in/mudelsee
> Twitter: @MMudelsee
>
> Climate Time Series and Risk Analyses
> Book: http://www.manfredmudelsee.com/book/
> Courses: http://www.climate-risk-analysis.com/courses/
> <a.txt><b.txt><c.txt><d.txt><e.txt><Scannen0001.pdf>
Bill Long [log in to unmask]
Principal Engineer, Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9143
Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
|