|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Sat Sep 24, 2016 7:53 am Post subject: |
|
|
I am not sure I understand your request.
Briefly, a binary file consists of groups of bytes that are basically memory images.
These groups of bytes can be enclosed in a header and footer ( 1, 4 or 5 bytes long) to describe the size of each record, but not always.
The memory image can be of any variable type, eg 4 byte integers, 8 byte reals or a character string.
For real or integer variables, the byte order is important ( big or little endian )
The two main forms of Fortran binary files are:
1) Unformatted sequential access files, which have a record header and trailer. FTN95 header syntax (1 byte for small, 5 byte for large records) is different from most other compilers, that use 4 bytes.
2) direct access fixed length binary files, which have no header/trailer info, are simply a memory image.
If written with Fortran, the memory image is based on the I/O variable list in the WRITE statement.
Importantly you need some knowledge of the data and record structure.
You can open the file for stream I/O (FTN95 access='transparent') to interrogate the file information, but an idea of the data is most important.
The best place to start with FTN95 is to use access='TRANSPARENT' to read files one byte at a time and have some files of known structure to review.
My preference is to use binary files when transferring information between closely related programs only.
If I want to transfer data between different packages or computers, I always use a text file which has a simple structure. One useful approach is that if you are providing a list of numbers, first provide the count, as this allows the program reading to first allocate a known space to read the data.
Also, make each line of text short; lots of <CR> <LF> will not flood a modern disk.
Use formats that provide adequate precision. The following always works:
write (lu,*) '#TITLE it is good to give each group of data a title that can be skipped when read'
write (lu,*) n
do I = 1,n
write (lu,*) a(I)
end do
write (lu,*) ' ' ! ending with a blank line also helps clarity
A text file is easy to look at to check what is in the file and so easy to then write a program to read.
Hopefully this answers some of your question.
Last edited by JohnCampbell on Sun Sep 25, 2016 3:50 am; edited 2 times in total |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sat Sep 24, 2016 10:34 am Post subject: |
|
|
I'm totally with you John on the 'ascii is best 'cause you can see it' philosophy, the only problem possibly being when the files are large becasue they use up much more disc space no?
I guess it's difficult to give a specific guidance unless newuserftn can give an example of the data format he's trying to read. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Sat Sep 24, 2016 11:07 am Post subject: |
|
|
I didn't understand the request, because you could easily write a couple of programs to write a file and read it back - or even do it in the same program.
ASCII might be readable, but it is very accessible to a user, who can quickly make it unreadable.
As to length, that depends. A single digit is one byte, but that could be read into a REAL*8 or INTEGER*8, which are 8 bytes. I'm not sure that file length is much of an issue on most computers, nor indeed is there much of an issue in speed of reading or writing formatted v. unformatted for most practical purposes. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sat Sep 24, 2016 12:04 pm Post subject: |
|
|
... oh your comment about ASCII REadable files is so true Eddie, reminds me of the old tried and tested adage ...
Quote: | "When it comees to input data, don't trust ANYONE, not even your Grandma !!! " ... oh, and especially NOT YOURSELF !!! |
LOL |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Mon Sep 26, 2016 4:16 pm Post subject: |
|
|
I'm not usre I fully understand what you are needing, but here's an alternative.
A text editor that can also read (and update!) binary files is EditPad (from Just Great Software). I've used this for years, and am very pleased with it for editing ASCII files of all kinds AND for it's ability to display and edit binary files.
When debugging/viewing binary files, you can "drag-and-drop" them into the editor. It will recognize that the file is binary and show you the file as hexadecimal data on the left and character representation on the right (a lot like many DUMP utilities). You can change the data (edit or add in hex) or delete data. It is the ability to change the data that I've found useful when I've had a programming issue and needed to edit the file slightly, or to introduce an error in a data file. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|