Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.
27152 Discussions

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

tian2
Beginner
423 Views

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
 
Labels (2)
0 Kudos
1 Solution
mecej4
Black Belt
382 Views

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.

View solution in original post

2 Replies
mecej4
Black Belt
383 Views

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
Beginner
325 Views

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. 

Reply