There is no way you can do this, as far as I know. You could open the files as a "null device" (*), so that they do not take up any space on disk
and the operating system might even decide that it is not worth to transfer the bytes that your program writes, but that does not take away the
processing required for the formatting of the numbers.

The write statements are not concentrated in a few dedicated routines, I suppose?

Regards,

Arjen

(*) On Windows the file name would be "nul" (or at least that was the case with older versions of Windows and I suppose that still works
that way). On Linux that would be "/dev/null"

Consider using the name of the null device ("NUL:" in Windows) as the FILE= argument when OPENing the files that you want to suppress. You could collect all the OPEN statements in one subroutine. Based on an environmental variable, directives in a small configuration file or user input, you would choose either real file names or the name of the null device in that subroutine.

The main problem with collecting all your OPENs into one routine MYOPEN and then collecting all your WRITEs and all your FORMATs into a single routine MYWRITE and replacing

WRITE(UNIT,FORMATNUMBER) (Argument list)

with

iret=MYWRITE(UNIT, FORMATNUMBER, Argumentlist)

is how to package each unique argument list. At first glance you would have to create a unique user-defined type for each argument list.
Sounds a lot of work when putting your WRITEs inside IF...Then..Else...Endif blocks is more straightforward and more flexible (easy to change argument list and format at will) even though a drag at first.

If this is formatted output, you can write all output to a string variable and pass it to a single subroutine which checks a global or passed argument to determine if it should write it. If the unit numbers vary, pass that as an argument. The subroutine can check open status of each unit if they differ and can perform opening as needed.

Good suggestion!
Just use

WRITE(CHARACTERBUFFER,formatnumber) (OUTPUT LIST whatever...)

then

iret=MYWRITE(CHARACTERBUFFER,UNITNUMBER).

Your problem will be sizing your character buffer beforehand long enough to handle your longest burst of output.
You are still processing the WRITEs though.

Anthony Richards (#3):Цитата:

The main problem with collecting all your OPENs into one routine MYOPEN and then collecting all your WRITEs and all your FORMATs into a single routine...

My suggestion in #2 was only about collecting the OPEN statements. Once unit numbers have been associated with bit-buckets, where the WRITE statements are located, what the I/O lists contain and the types of the members of those lists do not matter.

How about
IF(YourUnit .gt. 0) WRITE(YourUNIT,FORMATNUMBER) (Argument list)

This would require your "YourUnit" numbers to be variables.
Also, depending on what is in "FORMATNUMBER" you may also be able to use the Fortran PreProcessor

#define WRITE(u,f) IF(u .gt. 0) write(u, f)

The above may require using free format as use in fixed format may cause line to exceed line length.

Jim Dempsey

My preferred approach is as Jim has suggested. It has a number of benefits.
Have global variables for the file unit numbers and set them to -ve if the file is not open or you do not want to use that output option at that time.
To change the code, you need to
1) include or USE the module with the unit numbers,
2) simply change the WRITE (... to
if (LU_23 > 0) WRITE (LU_23,...
.
This is a minimal change to the original code and opens up the functionality of selectively manageing all output.
Searching for all WRITE statements is fairly easy for a global change, while the main code change problem comes when the file unit numbers are transferred via subroutine arguments.
.
Again this change can be a precurser to an improved management of program output, with the advantage of minimising output size and run time.
Avoiding the generation of the output text can be a significant saving.
I have needed this approach, where outputs from my simulation codes have exploded from a few mb of output to many gb. This was an easy change to bring the output back under control, while leaving a lot of checking code in place, but selectively turned off.
.
John

One hitch with the "all negative numbers" approach is that it then prevents you from using a rather handy feature in F2008 - the NEWUNIT specifier in the open statement, which must return a negative unit number.  I find fixed unit numbers an anathema (why should I have to care what specific number is in use and then need to resolve any clashes between libraries - I just want to reference a particular connection!), so something like NEWUNIT appeals to me.

If you tested explicitly against -1 then I think you are ok - from what I can tell that can never be a valid unit number.  i.e. IF (LU_23 /= -1) WRITE (...

I'd be trying to cut things off in the source code like this - if you are relying on a nul device type of solution then you've still got a lot of IO overhead being incurred, even if physical disk heads aren't involved.  But failing that, as Arjen said the filename for the Windows bitbucket is simply "NUL". 

OPEN(UNIT=10,FILE='NUL',ACTION='WRITE')
  WRITE (10,"('No one will read this!')")
  CLOSE(10)

If you are dong a global edit and extending coding line lengths, you have to be using free-format if you are to avoid going beyond column 72 problems.

If 0 in your units table indicates something special in addition to not being open, and if -n is not appropriate (re NEWUNIT), then you can define a unit number that is to be reserved to indicate file not available - avoid WRITE. Perhaps you can use 9999 (assuming your unit numbers are held in something other than integer(1)).

INTEGER, PARAMETER :: AvoidIO = 9999
...
IF(YourUnit != AvoidIO) WRITE(YourUnit,....)
Also address OPEN, SEEK, INQUIRE, CLOSE, ...

Note, should you have a section of code containing writes

IF(YourUnit != AvoidIO) THEN
WRITE(YourUnit,....) ...
WRITE(YourUnit,....) ...
WRITE(YourUnit,....) ...
...
ENDIF

The relative small amount of work spent now will be returned later by shorter run times in not formatting data sent to NUL

Jim Dempsey

I like the idea of writing to the null device. It goes well with a test for skipping writing as well:

program p
   implicit none
   integer unit1, unit2
! Or 'NLA0:' if you prefer
   character(20), parameter :: nulfilename = 'NUL'
   character(20) filename
   open(newunit=unit1,file='f.txt',status='replace')
   open(newunit=unit2,file=nulfilename)
   write(unit1,'(a)') 'Should appear in f.txt'
   write(unit2,'(a)') 'Should not survive'
   inquire(unit=unit1,name=filename)
   write(*,'(a)') 'Name of unit1 file = '//trim(filename)
   inquire(unit=unit2,name=filename)
   write(*,'(a)') 'Name of unit2 file = '//trim(filename)
   if(filename /= nulfilename) then
      write(unit2,'(a)') "This shouldn't have happened"
   else
      write(*,'(a)') 'Writing to unit2 skipped'
   end if
end program p