Old code, stopping on flush

Getting this error message: Runtime error from program:c:\fortran\xxxxxx121413\debug\win32\bubec.exe Run-time Error *** Error 29, Call to missing routine : _FLUSH at 0x0040200e.

main - in file xxxxxx.f at line 192 [+1013] [recur= 1]

Background: Professor assigned a semester project to get an old code running that he wrote in 1993, and make some modifications to it. It runs on the University systems, but my computer can't log in for some reason, so I'm trying to run it on Silverfrost. I think I've worked through most of the issues, but for some reason it's failing on FLUSH. Is there a means of putting a Flush subroutine into the folder/project? Is there a better way to get it running? I thought FLUSH was a standard Fortran routine.

I haven't used Fortran since 1995. 😮ops:

FLUSH seems to be a non-standard function. It is available in GNU Fortran. If the file you are flushing is a sequential file, then you could try something like:

      Subroutine flush(ichan)
      integer*4 ichan
      character*256 path
* remember file name for later
      inquire(unit=ichan,name=path)
* close file hence flush buffer
      close(unit=ichan)
* re-open file and carry on as before
      open(unit=ichan,file=path,status='append')
      end

Simply call flush with the channel number. Ian PS - This is just a thought; I haven't actually tried it.

Ian is correct. Flush isn't standard,

Try calling this:

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

This uses OPEN on a file that is already open. This [u:ef7da6254e]IS[/u:ef7da6254e] standard. Usually a flush is done as a side effect.

Like Ian's code, I haven't tried this with Silverfrost but it works with other compilers.

Would be great to see FLUSH function (of Fortran 2003) in FTN95. One of the third party very confusing codes I use may hiccup due to our FLUSH workaround

Thanks, all. Off to try it now.

← not a programmer... very appreciative of the help!

Ok so I dropped the shorter of the two into the code in place of Flush as follows:

old code:

c    ...Write output for this time step to 'bubout.dat'
        WRITE(1,'(e20.13)') tnew
        DO 900 j=1,nb+1
           WRITE(1,10) rn(j),zn(j),phi(j),phin(J)
900     CONTINUE
10      FORMAT (4(1x,E13.6))      
        call FLUSH(1)

        WRITE(1,'(/)')
        itx=i+1
        WRITE(1,'(/,a4,i4,/)') '****',itx


        ipc=1
c       ... ipc controls calcs in newb for pred-correc scheme

new code:

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

Wait... I can't pretend I know what this is doing in either instance. I have a sense that

        WRITE(1,'(/)')
        itx=i+1
        WRITE(1,'(/,a4,i4,/)') '****',itx

is supposed to be inserted at 'INTENT(IN)'?

No! As you have it, the program won't compile.

Just write the FLUSH function as I have written it. Then it will work.

The dummy argument name should be UNIT. When you make your call this will be given the value of 1.

Don't worry about the INTENT(IN).

Why are you using unit 1 ? This is a special unit for screen I/O. I would not open a file on this unit ?? Some compilers use units 5 and 6 for screen I/O; FTN95 uses unit 1.

Not sure if this is the main reason for your problems.

John

I think the OP is trying to write an indication of progress to the screen, in which case unit 1 is correct.

Strictly speaking you are supposed to be able to open files on any of the pre-connected units. But some compilers have problems doing this reliably. If unit 1 is supposed to be connected to a file, then better heed John's warning and change to something else.

Why would you require a buffer flush on unit 1 ? I thought the main use of flush is when you trap an exception or error and want to clear the file buffers or for some mult-process communication. Unit 1 should not require this approach.

John

I have sometimes needed flush on the screen (perhaps not for some years now).

I agree that in this modern age, the OP probably doesn't need the Flush and could just delete this line.

Thanks, all. Will try again this evening. I tried running it with the exact code provided, and the compiler started returning problems with c*************** which only occurs up in the descriptive header and hasn't been an issue before. I'm going to start fresh this evening and see what happens.

For what it's worth, the code references a couple of external files, and the bubout.dat file was referenced as Unit=1, so I assumed (yeah, yeah) it was necessary to clarify which file.

Due to the units 1, 2, 5 & 6 being preconnected to the keyboard and screen, depending upon the compiler, then using them for file IO, disconnects their original use. For file IO try adding 10 to all the unit numbers and leave the console items as they are.

Try running this program to find the preconnected channels:

      winapp
      program iochans
      print *,'IOchan test'
      do i=1,2
        print *,'Preconnected channel test - loop:',i
        do ichan=0,10
          write(ichan,*,err=9000)'Write OK - Channel:',ichan
! close a sucessfully used channel for the next time around
! don't ever close 2 ans this is used for the print command
          if(ichan .ne. 2)close(unit=ichan)
          goto 9100
 9000     continue
          print *,'Error on Channel:  ',ichan
 9100     continue
        enddo
        print *
        Print *,'Channels now closed (except 2)'
      enddo
      end

1 or 5 would normally be used for keyboard input and 2 or 6 for screen output.

Besides those units the logical unit 0 is also special. It is equivalent in FTN95 to write(,) but in other Fortran compilers (like GNU for example) it was and still is used as a 'console' unit (older ages therminology) with obviously higher priorities (like not allowing the stream to unit 0 to be redirected to anything else, the file or printer)