forums.silverfrost.com

[DanRRight]

The files created by gcc on Linux are readable by FTN95 on Windows no problem without any changes or conversions. The same files made by the Intel Fortran on Linux are not readable by FTN95 on Windows. Anyone had this problem?

[simon]

Ian Lambley has posted something about this in at least a couple of places on the forum. Here's one:

http://forums.silverfrost.com/viewtopic.php?t=2722&highlight=endian

[DanRRight]

Thanks, Simon. If nothing else works, will try GFortran and if it will not work or will be slower than Intel, will return to READF@/WRITEF@ as it was suggested.

I used them before, but lately i just switched to the plain standard way of reading. Thanks to the numerous helpful discussions here of our great community i found that with the trick of reading/writing the entire array without mentioning any of its indexes as utterly simple as this

[JohnCampbell]

ifort and gfortran use a 4-byte record header/footer.
FTN95 use a 1-byte or 5-byte record header/footer. 1-byte formats are for records smaller than 256 bytes.
ifort use 4-byte header/footer for records up to 2^31 - 9 bytes. Larger records become much more complicated.

So, the binary unformatted files are NOT compatible.

There are two alternatives:
1) write a file tester then converter, using transparent/stream format. The advantage of this approach is that the I/O list structure is not required. This is a fairly simple approach, or
2) Ask FTN95 to provide a "4-byte-header" option in the OPEN statement, as you might need to open both ifort and FTN95 format record files.

I have probably written option 1) before, certainly using access=transparent to read one or 4-bytes to identify the record header and so determine the record_data. It is not a difficult conversion.

[DanRRight]

John,
Thanks, missed your post. I saw similar advises to use access=STREAM. I included it with Intel and gfortran compilers on Linux, and then after transferring files to Windows with FTN95 (both with the STREAM or without) still got that unformatted read does not work.

What is "transparent"?

[JohnCampbell]

What is "transparent" ? Good question !

Access='transparent' is FTN95's earlier support for stream like access before Access='stream' now being supported by FTN95.

I have looked for a converter between ifort/gfortran and FTN95 unformatted sequential binary files, but could not find one. So I have now produced another "test" program convert_file_to_FTN95.f90 that achieves the result.
It can be compiled using FTN95 or gfortran, but the option "is_FTN95" is based on the file name ( see routine open_files) ( The program can run sucessfully in PLATO without command line options being provided )
It has the main functionality required but might not be robust for all file options.

https://www.dropbox.com/s/wom8lsaq1lbkbl8/convert_file_to_FTN95.f90?dl=0

https://www.dropbox.com/s/kxz6df4aqm15kh3/make_file.f90?dl=0
https://www.dropbox.com/s/pi636fynx2c7etr/count_char.f90?dl=0

When accessing FTN95 unformatted binary files, they can have either a 1-byte or 5-byte header and footer : 1-byte for records shorter than 255 bytes or byte-1=255(-1) + 4-byte record size for the header then 4-bytes + 1-byte for the trailer.
gfortran/ifort use a 4-byte for header and trailer for all record sizes up to 2^31 - 9 bytes ( need to confirm this, might be 2^32-9 ?)
They do have record formats for larger records, involving linked 1 or 2gb sub-records, but I think FTN95 does not support larger size records.

The program "make_file.f90" can be used to generate an unformatted binary test file, using either gfortran or FTN95 compiler.
I use " is_FTN95 = kind(x) /= 4" to test which compiler I am using when providing a file name.
Program convert_file_to_FTN95.f90 recognises the name of the file to identify the implied input file format (lazy approach which could be enhanced to possibly identify the compiler used from the first record, but should be a command line option! )

The program "count_char.f90" shows a use of stream access to identify what characters are in a text file and the DOS/UNIX text record format.

All programs use Access='stream' sequentially, so don't demonstrate the power of random access provided by stream I/O.

[DanRRight]

John,
Thanks. Will look at that. Preliminary, the first code - the converter - by some reason did not work with my files complaining about something. As a result the file size of converted file increased 3x, first few numbers of converted file were different but the rest were the same resembling zeroes. But my smaller size file seems was converted OK by your converter

Do i correctly understand that if we with FTN95 succeeded to read GFortran or Intel unformatted file which size is less than a quarter kilobytes, we could fail reading 1GB file?

And succeeding with FTN95 to read 1GB GFortran file we will again fail to read >2GB file ? All because headers/footers depend of file size

-----UPDATE -------------------
I'm currently totally lost....
This is not related to your code. When working with my own small test programs which are saving only 4 unformatted numbers, the Linux gFortran files with access='stream' are reading OK by FTN95 with access='stream'. And regular gFortran files without access='stream' also are freaking loading OK by FTN95 without access='stream'.

