- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What is the declaration for NameWaveFile?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So how was NameWaveFile declared?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FORTRAN is gone since 1991. Fortran is here today.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve meant it is now officially Fortran not FORTRAN :-)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
:-) 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 !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We already tried the space (same result) but haven't tried the others - great suggestions, thanks John!
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page