Home > Archive > Fortran > November 2007 > Reading binary file generated from 32-bit machine using 64-bit
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Reading binary file generated from 32-bit machine using 64-bit
|
|
| yonas_kassa@hotmail.com 2007-11-25, 4:36 am |
| Hi all,
I am sorry if i come up with elementary question but i spend two days
trying to figure out how to read a binary file generated by gfortran
on a 32 bit i386 machine using a 64 bit x86_64 machine. i tried to use
the flag -frecord-marker=4 to change the default from 8 to 4 bytes on
64 bits machine. However, this still doesn't seem to work. I just
can't read the binary file despite so many different trial. Can you
please help me what to do?
Thanks all,
Yonas
| |
| yonas_kassa@hotmail.com 2007-11-25, 7:14 pm |
| On Nov 25, 3:54 am, Thomas Koenig <tkoe...@netcologne.de> wrote:
> On 2007-11-25, yonas_ka...@hotmail.com <yonas_ka...@hotmail.com> wrote:
>
>
> Please give some details about the machines you are running on.
>
> Which versions of gfortran do you use on the two machines?
>
> What operating systems do you use?
>
> The default for record markers was changed to four bytes from
> (mostly) eight bytes with gfortran 4.2.0. If either of your
> systems uses 4.1.*, you'll need to specify -frecord-marker=8
> for gfortran 4.2.* .
>
>
> What exactly does "doesn't work" mean?
>
> Are you getting error messages / reading in the wong data / ???
>
> Can you provide a simple example that we can corss-check?
Thanks Thomas,
I am using x86_64-suse-linux operating system. The gfortran version
is 4.1.2. The binary file (i am tried to read) was generated using
Fedora Core 6 linux on 32-bit i386 machine with the same gfortran
version.
> What exactly does "doesn't work" mean?
When i complied the codes i added flag -frecord-marker=4 thinking that
will change the default from 8 to 4 bytes on my 64 bits machine.
The error message is: Fortran runtime error: End of file
Thanks again.
Yonas
| |
| Louis Krupp 2007-11-25, 7:14 pm |
| yonas_kassa@hotmail.com wrote:
> On Nov 25, 3:54 am, Thomas Koenig <tkoe...@netcologne.de> wrote:
>
> Thanks Thomas,
>
> I am using x86_64-suse-linux operating system. The gfortran version
> is 4.1.2. The binary file (i am tried to read) was generated using
> Fedora Core 6 linux on 32-bit i386 machine with the same gfortran
> version.
>
>
> When i complied the codes i added flag -frecord-marker=4 thinking that
> will change the default from 8 to 4 bytes on my 64 bits machine.
>
> The error message is: Fortran runtime error: End of file
Some (possibly stupid) questions:
The term "binary file" can be ambiguous; are we talking about an
unformatted file?
Have you run the program that reads the file on a 32-bit machine? If
so, does it work? If you haven't run the program before, is it possible
that the problem has nothing to do with the length of the record marker?
If you haven't written a program that just reads the first record into
an array and prints the results, you might want to try that just to see
if it works.
Louis
| |
| yonas_kassa@hotmail.com 2007-11-25, 7:14 pm |
| On Nov 25, 1:31 pm, Louis Krupp <lkr...@pssw.nospam.com.invalid>
wrote:
> yonas_ka...@hotmail.com wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
> Some (possibly stupid) questions:
>
> The term "binary file" can be ambiguous; are we talking about an
> unformatted file?
>
> Have you run the program that reads the file on a 32-bit machine? If
> so, does it work? If you haven't run the program before, is it possible
> that the problem has nothing to do with the length of the record marker?
>
> If you haven't written a program that just reads the first record into
> an array and prints the results, you might want to try that just to see
> if it works.
>
> Louis- Hide quoted text -
>
> - Show quoted text -
Hi Louis,
I think you understood my problem well enough. In fact the file is
unformated with four bytes record length before and after each data.
In the case of binary file, i think we don't have those record lengths
and the file is treated as a continuous stream of bytes.
Yes Louis, i run the program on 32-bit machine using same gfortran and
it works well (i.e. the program can read the unformatted file
properly).
Yonas
| |
| Louis Krupp 2007-11-25, 7:14 pm |
| yonas_kassa@hotmail.com wrote:
> On Nov 25, 1:31 pm, Louis Krupp <lkr...@pssw.nospam.com.invalid>
> wrote:
>
> Hi Louis,
>
> I think you understood my problem well enough. In fact the file is
> unformated with four bytes record length before and after each data.
> In the case of binary file, i think we don't have those record lengths
> and the file is treated as a continuous stream of bytes.
>
> Yes Louis, i run the program on 32-bit machine using same gfortran and
> it works well (i.e. the program can read the unformatted file
> properly).
I have no clue, just more (possibly stupid) questions:
Can you dump the first few bytes of your input file and post them? (I
would use "od -txC input_file | head".)
Do you have a program that just reads the first record into an array and
prints it?
Louis
| |
| yonas_kassa@hotmail.com 2007-11-25, 7:14 pm |
| On Nov 25, 2:42 pm, Louis Krupp <lkr...@pssw.nospam.com.invalid>
wrote:
> yonas_ka...@hotmail.com wrote:
>
>
>
>
>
>
>
>
>
> I have no clue, just more (possibly stupid) questions:
>
> Can you dump the first few bytes of your input file and post them? (I
> would use "od -txC input_file | head".)
>
> Do you have a program that just reads the first record into an array and
> prints it?
>
> Louis- Hide quoted text -
>
> - Show quoted text -
Hi,
Here is the first record of the file generated following your
suggustion. May be you can make sense out of it but i have no clue.
Thanks again
Yonas
0000000 34 00 00 00 02 00 00 00 0c 00 00 00 00 00 00 00
0000020 40 6f 44 41 00 00 00 00 38 13 7e 41 20 20 20 20
0000040 20 20 20 20 20 20 20 20 48 45 41 44 46 01 00 00
0000060 a5 00 00 00 01 00 00 00 34 00 00 00 f0 90 06 00
0000100 00 00 00 00 00 38 8f c0 00 00 00 00 00 38 8f c0
*
0014440 e1 7a 14 ae 47 58 a7 40 8f c2 f5 28 dc 4b a7 40
0014460 85 eb 51 b8 9e 3b a7 40 cd cc cc cc 4c 2b a7 40
0014500 00 00 00 00 00 1b a7 40 b8 1e 85 eb d1 0a a7 40
0014520 00 00 00 00 80 fa a6 40 52 b8 1e 85 eb e9 a6 40
| |
| yonas_kassa@hotmail.com 2007-11-25, 7:14 pm |
| On Nov 25, 2:42 pm, Louis Krupp <lkr...@pssw.nospam.com.invalid>
wrote:
> yonas_ka...@hotmail.com wrote:
>
>
>
>
>
>
>
>
>
> I have no clue, just more (possibly stupid) questions:
>
> Can you dump the first few bytes of your input file and post them? (I
> would use "od -txC input_file | head".)
>
> Do you have a program that just reads the first record into an array and
> prints it?
>
> Louis- Hide quoted text -
>
> - Show quoted text -
Hi,
Here is the first record generated following your suggustion. May be
you can make a sense out of it but i am still clueless.
Thanks again
Yonas
0000000 34 00 00 00 02 00 00 00 0c 00 00 00 00 00 00 00
0000020 40 6f 44 41 00 00 00 00 38 13 7e 41 20 20 20 20
0000040 20 20 20 20 20 20 20 20 48 45 41 44 46 01 00 00
0000060 a5 00 00 00 01 00 00 00 34 00 00 00 f0 90 06 00
0000100 00 00 00 00 00 38 8f c0 00 00 00 00 00 38 8f c0
*
0014440 e1 7a 14 ae 47 58 a7 40 8f c2 f5 28 dc 4b a7 40
0014460 85 eb 51 b8 9e 3b a7 40 cd cc cc cc 4c 2b a7 40
0014500 00 00 00 00 00 1b a7 40 b8 1e 85 eb d1 0a a7 40
0014520 00 00 00 00 80 fa a6 40 52 b8 1e 85 eb e9 a6 40
| |
| yonas_kassa@hotmail.com 2007-11-25, 7:14 pm |
| On Nov 25, 4:50 pm, yonas_ka...@hotmail.com wrote:
> On Nov 25, 2:42 pm, Louis Krupp <lkr...@pssw.nospam.com.invalid>
> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi,
>
> Here is the first record of the file generated following your
> suggustion. May be you can make sense out of it but i have no clue.
>
> Thanks again
>
> Yonas
>
> 0000000 34 00 00 00 02 00 00 00 0c 00 00 00 00 00 00 00
> 0000020 40 6f 44 41 00 00 00 00 38 13 7e 41 20 20 20 20
> 0000040 20 20 20 20 20 20 20 20 48 45 41 44 46 01 00 00
> 0000060 a5 00 00 00 01 00 00 00 34 00 00 00 f0 90 06 00
> 0000100 00 00 00 00 00 38 8f c0 00 00 00 00 00 38 8f c0
> *
> 0014440 e1 7a 14 ae 47 58 a7 40 8f c2 f5 28 dc 4b a7 40
> 0014460 85 eb 51 b8 9e 3b a7 40 cd cc cc cc 4c 2b a7 40
> 0014500 00 00 00 00 00 1b a7 40 b8 1e 85 eb d1 0a a7 40
> 0014520 00 00 00 00 80 fa a6 40 52 b8 1e 85 eb e9 a6 40- Hide quoted text -
>
> - Show quoted text -
Here is the corresponding array:
2 925 2678400.00000000 2461471200.00000 Head 326 165 1
| |
| Louis Krupp 2007-11-25, 7:14 pm |
| yonas_kassa@hotmail.com wrote:
> On Nov 25, 4:50 pm, yonas_ka...@hotmail.com wrote:
>
> Here is the corresponding array:
> 2 925 2678400.00000000 2461471200.00000 Head 326 165 1
Interesting...
Your first record is 52 (hex 34) bytes, and your second looks like it's
430320 (hex 0690f0) bytes long. Does that sound OK? The dumped bytes
starting at offset (octal) 0014440 -- are they at the end of the file?
Did you transfer the file from another machine? If so, is it possible
that the file was somehow truncated in transit? Do the file size and
checksum match across machines?
One thing to try is a program that opens the file and loops reading
records with no I/O list and printing the record number after each
successful read. This will help you figure out where you're getting the
end of file condition.
Louis
| |
| glen herrmannsfeldt 2007-11-25, 10:10 pm |
| yonas_kassa@hotmail.com wrote:
52 bytes | 2 | 12 |
[color=darkred]
2678400D0 | 31536000D0 | (blanks
[color=darkred]
H E A D| 326
[color=darkred]
165 | 1 | end 52 bytes
(snip)
[color=darkred]
> Here is the corresponding array:
> 2 925 2678400.00000000 2461471200.00000 Head 326 165 1
It seems that some are a little off. Also, be sure to indicate single
or double precision, and read them back the same way as written.
-- glen
| |
| yonas_kassa@hotmail.com 2007-11-25, 10:10 pm |
| On Nov 25, 8:32 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> yonas_ka...@hotmail.com wrote:
>
> 52 bytes | 2 | 12 |
>
>
> 2678400D0 | 31536000D0 | (blanks
>
>
> H E A D| 326
>
>
> 165 | 1 | end 52 bytes
>
> (snip)
>
>
> It seems that some are a little off. Also, be sure to indicate single
> or double precision, and read them back the same way as written.
>
> -- glen
Thanks all,
I am learning a lot here. Let me take sometime and digest all your
messages and will let you know how it goes.
Thanks again
Yonas
| |
| yonas_kassa@hotmail.com 2007-11-25, 10:10 pm |
| On Nov 25, 8:32 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> yonas_ka...@hotmail.com wrote:
>
> 52 bytes | 2 | 12 |
>
>
> 2678400D0 | 31536000D0 | (blanks
>
>
> H E A D| 326
>
>
> 165 | 1 | end 52 bytes
>
> (snip)
>
>
> It seems that some are a little off. Also, be sure to indicate single
> or double precision, and read them back the same way as written.
>
> -- glen
I am really sorry glen. You are absolutly right the above array
(2 925 2678400.00000000 2461471200.00000 Head 326
165 1 ) is for this binary (i mixed up some files).
0000000 34 00 00 00 02 00 00 00 9d 03 00 00 00 00 00 00
0000020 40 6f 44 41 00 00 00 3c e2 56 e2 41 20 20 20 20
0000040 20 20 20 20 20 20 20 20 48 45 41 44 46 01 00 00
0000060 a5 00 00 00 01 00 00 00 34 00 00 00 f0 90 06 00
0000100 00 00 00 00 00 38 8f c0 00 00 00 00 00 38 8f c0
*
0014440 e1 7a 14 ae 47 58 a7 40 8f c2 f5 28 dc 4b a7 40
0014460 85 eb 51 b8 9e 3b a7 40 cd cc cc cc 4c 2b a7 40
0014500 00 00 00 00 00 1b a7 40 b8 1e 85 eb d1 0a a7 40
0014520 00 00 00 00 80 fa a6 40 52 b8 1e 85 eb e9 a6 40
I converted the above binary and got the same array as your's. Thanks
again and sorry for the confusion.
Yonas
|
|
|
|
|