forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

FLUSH (unit)

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2139
Location: South Pole, Antarctica

PostPosted: Fri Aug 17, 2012 10:26 am    Post subject: FLUSH (unit) Reply with quote

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.
Back to top
View user's profile Send private message
davidb



Joined: 17 Jul 2009
Posts: 557
Location: UK

PostPosted: Fri Nov 16, 2012 8:50 pm    Post subject: Reply with quote

You could re-open the connection, something like:

Code:

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.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2139
Location: South Pole, Antarctica

PostPosted: Mon Nov 19, 2012 5:33 pm    Post subject: Reply with quote

Interesting suggestion, thanks David.
Never heard before about "ASIS" and that you can 'mess' like that with already open file. LOL
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2154
Location: Sydney

PostPosted: Tue Nov 20, 2012 4:05 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
davidb



Joined: 17 Jul 2009
Posts: 557
Location: UK

PostPosted: Tue Nov 20, 2012 9:11 am    Post subject: Reply with quote

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.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2154
Location: Sydney

PostPosted: Thu Nov 22, 2012 12:11 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
davidb



Joined: 17 Jul 2009
Posts: 557
Location: UK

PostPosted: Fri Nov 23, 2012 6:17 pm    Post subject: Reply with quote

I will be interested to see what you discover when you have the time.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
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