Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Implied DO LOOP in READ statement

Paul_C_5
Beginner
1,209 Views

Hi - newbie here!

Here are three lines of a text file

2                                 !nwpoints
100,4500                                 !below xwpoint(i) and then wave data file & shift for wave data
PT_1week.dat,F_1week.dat                        !wave file name

Here is some code to read the file

READ(LunSte,*)nWPoints
if (deb.eq.1)  write(*,*) 'n wave points',nWPoints
READ(LunSte,*) (XWPoint(N),N=1,nWPoints) !Read xposition for the wave points     
if (deb.eq.1)  write(*,*) 'wave points', (XWPoint(N),N=1,nWPoints)   
READ(LunSte, *)(NameWaveFile(N),N=1,nWPoints)  !Read File names for each wave point

It runs successfully on one system (compiler/OS/etc) with the NameWaveFile array containing “PT_1week.dat” and “F_1week.dat” as one might expect.

On my system (of course) the first two reads work fine -  so nWPoints is 2 and the XWPoint array contains 100 and 4500 accordingly … but…. the third read results in the first element of NameWaveFile containing:

           "PT_1week.dat F_1week.dat " (NB no comma but two spaces)

in the first element and

            "F_1week.dat " (NB a space at the end)

in the second element.

My system is Visual Studio 2012 running a 64 bit version of the Intel Fortran 2013 compiler and the code is 64 bit.

The one that works is Visual Studio 2010 running a 32 bit version of the Intel Fortran compiler and the code is 32 bit.

Help gratefully received :-}  I suspect this is a bug in something rather than sensible behaviour

Thanks
Paul

0 Kudos
14 Replies
Simon_Geard
New Contributor I
1,209 Views

What is the declaration for NameWaveFile?

0 Kudos
andrew_4619
Honored Contributor II
1,209 Views

Reading the character data with a * format is a bit hit and miss. What are the rules for the file names? Are they separates by commas or spaces or both? Can file names have spaces? How long can a file name be?

Better to read into a large text buffer and then parse it or have one file name per line....

 

 

0 Kudos
Paul_C_5
Beginner
1,209 Views

Thank you all for your input!!  Problem is solved J

Well, the lesson learned it is an object one in never trusting anything – it transpires that the locals window in Visual Studio which display the values of LOCAL variables gets the string extent wrong and displays from the pointer  to the end of the whole string (strings being pointers I guess). Presumably a length byte is missed out or a terminator or something…… a..n..y..w..a..y

So, if the input line is A, B, C

Visual Studio displayed the values of the array as:

Arr(1)    =          A, B, C
Arr(2)    =          B, C
Arr(3)    =          C

 

In actual fact as far as the program itself is concerned the string array is completely valid so exposing Arr(2) in detail demonstrated its correct value - ie "B"

“Our doubts are traitors and make us lose the good we oft might win by fearing to attempt”  Wm. Shakespeare.

– but Visual Studio has just lost some my trust…  tune in next time to see how Visual Studio tries to regain some credibility in my eyes…!

Thanks for the help again! 

Paul

0 Kudos
andrew_4619
Honored Contributor II
1,209 Views

So how was NameWaveFile declared?

0 Kudos
Paul_C_5
Beginner
1,209 Views

It was declares as CHARACTER*13, DIMENSION(10) ::  NameWaveFile

Like many things this has gone all over the place now.  It transpires that the Visual Studio initial display of the array elements was correct but the detail one incorrect!  Subsequently accessing the names of the files in the program shows them to be wrong.

I'm wondering if this is because I am compiling to 64 bit from code that was originally written for 32 bit and missed out a configuration option on the compiler somewhere...

0 Kudos
mecej4
Honored Contributor III
1,209 Views

Perhaps the debugger is interpreting the strings as if they were C strings. If they were so, even if the strings are stored contiguously in memory, there would be null (Z'00') characters to terminate each string. If the debugger relies on the presence of those nulls instead of using the character variable length information, the symptoms that you saw would result.

A similar thing happens when you use the Unix/Linux/Cygwin strings command on an EXE/a.out file produced by compiling Fortran sources.

0 Kudos
Paul_C_5
Beginner
1,209 Views

That had occurred to me but I'm not sure what to do about it :-).

This is code that works with Visual Studio 2010 and Intel fortran 2011 on 32 bit.

Do you happen to know if there are any good resources somewhere about FORTRAN character string array handling in Intel Fortran 2013 (and possibly compiler switches to set to revert to 2011 :-)?

 

Thanks

Paul

0 Kudos
Steven_L_Intel1
Employee
1,209 Views

FORTRAN has been gone since 1991.

Nothing has changed in the way that Intel Fortran handles character strings. That the debugger stops displaying strings when it reaches a NUL is an issue I reported a long time ago but hasn't been fixed - possibly because it uses Visual Studio to display the strings and "everyone knows" that a string ends at a NUL.

0 Kudos
Paul_C_5
Beginner
1,209 Views

Gone since 1991? not here :-}  I think by making all variables that accessed the array the same size as the array elements (255) we have managed to get round the problem...  it's bound to happen again though.

0 Kudos
Steven_L_Intel1
Employee
1,209 Views

FORTRAN is gone since 1991. Fortran is here today.

0 Kudos
andrew_4619
Honored Contributor II
1,209 Views

Steve meant it is now officially Fortran not FORTRAN :-)

0 Kudos
Paul_C_5
Beginner
1,209 Views

 

:-) Gosh I hope I haven't offended anyone :-)!?  Not my intent - but it gives you some idea of the last time I actually used the language (coz it was FORTRAN then ;-)   I suppose these days that just looks like I'm shouting at the language.

I've asked the original developers to refactor their code so their character variables are the same length as the array elements. Seems to work!

Thanks for the help guys! It pointed me in the right direction !

0 Kudos
John_Campbell
New Contributor II
1,209 Views

I thought the standard delimiter for read (*,*) was a space and not a comma.

I'd suggest you try some alternative formats for your file names, to see what works with 64-bit, such as:

PT_1week.dat F_1week.dat        (use a space)

"PT_1week.dat","F_1week.dat"     ( enclose strings in double quotes)

"PT_1week.dat" "F_1week.dat"     ( use space and enclose string in quotes)

As another possibility, have you considered one line per file:

do N = 1,nWPoints
  READ (LunSte, *) NameWaveFile(N), XWPoint(N)
End do

John

0 Kudos
Paul_C_5
Beginner
1,209 Views

We already tried the space (same result) but haven't tried the others - great suggestions, thanks John!

0 Kudos
Reply