Solving FORTRAN Compiler Issues with Different Outputs

[shitij]

Hi all !

This is a weird problem. A simple program to read a file and display it works differently when compiled with different versions of the same compiler.

When I compile it as:

garbageij@garbageij:~/NMA$ mpif90 exp4.f90

and run it, it gives the correct output. But when I compile it as:

garbageij@garbageij:~/NMA$ /home/garbageij/Lib/MPI/mpich2-1.3.2/bin/mpif90 exp4.f90

and run it, the output is incorrect. Like a few lines are missing altogether, some lines are read half-way, for example:
The line

ATOM    NE2     NR2    -0.70

is always read as

ATOM    NE2    -0.70

.
Please note that in the actual program I am using some libraries (PETSc/SLEPc) which are configured to use the second version of the compiler. So I can't just use a different compiler and get it over with.
Also, it seems as if the discrepancies in output also remain the same after any compile-->run, so it probably isn't some random occurrence. Also, I re-installed MPICH2 in another directory, and if I use that version's mpif90, the problem remains the same. (even the discrepancy in the output remains the same)

I am giving the code below:

program exp4
implicit none

	character(79)::line
	
	open(unit=1,file='top_all27_prot_na_RTF.txt',action='read',ACCESS='STREAM',FORM='FORMATTED')

	do
	read(1,'(a)',END=10)line   ! Read line as string
	write(*,*)line
	enddo
	10 write(*,*)'Done !'
		
end program exp4

I am totally clueless. Any ideas?

EDIT: I just remembered that MPICH2 is configured to use ifort only. When I compiled it with ifort and ran it, it really was giving incorrect output ! When I compiled it with gfortran, the output was fine. Is this some sort of bug with ifort?

 

[jedishrfu]

are you sure they are reading the same file? like can you change the offending line and see it in the output ie change ATOM to ATXM and see what you get.

it looks very odd that the third text field is different.

Ive seen differences in C code when a program library was compiled using double byte enabled but the program code wasn't. Data appeared to get changed when calling a function in the library. double byte meant that all numbers where stored on even byte boundaries.

 

[shitij]

Yes. Actually the code above is in a file "exp4.f90".

I am simply doing:

gfortran exp4.f90
./a.out > gfortOP.txt

ifort exp4.f90
./a.out > ifortOP.txt

Then I compare the files gfortOP.txt and ifortOP.txt by diff/sdiff. So this way they are guaranteed to read the same files. (the source code is the same !)
This is mindboggling. I can't think of any reason why this is happening...

EDIT:
I changed one of the ATOM to ATXM, and this change is reflected in both the outputs. So they are reading the same file.

 

[jedishrfu]

next thought is there some hidden control character in the file such as a tab or is it just spaces.

as an example say the conrol character was a sequence of backspace characters then they could erase the third field (as is sometimes used in password entry in a command shell) so that one fortran passes it thru to output and the other just throws it away.

you'd need to print the line in octal or hex to see it.

also can you use a formatted write to explicitly print the line of text? it may come out correctly then.

write(*,'(A)') line

 

[shitij]

Thank you for your reply !

I posted the problem on the intel forums also, and somebody verified that for the input file, ifort version 11.0.xx gives the problem. So it definitely was a problem with the compiler only. But they said that ifort version 11.0 was quite old and updating will solve the problem. Somebody verified this by running the program on the input file on ifort 12.1.4. Also, he said that if I remove access='steam', the program will work on 11.0 also.

The thread is present here, with some more information, including possible cause of this (which I didnt understand)
http://software.intel.com/en-us/forums/showthread.php?t=106066

For now, I have just switched to gfortran (after much painstaking work for reinstalling all the libraries again). The new intel's fortran is quite a big download (~400MB) for my internet connection. I prefer intel's for performance, so I will make the switch again later.

Thanks !

 

[AlephZero]

I suggest you carefully read the compiler documentation or a Fortran tutorial about what ACCESS= 'STREAM' is for. That should explain why you don't want to use it. There are VERY few situations when ACCESS='STREAM',FORM='FORMATTED' is useful, and this isn't one of them.

I don't think your "wrong output" is a bug at all. The program is doing what you told it to do. It is copying exactly 79 characters from the existing file, regardless of how long the lines were (and including any existing "end of line" characters in the count of 79), and then writing them with an extra "end of line" after them.

It's not surprising that gives the appearance of "reading some lines half way", etc, unless every line of the input file was exactly 78 characters long if its "end of line" data follows Unix conventiions, or 77 characters if was a Mac or Windows file.

 

[shitij]

Well yeah, I am a little new to fortran and I saw an example on the internet to see how files have to be read as strings (line by line) and there the file was opened with access='stream' and form='formatted'. I didn't bother reading about why that was done, but I guess that came back to haunt me here. I'll take you up on that suggestion though.

Also, the thing is, that with the same source code, gfortran produces "correct" output, but ifort doesn't. So unless it is the case that using access='stream' in a fortran program makes the behavior of the program compiler dependent, it is (*was*, now it's fixed I guess) a bug.
Also 79 is not important here, as line truncation is not the problem. In the input file all useful information ends at around 40 (some lines are comments that extend beyond). Also, even if you replace 79 by 150 or 300 (which is definitely much more characters than any line has), ifort still gives incorrect output, but gfortran gives correct one.
I wanted to attach the input file here, but its size goes beyond the attachment limit.

Thanks !