> On May 15, 2018, at 1:22 AM, Mudelsee M <[log in to unmask]> wrote:
>
> Dear Bill,
>
> thanks for the reply. I agree that malformed files (i.e., others than file "a" I sent with my inquiry message) should be avoided, but that is life if you give courses and participants bring own data.
Indeed a problem. Perhaps some sort of input file clean-up code would be helpful - check that each record has the right line termination character(s) and the right number of values.
>
> However: I tried your suggestion by adding/replacing text with
>
> use,intrinsic :: iso_fortran_env
> if (iocheck == IOSTAT_END) exit
>
> but the results for file "d" are still negative ("n = 820") on my machines here:
>
> o gfortran that is included in gcc-4.6.0 (32 bit, Windows)
> o an old (2007) IBM workstation under Windows XPP 64 bit
> o an old (2010) PC under Windows 7 Prof 64 bit
>
> (I doubt that is has something to do with 32/64 bit.)
For comparison, I was using gcc 6.3.0 on a Mac (64-bit) - basically Unix. I’n not sure if the newer version helped, although by today’s standards even 6.3 is “old”. I would more likely suspect some issue with Windows which has its own proprietary character sequence for record termination. Is there some gfortran flag for “assume Windows record terminators”?
Cheers,
Bill
>
> For the sake of completeness, I attach one code here (there are several codes I use for teaching, which all have the same data size determination). There your suggestion has been built into subroutine chsett5.
>
> Cheers
>
> Manfred (puzzled)
>
> Am 14.05.2018 um 21:19 schrieb Bill Long:
>> 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
>
> --
> 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/
> <kernel.f90>
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
|