用不同的编译器读写fortran直接访问无格式文件 [英] Reading writing fortran direct access unformatted files with different compilers
问题描述
我在一个程序中有一个部分，它编写一个直接访问二进制文件，如下所示:
I have a section in a program that writes a direct-access binary file as follows:
open (53, file=filename, form='unformatted', status='unknown',
& access='direct',action='write',recl=320*385*8)
write (53,rec=1) ulat
write (53,rec=2) ulng
close(53)
这个程序是用 ifort 编译的.但是，如果我从使用 gfortran 编译的不同程序中读取数据文件，我将无法正确重建数据.如果读取数据的程序也是用ifort编译的，那么我就可以正确重构数据了.下面是读取数据文件的代码:
This program is compiled with ifort. However, I cannot reconstruct the data correctly if I read the data file from a different program compiled with gfortran. If the program reading the data is also compiled in ifort, then I can correctly reconstruct the data. Here's the code reading the data file:
OPEN(53, FILE=fname, form="unformatted", status="unknown", access="direct", action="read", recl=320*385*8)
READ(53,REC=2) DAT
我不明白为什么会这样?我可以用两个编译器正确读取第一条记录，如果我混合编译器，这是我无法正确重建的第二条记录.
I do not understand why this is happening? I can read the first record correctly with both compilers, it's the second record that I cannot reconstruct properly if I mix the compilers.
推荐答案
默认情况下，Ifort 和 gfortran 不使用相同的块大小作为记录长度.在 ifort 中，您的 open 语句中的 recl 的值是 4 字节块，因此您的记录长度不是 985,600 字节，而是 3,942,400 字节长.这意味着记录是以 390 万字节为间隔写入的.
Ifort and gfortran do not use the same block size for record length by default. In ifort, the value of recl in your open statement is in 4-byte blocks, so your record length isn't 985,600 bytes, it is 3,942,400 bytes long. That means the records are written at intervals of 3.9 million bytes.
gfortran 使用 1 字节的 recl 块大小，您的记录长度为 985,600 字节.当您读取第一条记录时，一切正常，但是当您读取第二条记录时，您查看文件中的 985,600 字节，但文件中的数据为 3,942,400 字节.这也意味着您在文件中浪费了大量数据，因为您只使用了文件大小的 1/4.
gfortran uses a recl block size of 1 byte and your record length is 985,600 byes. When you read the first record, everything works, but when you read the second record you look at 985,600 bytes into the file but the data is at 3,942,400 bytes into the file. This also means you are wasting a ton of data in the file, as you are using only 1/4 of its size.
有几种方法可以解决这个问题:
There are a couple ways to fix this:
- 在 ifort 中以 4 字节块指定 recl，例如
320*385*2而不是*8 - 在 ifort 中，使用编译标志
-assume byterecl将recl值解释为字节. - 在 gfortran 中补偿大小并使用
recl=320*385*32以便正确定位读取.
- In ifort specify recl in 4-byte blocks, e.g.
320*385*2instead of*8 - In ifort, use the compile flag
-assume bytereclto havereclvalues interpreted as bytes. - In gfortran compensate for the size and use
recl=320*385*32so that your reads are correctly positioned.
然而，更好的方法是在 recl 单元大小中设计不可知论.您可以使用 inquire 找出数组的 recl.例如:
A better way, however, is to engineer agnosticism in the recl unit size. You can use inquire to figure out the recl of an array. For example:
real(kind=wp), allocatable, dimension(:,:) :: recltest
integer :: reclen
allocate(recltest(320,385))
inquire(iolength=reclen) recltest
deallocate(recltest)
...
open (53, file=filename, form='unformatted', status='unknown',
& access='direct',action='write',recl=reclen)
...
OPEN(53, FILE=fname, form="unformatted", status="unknown", &
access="direct", action="read", recl=reclen)
这将根据编译器记录长度的基本单位将 reclen 设置为存储 320x385 数组所需的值.如果在编写和读取代码时使用此选项，则无需在 ifort 中使用编译时标志或补偿编译器之间的硬编码 recl 差异，即可与两个编译器一起使用.
This will set reclen to the value needed to store a 320x385 array based on the that compilers base unit for record length. If you use this when both writing and reading your code will work with both compilers without having to use compile-time flags in ifort or compensate with hardcoded recl differences between compilers.
program test
use iso_fortran_env
implicit none
integer(kind=int64), dimension(5) :: array
integer :: io_output, reclen, i
reclen = 5*8 ! 5 elements of 8 byte integers.
open(newunit=io_output, file='output', form='unformatted', status='new', &
access='direct', action='write', recl=reclen)
array = [(i,i=1,5)]
write (io_output, rec=1) array
array = [(i,i=101,105)]
write (io_output, rec=2) array
array = [(i,i=1001,1005)]
write (io_output, rec=3) array
close(io_output)
end program test
这个程序将一个由 5 个 8 字节整数组成的数组 3 次写入文件中的记录 1,2 和 3.该数组是 5*8 字节，我已将该数字硬编码为 recl 值.
This program writes an array of 5 8-byte integers 3 times to the file in records 1,2 and 3. The array is 5*8 bytes and I have hardcoded that number as the recl value.
我用命令行编译了这个测试用例:
I compiled this testcase with the command line:
gfortran -o write-gfortran write.f90
这会产生输出文件(用 od -A d -t d8 解释):
This produces the output file (interpreted with od -A d -t d8):
0000000 1 2
0000016 3 4
0000032 5 101
0000048 102 103
0000064 104 105
0000080 1001 1002
0000096 1003 1004
0000112 1005
0000120
5 个 8-bye 元素的数组被连续打包到文件中，记录号 2 (101 ... 105) 从我们期望的偏移量 40 处开始，即 recl5*8 文件中的值.
The arrays of 5 8-bye elements are packed contiguously into the file and record number 2 (101 ... 105) starts where we would expect it to at offset 40, which is the recl value in the file 5*8.
这是类似的编译:
ifort -o write-ifort write.f90
对于完全相同的代码，这会生成输出文件(用 od -A d -t d8 解释):
And this, for the exact same code, produces the output file (interpreted with od -A d -t d8):
0000000 1 2
0000016 3 4
0000032 5 0
0000048 0 0
*
0000160 101 102
0000176 103 104
0000192 105 0
0000208 0 0
*
0000320 1001 1002
0000336 1003 1004
0000352 1005 0
0000368 0 0
*
0000480
数据都在那里，但文件中充满了 0 值元素.以 * 开头的行表示偏移量之间的每一行都是 0.记录号 2 从偏移量 160 而不是 40 开始.注意 160 是 40*4，其中 40 是我们指定的 记录5*8.默认情况下，ifort 使用 4 字节块，因此 recl 为 40 意味着物理记录大小为 160 字节.
The data is all there but the file is full of 0 valued elements. The lines starting with * indicate every line between the offsets is 0. Record number 2 starts at offset 160 instead of 40. Notice that 160 is 40*4, where 40 is our specified recl of 5*8. By default ifort uses 4-byte blocks, so a recl of 40 means a physical record size of 160 bytes.
如果用 gfortran 编译的代码读取这个，记录 2,3 和 4 将包含所有 0 元素，读取记录 5 将正确读取由 ifort 作为记录 2 写入的数组.让 gfortran 读取文件中记录 2 的另一种方法是使用 recl=160 (4*5*4) 以便物理记录大小与 ifort 写入的大小相匹配.
If code compiled with gfortran were to read this, records 2,3 and 4 would contain all 0 elements and a read of record 5 would correctly read the array written as record 2 by ifort. An alternative to have gfortran read record 2 where it lies in the file would be to use recl=160 (4*5*4) so that the physical record size matches what was written by ifort.
这样做的另一个后果是浪费空间.过度指定 recl 意味着您使用 4 倍的必要磁盘空间来存储您的记录.
Another consequence of this is wasted space. Over-specifying the recl means you are using 4 times the necessary disk space to store your records.
编译为:
ifort -assume byterecl -o write-ifort write.f90
并产生输出文件:
0000000 1 2
0000016 3 4
0000032 5 101
0000048 102 103
0000064 104 105
0000080 1001 1002
0000096 1003 1004
0000112 1005
0000120
这会按预期生成文件.命令行参数 -assume byterecl 告诉 ifort 将任何 recl 值解释为字节而不是双字(4 字节块).这将产生与使用 gfortran 编译的代码相匹配的写入和读取.
This produces the file as expected. The command line argument -assume byterecl tells ifort to interpret any recl values as bytes rather than double words (4-byte blocks). This will produce writes and reads that match code compiled with gfortran.
program test
use iso_fortran_env
implicit none
integer(kind=int64), dimension(5) :: array
integer :: io_output, reclen, i
inquire(iolength=reclen) array
print *,'Using recl=',reclen
open(newunit=io_output, file='output', form='unformatted', status='new', &
access='direct', action='write', recl=reclen)
array = [(i,i=1,5)]
write (io_output, rec=1) array
array = [(i,i=101,105)]
write (io_output, rec=2) array
array = [(i,i=1001,1005)]
write (io_output, rec=3) array
close(io_output)
end program test
这个测试用例的唯一区别是我正在查询正确的 recl 来表示我的 40 字节数组(5 个 8 字节整数).
The only difference in this testcase is that I am inquiring the proper recl to represent my 40-byte array (5 8-byte integers).
gfortran 5.2:
gfortran 5.2:
Using recl= 40
ifort 16，没有选项:
ifort 16, no options:
Using recl= 10
ifort 16, -假设 byterecl:
ifort 16, -assume byterecl:
Using recl= 40
我们看到，对于 gfortran 和 ifort 使用的 1 字节块，byterecl 假设 recl 是 40，它等于我们的 40 字节数组.我们还看到，默认情况下，ifort 使用 10 的 recl，这意味着 10 个 4 字节块或 10 个双字，两者都意味着 40 字节.所有这三个测试用例都产生相同的文件输出，并且来自任一编译器的读/写都将正常运行.
We see that for the 1-byte blocks used by gfortran and ifort with the byterecl assumption that recl is 40, which equals our 40 byte array. We also see that by default, ifort uses a recl of 10, which means 10 4-byte blocks or 10 double words, both of which mean 40 bytes. All three of these testcases produce identical file output and read/writes from either compiler will function properly.
要在 ifort 和 gfortran 之间移植基于记录的、未格式化的直接数据，最简单的选择就是将 -assume byterecl 添加到 ifort 使用的标志中.您确实应该已经这样做了，因为您以字节为单位指定记录长度，所以这将是一个简单的更改，可能对您没有任何影响.
To have record-based, unformatted, direct data be portable between ifort and gfortran the easiest option is to just add -assume byterecl to the flags used by ifort. You really should have been doing this already since you are specifying record lengths in bytes, so this would be a straightforward change that probably has no consequences for you.
另一种选择是不用担心该选项并使用 inquire 内在函数来查询数组的 iolength.
The other alternative is to not worry about the option and use the inquire intrinsic to query the iolength for your array.
这篇关于用不同的编译器读写fortran直接访问无格式文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
