- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I am reading an integer array in a a binary file in my routines. It is working with Intel Fortran 11.1 073.
I installed ifort v12 on Ubuntu 10.04 x64. Now the exact same code reads totally different values from the binary file. It's all implicit none and should be quite compiler-independent I add the source code (see "write (*,*) "id " , (id(i) ,i= 1,numnp*ndofn)") and the file from where I read.
I am reading an integer array in a a binary file in my routines. It is working with Intel Fortran 11.1 073.
I installed ifort v12 on Ubuntu 10.04 x64. Now the exact same code reads totally different values from the binary file. It's all implicit none and should be quite compiler-independent I add the source code (see "write (*,*) "id " , (id(i) ,i= 1,numnp*ndofn)") and the file from where I read.
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unformatted I/O may never be assumed to be compiler-independent. However, that is probably not the source of the problem here.
Secondly, when a program that was working with version X of the compiler stops working with version X+1, the cause may be a bug in the new version. However, more often it is a bug in the source code that is now exposed by the new version because of a change in the way that code is generated or variables laid out in memory.
If you provide a short program that calls the subroutine with argument values that match those used for writing the file, someone may be able to help you. Few people want to guess how an unformatted file was written.
Secondly, when a program that was working with version X of the compiler stops working with version X+1, the cause may be a bug in the new version. However, more often it is a bug in the source code that is now exposed by the new version because of a change in the way that code is generated or variables laid out in memory.
If you provide a short program that calls the subroutine with argument values that match those used for writing the file, someone may be able to help you. Few people want to guess how an unformatted file was written.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The program writing the file is being compiled with several tools: gfortran, portrland fortran, and intel fortran. In all the cases it was working previously. So that's why I was guessing it's more of an issue with how the file is read than how it's written
The routines writing the binary files are "old-and-ugly" F77, please find attached an example. Note that doing a write(*,*) of the incriminated matry of integers in thir routine gives exactly the good values Then again might be a formatting issue
Thanks for the help.
The routines writing the binary files are "old-and-ugly" F77, please find attached an example. Note that doing a write(*,*) of the incriminated matry of integers in thir routine gives exactly the good values Then again might be a formatting issue
Thanks for the help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So far you have shown source code for a module, and for a subroutine with over 70 arguments. That's not enough to compile and run the program. Trying to divine why the contents of a Fortran unformatted file are what they are, without knowing with which program+compiler combination the file was written, is something which humans are not good at.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As you said, there is a lot of arguments, so exctracting a "simple" program to showcase what values were written in the unformatted file is not straightforward
The way the file is written and read has been working well with several gfortran, portland fortran and intel fortran in the past That is why I thought it could have something to do with a new way formatted input & output are dealt with in ifort 12.
Anyways, thank you for your time. We have reverted to ifort 11 in order to keep things running.
The way the file is written and read has been working well with several gfortran, portland fortran and intel fortran in the past That is why I thought it could have something to do with a new way formatted input & output are dealt with in ifort 12.
Anyways, thank you for your time. We have reverted to ifort 11 in order to keep things running.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Leo,
I'm glad it's working again with 11.1. that would have been my next suggestion - using 11.1 on the new system.
There should not be any differences in formattted IO in 12.0, other than the newer F08 G edit descriptor (which you probably are not using). So there could be a bug. I searched the database and there is nothing reported similar to this - but 12.0 is still quite new. I will keep an eye out for similar reports. If there is a bug, surely it will surface, hopefully in a simplier code that is easier to send into us.
I understand the code is complex, but if you can get a reproducing testcase at some point we'd be happy to have a look.
ron
I'm glad it's working again with 11.1. that would have been my next suggestion - using 11.1 on the new system.
There should not be any differences in formattted IO in 12.0, other than the newer F08 G edit descriptor (which you probably are not using). So there could be a bug. I searched the database and there is nothing reported similar to this - but 12.0 is still quite new. I will keep an eye out for similar reports. If there is a bug, surely it will surface, hopefully in a simplier code that is easier to send into us.
I understand the code is complex, but if you can get a reproducing testcase at some point we'd be happy to have a look.
ron

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page