Unformatted read on switch to Parallel Composer

[bflynt]

Today I switched from the V11.1 intel fortran compiler to the one which comes with the newest Parallel Composer suite. After a simple install and setting all the environment variables to the new suite I cannot correctly read my fortran unformatted files written with the previous version. The read completes but the data is corrupted. My initial thought was an Endiannes problem but that doesn't seem to resolve it.

Has the F_UFMTENDIAN environment flag been replaced with something else?
I previously had 'F_UFMTENDIAN=big' and I've kept that setting in the new install. I tried setting it to 'little' just to see if it helped but then it wouldn't even complete the read and resulted in a "Stack trace terminated abnormally" error.

I've checked the files by switching back to the V11.1 paths, recompiling and the files read fine.

Any Ideas???

My OS system:
OpenSuse 11.3 64 bit

Compiler & Flags:
ifort -check bounds -check pointers -traceback

Bryan

[mecej4]

Because there are several ways of choosing endianness for unformatted files, these ways interact, and not all apply if there are derived-types in your READ/WRITE statements, it would help narrow things down if you present a short example with which you show that the two compiler versions are unable to produce/consume unformatted files that can be used interchangeably.

[bflynt]

OK.
So I tried to duplicate the error using a small piece of code to no avail. It did however figure out the fix but not sure what the problem is/was. I'll post problem and my solution incase anyone else comes across something simular.

----- Problem Code ------


The array is defined as:
type GridType
integer(ip) :: NFace
integer(ip), dimension(:,:), pointer :: FaceToElement => NULL()
end type GridType

Where:
integer, parameter :: ip = selected_int_kind( r = 5 )

The array is allocated like this:
allocate( Grid%FaceToElement(2,NFace), stat = error)

I write it to file with:
open(FID,file=Fname,status='unknown',form='unformatted', &
action='write',iostat=error)
write(FID) Grid%FaceToElement(1:2,1:Grid%NFace)

Read it back with (in different program):
open(FID,file=Fname,status='unknown',form='unformatted', &
action='read',iostat=error)
read(FID) Grid%FaceToElement(1:2,1:Grid%NFace)

The array read completes but the integer values are all scrambled up. When I create a smaller test program using the same strucure it works fine so there must be something the larger program introduces.

--------- The fix ---------

Allocate the array as:
allocate( Grid%FaceToElement(2_ip,NFace), stat = error)

Notice the _ip after the 2. Not sure why, but in my larger program putting the _ip in then compiling with v12 allows me to read the files I created wihtout the _ip using v11.1. Using v11.1 I can read/write using _ip or not using _ip it makes no difference.

Bryan

[mecej4]

You are using the environmental variable F_UFMTENDIAN in an unsupported context: unformatted I/O of derived type variables. Any workaround that may work now may fail with the next release. Therefore, you need to look for a better solution. That the unsupported usage gave you correct results with a certain release of the compiler means little.

Several better solutions present themselves.

[bflynt]

OK from your last comment I'm starting to understand the problem more.

Would a better solution be to use a temporary array to read/write the data by coping it from the derived data type? Something like this.

Temporary Array:
integer(ip), dimension(2,Grid%NFace) :: FaceToElement

Then read using temporary:
read(FID) FaceToElement

Then copy back to derived type:
Grid%FaceToElement(1:2,1:Grid%NFace) = FaceToElement(1:2,1:Grid%NFace)

This works on v12 but seems rather wastefull.
I was under the assumption that specifying the array to read/write within the derived data type (using %) would have told the compiler to read/write that portion of the data just like a standard array.

Thanks for the help,
Bryan

[mecej4]

I was under the assumption that specifying the array to read/write within the derived data type (using %) would have told the compiler to read/write that portion of the data just like a standard array.

That is what I would expect, too.

Let's look at a different question: do you need to do frequent data exchange between little- and big-endian processors through unformatted files? If not, and you need only to read old files that were written on a big-endian machine, would it not be a better solution to do a one-time conversion as to endianness, and benefit from the compiler-independence that results?