 |
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
Emerson00
Joined: 09 Dec 2013 Posts: 4
|
Posted: Tue Dec 10, 2013 12:54 pm Post subject: 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.  |
|
Back to top |
|
 |
IanLambley
Joined: 17 Dec 2006 Posts: 506 Location: Sunderland
|
Posted: Tue Dec 10, 2013 1:31 pm Post subject: |
|
|
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:
Code: |
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. |
|
Back to top |
|
 |
davidb
Joined: 17 Jul 2009 Posts: 560 Location: UK
|
Posted: Tue Dec 10, 2013 5:53 pm Post subject: |
|
|
Ian is correct. Flush isn't standard,
Try calling this:
Code: |
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 IS 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. _________________ Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl |
|
Back to top |
|
 |
DanRRight
Joined: 10 Mar 2008 Posts: 2923 Location: South Pole, Antarctica
|
Posted: Tue Dec 10, 2013 6:35 pm Post subject: |
|
|
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 |
|
Back to top |
|
 |
Emerson00
Joined: 09 Dec 2013 Posts: 4
|
Posted: Wed Dec 11, 2013 4:30 am Post subject: |
|
|
Thanks, all. Off to try it now.
<- not a programmer... very appreciative of the help! |
|
Back to top |
|
 |
Emerson00
Joined: 09 Dec 2013 Posts: 4
|
Posted: Wed Dec 11, 2013 4:55 am Post subject: |
|
|
Ok so I dropped the shorter of the two into the code in place of Flush as follows:
old code:
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:
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 Code: |
WRITE(1,'(/)')
itx=i+1
WRITE(1,'(/,a4,i4,/)') '****',itx
|
is supposed to be inserted at "INTENT(IN)"? |
|
Back to top |
|
 |
davidb
Joined: 17 Jul 2009 Posts: 560 Location: UK
|
Posted: Wed Dec 11, 2013 10:09 am Post subject: |
|
|
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). _________________ Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl |
|
Back to top |
|
 |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2615 Location: Sydney
|
Posted: Wed Dec 11, 2013 12:00 pm Post subject: |
|
|
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 |
|
Back to top |
|
 |
davidb
Joined: 17 Jul 2009 Posts: 560 Location: UK
|
Posted: Wed Dec 11, 2013 8:55 pm Post subject: |
|
|
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. _________________ Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl |
|
Back to top |
|
 |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2615 Location: Sydney
|
Posted: Thu Dec 12, 2013 12:15 am Post subject: |
|
|
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 |
|
Back to top |
|
 |
davidb
Joined: 17 Jul 2009 Posts: 560 Location: UK
|
Posted: Thu Dec 12, 2013 6:48 am Post subject: |
|
|
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. _________________ Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl |
|
Back to top |
|
 |
Emerson00
Joined: 09 Dec 2013 Posts: 4
|
Posted: Sat Dec 14, 2013 5:06 am Post subject: |
|
|
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. |
|
Back to top |
|
 |
IanLambley
Joined: 17 Dec 2006 Posts: 506 Location: Sunderland
|
Posted: Sat Dec 14, 2013 10:25 am Post subject: |
|
|
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:
Code: |
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. |
|
Back to top |
|
 |
DanRRight
Joined: 10 Mar 2008 Posts: 2923 Location: South Pole, Antarctica
|
Posted: Sat Dec 14, 2013 5:58 pm Post subject: |
|
|
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) |
|
Back to top |
|
 |
|
|
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
|