From: Terence on 3 Dec 2006 02:32 abbad(a)ntnu.no wrote: > Hi guys, > > I have a problem to read a SEG-Y file (a file format used in > geophysics to store and process seismic data). The SEG-Y format > consists of three blocks separated by an IBG (InterBlock Gap). The > first block is written in EBCDIC on 3200 bytes and is followed after an > IBG by a 400-byte binary block. After a third IBG, there is another > binary block. > > My questions are: > > 1) How to convert the EBCDIC code to real (through binary if necessary)? If you have THREE blocks there will be TWO IBGs and an end-file marker unless more data follows. So read the data as a 3200 byte unformatted binary sequential record, followed by another of 400 bytes, followed by whatever byte length the next block is, and so on. .. IBM EBCDIC codes for characters convert to normal ascii codes, through a 256 byte look-up table, normally sending european Latin-based characters to the lower half of the ascii multilingual 850 code page, unless accented characters, or non-latin languages are used (when they go to the higher half). Greek goes entirely to the upper half of the ascii table. In these special cases, the user has to specify the correct conversion table for the mapping of EBCDIC to the ascii table specific for the language. > I found that the ascii character from 0 to 20 corresponding to the > EBCDIC code don't exist in Windows and correspond to "blank spaces". Fortran does not use characters of value 1 to 31, blank being the first valid code in the series. There are many other codes that will be invalid within text strings or literals in Fortran. Ebcdic does not use those for text characters either. > 2) How to jump the IGB gap when reading such a file?. First convert the file from tape to disk. Process whatever you get, afterwards. > 3) I wrote subroutines for binary to integer/real conversion and > vice-versa. are there any simple functions to do that for the special > formats of binary code (complement to "1" or not, on 4 or 8 bytes for > instance). Binary Integers just need the 8-bit bytes re-ordered from lowest significance to highest significance, whether 2, 4 or 8 bytes precision from IBM mainframe sources (they are from highest to lowest).. If you have floating point values stored in a bit representation you will have to change the representation of the mantissa and exponent. IBM mainframes used a different number of bits and treatment from the usual fortran representation for non-mainframe computers. If you have floating point values stored as ascii strings in scientific notation, these should be directly readable. > 4) Do these functions depend on a specific Fortran compiler. If yes, > which one, running under windows, offers the best environement to > process EBCDIC and binary codes?. I think the answer is no. But perhaps an IBM mainframe compiler will understand the information perfectly and by running a conversion program on the mainframe, and converting to a file of all-text representations, with scientific notations, the text and binary information will be preserved but the floating point accuracy may not be exactly to the same precision on re-reading. This text file could then be read t recover the original texts and values.
First
|
Prev
|
Pages: 1 2 Prev: Problem linking Intel Math Kernel Library Next: gfortran install on PCC OSX |