Numbers are wrong when reading the same binary file from a different machine by ifort

[tian2]

Hi, I'm trying to read the same binary file with the same program from a different machine. The read numbers are not right but like some uninitialized values. I have tried convert='big_endian' or 'little_endian', but it doesn't work.  

The reading program is :

        NRECL=4

        KSIZE=2036

        IRECSZ=NRECL*KSIZE 

        lfn=get_valid_unit(10)

        OPEN(lfn,FILE='jpleph_de405',ACCESS='DIRECT',FORM='UNFORMATTED'

     .     ,RECL=IRECSZ,STATUS='OLD',err=200)

        READ(lfn,REC=1) HD%TTL,HD%CNAM,HD%SS,HD%NCON,HD%AU,HD%EMRAT,

     .     ((HD%IPT(I,J),I=1,3),J=1,12),HD%NUMDE,(HD%IPT(I,13),I=1,3)

        READ(lfn,REC=2) HD%CVAL

with HD defined by:

     

        type jpleph_header

           integer*4 numde,ncon,ipt(3,13)

           character*6 cnam(400),TTL(14,3)

           double precision cval(400),ss(3),au,emrat

        end type

and the compiling command is 

 ifort  -w -m64 -g -132  -fpscomp ioformat 

The binary file is attached to the post. This reading program works well on my laptop but goes wrong when I use the desktop computer. 

Could you provide some suggestions? Thanks

[mecej4 · Accepted solution]

You need to provide a lot of missing information for someone to try to reply. For instance, what is the difference between the runtime environments on your laptop and desktop -- OS, CPU, compiler used, compiler options?

Alternatively, since the data file being read has a well-established pedigree (JPL Planetary and Lunar Ephemerides) and for which there is voluminous documentation, one could attempt to read that documentation to obtain/reason out the missing information.

My hunch is that you should probably use the compiler option -assume byterecl (or use the corresponding clause in the OPEN statement for the file).

You stated that you used the -fpscomp ioformat option. Why? The Intel Ifort documentation merely says "For unformatted READ statements, the unformatted file semantics are dictated according to the Fortran PowerStation
documentation; see the Fortran PowerStation documentation for more detailed information". I don't have the old FPS documentation at hand.

With the -assume byterecl compiler option, I see the value of HD%CVAL(1) as 405.00; without that option, the unit for record length is 4 bytes, and HD%CVAL(1) is 2436976.50. Which of these two values strikes you as correct? Or are both values wrong?

Unless you know that the file was written on a big-endian computer (or on a computer that is emulating big-iron), the option "convert=..." should not be used.

[tian2]

Thanks for your reply. I found it is the recl matter. The results are correct when I regenerated the file on the desktop computer and read it on the same computer. The OS on both computers are ubuntu and the cpu is intel xeon for the desktop and i7 for the laptop.  The problem about this file is solved. The  -assume byterecl option can well solve the 'write and read' problem on the same machine. Thanks a lot.