Here are my programs, the first one writes the file, second one reads it either on Linux or Windows and both work damn fine ! As i wrote, all works fine if we remove access=stream. The problem is why my larger code fails ?

[JohnCampbell]

Dan,

We need to review which types of Fortran binary file formats are available.

These are selected via ACCESS= in the OPEN statement and the options are:

DIRECT these are fixed length records and provide random access of "records" via READ or WRITE "[I/O list].

SEQUENTIAL these are the clasic sequential access, variable length records that have been available for 50 years, based on magnetic tape technology. Each record has a header and footer to indicate the size and the position can be manipulated by READ or BACKSPACE.
These files are NOT interchangeable between gfortran/ifort and FTN95, as the record size header is different. An important feature of these is they can be read/written as a "record" based on their position using a READ or WRITE I/O list. Partial records can be read, then positioned to the start of the next record.

STREAM ( also TRANSPARENT (FTN95 and Lahey) ) These ARE interchangeable between gfortran, ifort and FTN95, as they do not have a header or footer to describe the record. They were officially introduced with F2003. Technically they do not have "records" and you must make sure you read the record completely if you want to use them as records. You can position at any byte in the file using READ (unit, pos=byte_address) [I/O list].
When reading the file, if you want to position to the next record, you must completely read the previous record or position to the byte address of the next record. (the byte address needs to be obtained when creating the file (via a record address table, see INQUIRE (POS=) or be calculated.)

My past posts assumed you have been using the clasic Fortran sequential access, variable length records, where the record size is defined by the WRITE (unit) "I/O list" and all READs to this file structure are positioned at the start of a record, based on header/footer sizes. Both gfortran and ifort use a 4-byte record size packet, while FTN95 uses 1-byte or 5-bytes, so the reason for the incompatibility.

One of the strengths of Fortran Binary files, is you can create a "record" of mixed variable types, using an I/O list. It is best to limit the I/O list to real, integer or complex intrinsic types, as derived type structures are not easily supported by Fortran 95+ (FTN95) in I/O lists.

Now, your latest post suggests you are using ACCESS = 'STREAM' !!!
This changes the relevance of my previous post which does not apply to STREAM I/O, although it does indicate the flexibility of this approach.

You must check what "ACCESS=" you are selecting.

The other issue with binary files is "endianess", although I hope this is not an issue for the file sources we have been discussing.

I hope this enables you to no longer be TOTALLY LOST

RTFM (Manual or Standard or FTN95.chm) for further clarification.

[JohnCampbell]

[DanRRight]

John,
I think i was not clear as usually. And i could be wrong as usually since always makin tons of typos and errors. The tests i have shown tell that FTN95 is 100% compatible with GFortran on regular unformatted read. If use STREAM on GFortran and FTN95 - they are 100% compatible. If both do not use STREAM they are also compatible. I totally have lost any clues. Devilry as usual - demo works contrary to any previous knowledge, the real production code - fails. I am even more confused.

I/O in FTN95 definitely has to be synchronized with all major Fortran compilers. No excuse to have its own standard for each compiler here which gives zero advantages to anyone, only problems. Every compiler developer dancing by its own.

Want more confusion? Here is the link https://gcc.gnu.org/onlinedocs/gfortran/File-format-of-unformatted-sequential-files.html and there the code

[JohnCampbell]

Dan,

Here is a version of the program that will run on FTN95 for a short (<255 bytes) and a long record.

Paul,
It appears that "inquire (iolength=l4a) a" does not give the value I would expect for a "real :: a(10)" being 40 bytes, but reports 400 bits or what ??
I think this is a bug in FTN95 Ver 8.80.0 that I am using.

[DanRRight]

Well, i did not find the error in my production code, i just completely rewrote the piece responsible for reading. Pity i lost 5 days searching. Seems the error was somewhere on my side and not in FTN95. The FTN95 communicates with other compilers using access=STREAM without any other changes so far seamlessly and my hot air on incompatibility seems was unjustified, for which i apologize. Thanks all for the help. John can claim his 12 y.o. Macallan, just give me the phone or address of your local shop

[JohnCampbell]

Paul,

It appears that "inquire (iolength=l4a) a" does not give the value I would expect for a "real :: a(10)", which should be 40 bytes, but FTN95 reports 400 (bits?) or what ??

I think this is a bug in the FTN95 Ver 8.80.0 (and 8.83.0) that I am using.

I shall look at this and an earlier stream problem I reported (regarding use of pos=) and see if the latest download available adresses the problem and update this post.

access='STREAM' looks to be a good improvement over 'DIRECT' or 'SEQUENTIAL' and is much more portable (until endian becomes an issue !!)

John

[PaulLaidler]

Thanks John.

I have logged this as a bug.

[PaulLaidler]

John

This bug has been fixed for the next release of FTN95.