JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for COMP-FORTRAN-90 Archives


COMP-FORTRAN-90 Archives

COMP-FORTRAN-90 Archives


COMP-FORTRAN-90@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

COMP-FORTRAN-90 Home

COMP-FORTRAN-90 Home

COMP-FORTRAN-90  May 2018

COMP-FORTRAN-90 May 2018

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: automatic sample size determination, while construct, gfortran compiler option (end of file)

From:

Bill Long <[log in to unmask]>

Reply-To:

Fortran 90 List <[log in to unmask]>

Date:

Tue, 15 May 2018 13:57:12 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (1 lines)

 
> 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 
 
 

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
December 2015
November 2015
October 2015
September 2015
August 2015
June 2015
April 2015
March 2015
January 2015
December 2014
November 2014
October 2014
August 2014
July 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
July 2013
June 2013
May 2013
April 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
August 2010
July 2010
June 2010
March 2010
February 2010
January 2010
December 2009
October 2009
August 2009
July 2009
June 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
January 2007
2006
2005
2004
2003
2002
2001
2000
1999
1998
1997


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager