forums.silverfrost.com

[LitusSaxonicum]

Christy,

The "header" is the set of bytes at the beginning of something (in your case, the array), and the "trailer" is a set of bytes after it. What these header and trailer sections consist of is system dependent, and they could consist of nothing at all. The header, trailer and the data in between make up one record. A file then consists of a set of records.

Imagine a Fortran program source code. Each line is a record. There isn't any header to each line, but the trailer consists of a CR, LF sequence. The Fortran program is made up of a number of these statements (records).

As to binary values, the computer doesn't record bytes with readable characters, it just keeps a whole list of 1 and 0 (on or off) values. That's binary. These are maddening to contemplate. Therefore people interpret them in different ways. One way is to take half a byte (4 bits) and represent it as:

0, 1, 2, .... 9, A, B, C, D, E or F. (there are 16 possible combinations).

Then, you can see what is in a byte as maybe 0E or CF (FF=255 or 11111111, 00 is 00000000). That is called hexadecimal. But binary is how the computer works.

As there are 256 possible combinations in a whole byte, we could also take each byte as representing a single character. This can cover the whole alphabet in both upper and lower case, and lots of symbols and control codes (like CR and LF). Deep down, however, it's all binary 0 and 1 ...

Eddie

[christyleomin]

That means the binary file that is generated is not readable, right? IT comprises of just 0's and 1's.Correct?

Basically, I have a l FE (finite element analysis) software (say software 'A') and want to write a binary file through my own program (say 'MY FE program') so that software A understands it.

I have the docuemntation of binary file contents of software A . I have some binary files which the software A has written whilst I worked on it.

Are the binary files of software A readable?

[IanLambley]

If the unformatted/binary files do have a header and trailer for each record which conforms to the FTN95 standard then yes, they can be read directly.

If they conform to the other standard, then it is harder to read them. The code that I posted above converts between the two unformatted methods. You could run the file from the non-FTN95 through the conversion routine and then open it in FTN95 to read it. If you write a file from FTN95, run it through the other converter for reading by your FE program.

Alternatively if they are fixed length records then the file will be readable with "direct" access methods and the code I gave above is not useful as there is no header or trailer.

The beauty of binary files is that nothing is lost when writing and reading. the data. The internal representation of the data is directly stored in the file and can reduce file size compared to formatted. For example for a real*8 value which gives say 17 decimal digits precision, it takes 8 bytes to store in unformatte/binary, but you might need a format as ridiculous as F35.17 to store it to the full precision in formatted mode, i.e 35 bytes. Anything less can result in loss of precision.
Ian

[LitusSaxonicum]

Christy,

Not readable by you or I, just using something like Notepad. Correct.
Notepad takes each byte, and interprets the 0 and 1 pattern as a character. Some of the resulting characters are invisible, which makes it even harder.

I'll start by considering that you want to READ a file written by the pre-existing program, and then go on to the difficulties in writing a file for it to read.

Your pre-existing Fortran program probably wrote a bunch of INTEGER values each time as 4 bytes, and a bunch of REAL values as 8 bytes at a time. Unlike a text file, there are no "blank" characters between the values, you just have a sequence of bytes, which means a sequence of 0 and 1 values.

The first problem you have in reading a file is to know which bytes are an INTEGER, and which bytes are a REAL . OK, you get that from the FE program documentation.

The next problem is sorting out any header and trailer for each record. This may vary not only computer system to system (if you are using a mainframe) or compiler to compiler - e.g. it is different for Intel Fortran from FTN95. OK, you get the answer to that from help by John, for example.

Finally, you have the problem with which order the bytes are written in. This is the "big-endian" and "little-endian" stuff. It's difficult in binary, so suppose we take a 4-digit decimal integer, such as 8632. Big-endian is just this way round, 8 - 6 - 3 - 2. Little endian stores it (in effect) 2 - 3 - 6 - 8. If your file was written by a code compiled with a different compiler, you will only know if you read the relevant documentation. It would be so much easier if both codes were compiled with FTN95 on a PC! The PC cpu has a native way of doing it, but any compiler can do it however it sees fit.

The problem you have in writing a file for reading by the other programme contains the same difficulties, but in reverse.

Transferring data as unformatted files always has this difficulty. Formatted files are bad enough, as the trailer to each line could be CR LF or just CR, but that is minor compared to unformatted.

Eddie

PS. I simplified the 8632 case. It is more like 86 - 32 versus 32 - 86 !

PPS. Big and little endian refer to whether the most significant bytes come first or last. The name derives from"Gulliver's Travels" where the hero travelled to various foreign lands, in one he witnessed a war between factions over whether to eat a boiled egg from the wide (big end) or narrow (little end) end! Whoever named this had a literary background, clearly. There used to be big arguments about which version of endian should be used.

The binary files that were written are readable, once you know the 3 tricks above to read them.

E

[christyleomin]

I have downlaoded hexeditor which reads a binary file, it comes like this;

4c 53 2d 44 59 4e 41 20 75 73 65 72 20 69 6e 70
75 74 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 cb 03 00 00 10 95 2f 03 00 00 70 44 04 00
00 00 2d 24 00 00 06 00 00 00 09 00 00 00 01 00
00 00 00 00 00 00 01 00 00 00 00 00 00 00 40 1f
00 00 09 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 92

However, as Eddie said, this is in 0's and 1's.

I'm really clueless how to start, anything suggested?[/list]

[JohnCampbell]

[christyleomin]

In addition to above;

Let me start with something simple;

(1) Let us say I have a "MY FE PROGRAM"

I have;

subroutine ReadMyFEProgramData

call GetNodes !!I get number of nodes
call GetNumberOFElements !!I get number of elements

end

(2) Now, I want to begin writing my binary file which ANOTHER (say program ''A'') program can read. I know that; the variables for number of nodes and number of elements in program 'A' are named as NNODES And NELMENTS respectively.

Number of words of NNODES And NELMENTS is 1 (each) and disk address is 10 and 11 respectively.

The word size id 4 bytes for single precision and 8 bytes for double precision.

The databases (i.e.binary file) are written as word addressable fixed length binary files. The actual length depends on the amount of data saved, but will always be a multiple of 512 words (4 or 8 bytes each). Since it is likely that the database cannot be contained in a single file of length, FEMLEN,the data will spread over several files known as a family of files. Having a set of files enables them to be handled more easily than a single very large file. The root name for a family is the name of the first file member.

With this information, can anyone please guide me how to write NNODES and NELMNTS to a binary file?

After writing, PROGRAM A understands the binary file I wrote and can do what it wants with the data in binary file.

[JohnCampbell]

I've recommended you read the fortran documentation about Input/Output, as your grasp of the subject appears poor.
A simple example of what you may need : ( you could improve much of it depending on other requirements)

[JohnCampbell]

If you want to cope with different record length formats, I've modified the program to demonstrate how you might control the record length header, using ACCESS='TRANSPARENT'. other compilers might use FORM='BINARY'

[JohnCampbell]

the file I/O routines