FLUSH (unit)

is Fortran 2003 feature. Do we have something like that? If not it's probably worth to add to FTN95

Description: Flushes Fortran unit(s) currently open for output. Without the optional argument, all units are flushed, otherwise just the unit specified. Option: gnu Class: non-elemental subroutine Syntax: CALL FLUSH(UNIT) Arguments: UNIT (Optional) The type shall be INTEGER.

Note: Beginning with the Fortran 2003 standard, there is a FLUSH statement that should be prefered over the FLUSH intrinsic.

You could re-open the connection, something like:

SUBROUTINE FLUSH_UNIT(UNIT)
   INTEGER, INTENT(IN) :: UNIT
   OPEN(UNIT, POSITION='ASIS')
END SUBROUTINE FLUSH_UNIT

Open can be used on an already open/connected unit to change the attributes of the connection.

Interesting suggestion, thanks David. Never heard before about 'ASIS' and that you can 'mess' like that with already open file. LOL

David,

I could not find much in the F95 standard to indicate what happens if you re-open a file that is already opened. Does this ensure that the file buffers are cleared by the OS ? Not a lot in the standard on how the OS manages the file buffers !! It's a bit hard to understand why ASIS is the default for position=, when in almost all cases OPEN is used to conect a file for the first time, with no predefined position.

John

John,

POSITION='ASIS' should only be used when OPEN is used to re-open an pre-existing connection. There are several Changeable connection mode specifiers that can be altered by re-opening a file. In'The Fortran 2003 Handbook' they are listed as:

BLANK DELIM PAD DECIMAL (F23 only) ROUND (F23 only) SIGN (F23 only)

In addition, you can change ERR= and IOSTAT= in the re-open statement.

I don't know for sure that this will do a 'flush', you would have to experiment with it. However, it seems likely that it will. In 'Fortran 95/2003 Explained, Metcalf, Reid, Cohen' it says the effect is as if the file is closed and opened again. I am guessing this is what FTN95 does (being careful with scratch files!). The implementation of close should call some routine to get the OS to flush the output buffers.

I agree its a bit strange ASIS is also the default when there isn't a pre-existing connection (the most common usage for OPEN as you say). In such cases, the effect of ASIS is undefined when the file already exists, so you shouldn't use it. Only use it when re-opening a connection.

David,

I've written a disk I/O tester for testing : small to large direct addressable binary files on HDD and SSD using XP and Win7

It goes through the stages of opening (a new file) writing reading writing randomly reading randomly closing and deleting

It is interesting to see the elapsed time for each stage, especially reading and closing. Closing has a significant effect on measured elapsed time performance for what I expect is flushing the buffers, which I should test to identify the flushing effect of CLOSE vs reOPEN. (This is especially the case where the file size is less than the amount of physical memory, which was 2 to 4gb but is now typically 8 to 12 gb) File size is tested in comparison to the amount physical memory installed, showing a significant difference between XP and Win7. Retesting is becoming a problem, as I've lost most access to XP, which is not a bad thing when considering file buffers. Also a few work pressures at the moment, so not the time available to do the retest, for more emphasis on the flush time. Will get back with some results when I can.

This use of FLUSH could be a good thing to consider, especially when testing a run time bug, where the file buffers are lost. Installing some temporary FLUSH commands might help, if you can anticipate where the bug is. Alternatively, it would be easier to have a buffer flush when an access violation or similar error occurs.

John

I will be interested to see what you discover when you have the time.