CFD Online Discussion Forums - read unformatted file in windows and linux

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- Main CFD Forum (https://www.cfd-online.com/Forums/main/)

- - read unformatted file in windows and linux (https://www.cfd-online.com/Forums/main/7921-read-unformatted-file-windows-linux.html)

read unformatted file in windows and linux

I want to read unformatted files which are generated in windows system directly in linux for the use of my fortran code. however, i ger error. only by convert the files into formatted files in windows and then read in linux and convert to unformatted. but the size of the files are terrible and time-expensive when i ftp it to linux. how i can convert between different systems with unformatted files for fortran? thanks

Re: read unformatted file in windows and linux

What Fortran calls "unformatted" data is referred to in other languages (VB, C) as "binary" data. I assume your precision is already matched on both platforms, i.e. if you use 32-bit integers in Windows you should be reading 32-bit integers in Linux, ditto for 64-bit floating point numbers (double precision). Older Fortran code such as Plot3D uses 32-bit floating point (single precision). So you have to know exactly what the precision is for integers and floating point numbers before you attempt to transfer your binary data from one platform to another.

But there is another catch: Windows and Linux store the bytes (8-bit) within each word (Word16, Word32, Word64) in reverse order. Therefore you need to reverse the bytes in your binary Windows file before you read it into a program running on a Linux system.

Below is a routine that converts a mesh file saved on a Windows machine, so it can be read by Plot3D on a Linux computer. In this routine, Imax, Jmax, Kmax are 32-bit integers and PX(), PY(), PZ() are 32-bit floating point numbers. The routine is written in Visual Basic, but you should be able to read the code and follow the logic of reversing bytes within each 32-bit word.

(Sorry, but I don't seem to be able to preserve the formatting of my code on this text page)

(Declarations)

Public Imax As Long Public Jmax As Long Public Kmax As Long

Public PX() As Single Public PY() As Single Public PZ() As Single

Public Type Word32

Byte1 As String * 1

Byte2 As String * 1

Byte3 As String * 1

Byte4 As String * 1 End Type

Public LongGet As Word32 Public LongPut As Word32

(End Declarations)

Public Sub SavePlot3D_XYZ(FileName As String)

Open FileName For Binary As #1

Put #1, , Imax

Put #1, , Jmax

Put #1, , Kmax

For k = 1 To Kmax

For j = 1 To Jmax

For i = 1 To Imax

Put #1, , PX(i, j, k)

Next i

Next j

Next k

For k = 1 To Kmax

For j = 1 To Jmax

For i = 1 To Imax

Put #1, , PY(i, j, k)

Next i

Next j

Next k

For k = 1 To Kmax

For j = 1 To Jmax

For i = 1 To Imax

Put #1, , PZ(i, j, k)

Next i

Next j

Next k

Close #1

Open FileName For Binary As #1

NB = 1

Do While Not EOF(1)

Get #1, NB, LongGet

LongPut.Byte1 = LongGet.Byte4

LongPut.Byte2 = LongGet.Byte3

LongPut.Byte3 = LongGet.Byte2

LongPut.Byte4 = LongGet.Byte1

Put #1, NB, LongPut

NB = NB + 4

Loop

Close #1

End Sub

Please read this response - HTML Version

<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head> <meta http-equiv=Content-Type content="text/html; charset=windows-1252"> <meta name=ProgId content=Word.Document> <meta name=Generator content="Microsoft Word 11"> <meta name=Originator content="Microsoft Word 11"> <link rel=File-List href="What%20Fortran%20calls_files/filelist.xml"> <title>What Fortran calls "unformatted" data is referred to in other languages (VB, C) as "binary" data</title>  <style>

</style>  </head>

<body lang=EN-US style='tab-interval:.5in'>

<div class=Section1>

What Fortran calls "unformatted" data is referred to in other languages (VB, C) as "binary" data. I assume your precision is already matched on both platforms, i.e. if you use 32-bit integers in Windows you should be reading 32-bit integers in Linux, ditto for 64-bit floating point numbers (double precision). Older Fortran code such as Plot3D uses 32-bit floating point (single precision). So you have to know exactly what the precision is for integers and floating point numbers before you attempt to transfer your binary data from one platform to another. But there is another catch: Windows and Linux store the bytes (8-bit) within each word (Word16, Word32, Word64) in reverse order. Therefore you need to reverse the bytes in your binary Windows file before you read it into a program running on a Linux system. Below is a routine that converts a mesh file saved on a Windows machine, so it can be read by Plot3D on a Linux computer. In this routine, Imax, Jmax, Kmax are 32-bit integers and PX(), PY(), PZ() are 32-bit floating point numbers. The routine is written in Visual Basic, but you should be able to read the code and follow the logic of reversing bytes within each 32-bit word. (Declarations) Public Imax As Long******* ' 32-bit integer Public Jmax As Long Public Kmax As Long Public PX() As Single******* ' 32-bit floating point Public PY() As Single Public PZ() As Single Public Type Word32 ** Byte1 As String * 1 ** Byte2 As String * 1 ** Byte3 As String * 1 ** Byte4 As String * 1 End Type Public LongGet As Word32 Public LongPut As Word32 (End Declarations) Public Sub SavePlot3D_XYZ(FileName As String) *** ** Open FileName For Binary As #1 ** Put #1, , Imax ** Put #1, , Jmax ** Put #1, , Kmax ***** ** For k = 1 To Kmax ***** For j = 1 To Jmax ******** For i = 1 To Imax *********** Put #1, , PX(i, j, k) ******** Next i ***** Next j ** Next k ****** ** For k = 1 To Kmax ***** For j = 1 To Jmax ******** For i = 1 To Imax *********** Put #1, , PY(i, j, k) ******** Next i ***** Next j ** Next k ****** ** For k = 1 To Kmax ***** For j = 1 To Jmax ******** For i = 1 To Imax *********** Put #1, , PZ(i, j, k) ******** Next i ***** Next j ** Next k * ** Close #1 * ** Open FileName For Binary As #1 ********** ** NB = 1 ********** ** Do While Not EOF(1) ** ***** Get #1, NB, LongGet ***** ***** LongPut.Byte1 = LongGet.Byte4 ***** LongPut.Byte2 = LongGet.Byte3 ***** LongPut.Byte3 = LongGet.Byte2 ***** LongPut.Byte4 = LongGet.Byte1 ***** ***** Put #1, NB, LongPut ***** ***** NB = NB + 4 ***** ** Loop ****** ** Close #1 End Sub<o:p></o:p>

<o:p>*</o:p>

</div>

</body>

</html>

Re: read unformatted file in windows and linux

The unformatted->formatted->unformatted conversion process that you have had to use is the only guaranteed method to migrate unformatted files from one "system" to another. However, the compilers involved are more important than the systems involved. The other poster brings up byte ordering, but byte ordering is a architecture issue, not an OS issue. Most linux and windows systems are running on Intel hardware that has consistent byte ordering, so I think it is unlikely that this is the root problem. It is more likely that the compilers that you are using do not have compatible unformatted files. If you are using g77 (and even if you aren't), you might want to take a look at:

http://gcc.gnu.org/onlinedocs/gcc-3....ted-Files.html

Hope that this helps,

jason

Re: read unformatted file in windows and linux

thank for your help! i transfer data from windows to linux. as in my code,the grid and field solutions are saved in plot3d format.as you said, i compile code in linux with F77 not, g77. in addition. i meet some problems that is read unformmated data files writen in fortran power station compiles, but be read in code compiled in visual fortran 6.5. the same problem appear. i can't read the files.so i agree with your opinion on the compiler.But is there another way? if g77 is the best choise, what i can do ?

Correction: Byte Ordering

The byte ordering is a matter of architecture as the other poster correctly points out. So if you are running Linux on an Intel, you don't need to reverse the bytes. It has been a few years, since I wrote this conversion routine, so I forgot and confused some of the details. I believe I ran Plot3D on a Sun workstation which had an Alpha processor.

I did follow the link provided in the previous post, and I find it to be somewhat misleading in the following statement:

"The record length is of C type long; this means that it is 8 bytes on 64-bit systems such as Alpha GNU/Linux and 4 bytes on other systems, such as x86 GNU/Linux. Consequently such files cannot be exchanged between 64-bit and 32-bit systems, even with the same basic number format."

Intel processors can read either 32-bit (single precision) or 64-bit (double precision) floating point numbers. So as long as you reverse the byte order when transferring from an Alpha to an Intel machine, you should have no problem with the overall conversion. Incidentally, all math operations on Intel (co)processors are carried out in 80-bit precision internally. Thus classifying an Intel as a 32-bit "only" processor is a bit of an understatement in my opinion.

Re: read unformatted file in windows and linux

The problem may be that your read statements in your fortran code are not identical to the write statements that created the file. FORTRAN adds record markers into the unformatted output at the beginning and end of each unformatted write. If read statements do not correspond correctly you will generally get an error.

Also when you transfer from windows to linux are you using ftp with the binary flag correctly set? If a binary file is transfered as ascii it's likely to be corrupted.

Re: read unformatted file in windows and linux

Well, (in my opinion) there is no best choice if you must stay with the plot3d format. Some compilers (and OS's like the Cray OS's) have facilities that will allow for easier transition from compiler to compiler and system to system. Unless you have access to this sort of facility, you really can't avoid doing some programming in a language other than f77. The safest, easiest, and most portable option is to do the conversion to formatted (being careful to preserve as much precision as possible) and compress the formatted file if you have to keep it around.

jason