topic I don't see any guarantee in Intel® Fortran Compiler

Problems of running fortran 66 program

Tony — Mon, 30 Dec 2013 09:06:57 GMT

I am a beginner of the Fortran, I have a very old Fortran program which is written in FORTRAN, and was designed and implemented on the DEC-20 of the University of Chicago Graduate School of Business (FORTRAN-20, version 5, an extension of ANSI FORTRAN-66). I used the visual studio 10 with intel fortran compiler 2013, 1.1.139. My system is window 7 64-bit.  I set the property of the old program as following:

/nologo /debug:full /Od /assume:buffered_io /Qopt-matmul- /f66 /d_lines /Qopenmp_stubs /standard-semantics /Qcoarray:shared /convert:ibm /fpscomp:filesfromcmd /fpscomp:ioformat /fpscomp:ldio_spacing /fpscomp:logicals /fpscomp:general /warn:interfaces /align:sequence /assume:dummy_aliases /Qsafe_cray_ptr /assume:noprotect_constants /assume:byterecl /Qtrapuv /module:"Debug\\" /object:"Debug\\" /traceback /check:bounds /check:stack /libs:dll /threads /dbglibs /c

After I run with debug, there are error message, however I start without debugging. Errors occurred in cmd with following statements:

forrtl: severe (47): write to READONLY file, unit 5, file CONIN$
In coarray image 1

application called MPI_Abort(comm=0x84000000, 3) - process 0
forrtl: severe (47): write to READONLY file, unit 5, file CONIN$
In coarray image 3

application called MPI_Abort(comm=0x84000000, 3) - process 2
forrtl: severe (47): write to READONLY file, unit 5, file CONIN$
In coarray image 2

application called MPI_Abort(comm=0x84000000, 3) - process 1
forrtl: severe (47): write to READONLY file, unit 5, file CONIN$
In coarray image 4

application called MPI_Abort(comm=0x84000000, 3) - process 3

job aborted:
rank: node: exit code[: error message]
0: localhost: 3: process 0 exited without calling finalize
1: localhost: 3: process 1 exited without calling finalize
2: localhost: 3: process 2 exited without calling finalize
3: localhost: 3: process 3 exited without calling finalize
Press any key to continue . . .

I think the problem is come from the input commands. There is a subroutine called OFILE, the original statements are

SUBROUTINE OFILE(IO,FNAME,IAC)
DOUBLE PRECISION FNAME
IF(IAC.NE.0)GO TO 10
OPEN(UNIT=IO,FILE=FNAME,ACCESS='SEQIN')
RETURN
10 OPEN(UNIT=IO,DEVICE='DSK',ACCESS='SEQOUT',FILE=FNAME)
RETURN
END

However, the intel fortran compiler doesn't support the ACCESS='SEQIN/SEQOUT' and DEVICE='DSK'. Therefore, I rewrote these subroutine as following:

IF(IAC.NE.0)GO TO 10
OPEN(UNIT=IO,FILE=FNAME,ACCESS='SEQUENTIAL',STATUS='OLD',READONLY)
RETURN
10 OPEN(UNIT=IO,ACCESS='SEQUENTIAL',STATUS='UNKNOWN',FILE=FNAME)
RETURN
END

I don't know whether it causes the problems as mentioned above. I can upload the fortran program if necessary. Thank you for your help.

Did you intentionally want to

andrew_4619 — Mon, 30 Dec 2013 10:12:13 GMT

Did you intentionally want to create a parallel program using co-arrays? If you did that is trying to run before you can walk... I would suggest removing that option and just getting the program to run in the first instance.

It looks like you have created multiple threads that are all trying to open the same file.

Thank you for your help. This

Tony — Mon, 30 Dec 2013 10:48:10 GMT

Thank you for your help. This program is not written by me, I think the main program is correct, since it works before. I think I need to revise DEVICE='DSK' in Intel Fortran Compiler or I need other libraries to handle this problem.

You have set compile options

andrew_4619 — Mon, 30 Dec 2013 11:11:21 GMT

You have set compile options using openmp and coarray to create a parallel program. If the program is as old as you suggest it will not have been written this way. Remove the parallel options and recompile.

I agree with app4619; remove

Lorri_M_Intel — Mon, 30 Dec 2013 11:56:51 GMT

I agree with app4619; remove the /Qcoarray switch. Also, remove the /standard-semantics switch. While it is true that that switch was intended to address only Fortran 90/95/2003 features, it could easily have side-effects with the /f66 support.

All that said, you opened the file as READONLY. I assume there is another place where you are trying to write to it.

You will be able to find that line of code when you remove the /Qcoarray switch, and simply run the program. You already have /traceback set, so it will give you more information about *where* in your program you are trying to "write" to the input unit.

--Lorri

Thank you for your help. I

Tony — Mon, 30 Dec 2013 13:36:47 GMT

Thank you for your help. I have remove these options, new the property is

/nologo /debug:full /Od /assume:buffered_io /Qopt-matmul- /f66 /d_lines /Qopenmp_stubs /convert:ibm /fpscomp:filesfromcmd /fpscomp:ioformat /fpscomp:ldio_spacing /fpscomp:logicals /fpscomp:general /warn:interfaces /align:sequence /assume:dummy_aliases /Qsafe_cray_ptr /assume:noprotect_constants /assume:byterecl /Qtrapuv /module:"Debug\\" /object:"Debug\\" /traceback /check:bounds /check:stack /libs:dll /threads /dbglibs /c

Then the error occurred:

WARPS.exe has triggered a breakpoint
The program '[4708] WARPS.exe: Native' has exited with code 47 (0x2f).

I don't see any guarantee

TimP — Mon, 30 Dec 2013 13:39:00 GMT

I don't see any guarantee that any of those switches for compatibility with old compilers are necessarily relevant. As far as I know, DEC-20 predated the abominations of fpscomp.

I've never seen the definition of /f66 for ifort, but typically such options set a minimum loop count of 1 for programs which depended on non-standard behavior in that respect. That was not covered by f66 standard, although some popular compilers worked that way with default options.

As others said, it makes no sense to combine those options with options dealing with later Fortran standards. There's no way such an old program could have been written to foresee developments of 30 years later.

As far as I can see, /convert

TimP — Mon, 30 Dec 2013 13:51:00 GMT

As far as I can see, /convert pertains to reading unformatted files which were written on old computers. If you have one from the DEC, vaxd is a much more likely possibility than ibm.

When you have so many options which are meant to work with a debugger, you will probably need to run under the debugger to see what is happening.

severe (47): Write to

andrew_4619 — Mon, 30 Dec 2013 14:10:42 GMT

severe (47): Write to READONLY file

http://software.intel.com/sites/products/documentation/hpc/composerxe/en-us/2011Update/fortran/lin/bldaps_for/common/bldaps_rterrs.htm

You are trying to write to the file opened for reading. You need to understand what the program is trying to do and follow it in the debugger. Is it a small program? You could post it on the forum perhaps?

You told us already that you

TimP — Mon, 30 Dec 2013 14:53:00 GMT

You told us already that you changed an OPEN from default read/write to READONLY. By the way, OPEN was not in Fortran 66, so it seems that someone already modified the program to run with Fortran 77.

Thank you for your help. The

Tony — Mon, 30 Dec 2013 15:07:23 GMT

Thank you for your help. The program contains many subroutines which I don't really understand. Kindly see the attached file and give me some comments. The data.txt should be the input file, I have tried to save it as .dat file, but it still doesn't work. With best regards, Tony

Try to find the spot in the

Jan_Jaap — Mon, 30 Dec 2013 15:23:28 GMT

Try to find the spot in the code where IO is set. From the error is appears to be set to 5, that is the default input device.

writing to that device will generate an error.

Change that value from 5 to any number but not 0, 5 or 6. (try 11)

Jan Jaap

Look at line 370. Change the

Lorri_M_Intel — Mon, 30 Dec 2013 16:14:37 GMT

Look at line 370. Change the second "5" to a "6", and that will get you past the initial failure.

That said, you'll have to step through the program in the debugger enough to figure out what it wants; I got as far as it asking for "Model Order", and I have no idea what the correct response is.

--Lorri

Thank you for your help.

Tony — Mon, 30 Dec 2013 18:01:08 GMT

Thank you for your help. After I enter "Model of Order" as "1", "Drift Parameter" as "N", "Discontinuity" as "N", "How many explanatory variables" as "1" and "Number of Data Points" as 72. Errors occurred: The program '[2392] WARPS.exe: Native' has exited with code 47 (0x2f).

VARIABLES INDEXED 1 THROUGH 3

forrtl: severe (47): write to READONLY file, unit 5, file CONIN$

I think the problems are in the subroutine "RDATA".

With best regards,

Tony

This is ancient Fortran code

andrew_4619 — Mon, 30 Dec 2013 18:24:21 GMT

This is ancient Fortran code doing all manner of awful things with data that sort of worked in a by gone age on long dead computers, such as storing character data as (35bit???!!!! yes I meant 35) real numbers (Fortran 66 did not have character variables). Large swathes of this code would disappear if it were coded today.

Do you need to use this code? What does it do? There are many sources of much more 'free' routines that would do the sort of stuff discussed in the program header....

Just took a look/see at the

bmchenry — Mon, 30 Dec 2013 19:55:08 GMT

Just took a look/see at the code. it has some Fortran-66 and/or previous development environment issues, however once you clean it up a bit it should work/run fine on INTEL Fortran. I've moved many programs, thousands of lines of code from Fortran-66 forward and there are only a few issues and then you will be good to go.

the program appears to be well documented so you should be able to figure out what they are doing. and yes, back in the day character data was stored in read (4 characters per Real*4 variable) and using equivalences you can still do it (to get running) and then perhaps update some of the older items.

first recommendation i'd have is: understand what the program is trying to accomplish, and see if there a better/easier solution available? Spline fitting and Regression Analysis are available free all over the web. also some 'for fee' books/code like Numerical Recipies, whcih will also help you understand Fortran code. (they have an old school version and a Fortran 90 version) and many free math libraries.

Note it also appears to use Hollerith data and that's i believe no longer supported, but no sweat! simply go to those character variables and enclose them in quotes rather than using Hollerith. So 4HTHIS simply becomes 'THIS'

i believe there are a number of good writeups on the web about moving code from ANSI-66 to modern day Fortran code. I'd get up to speed on them. And don't be one of the lemmings moving all your code to C++, there is no point. It's a waste of time since you can easily link with C++ code if parts would be better accomplished with C++.

I'd suggest you do the minimum changes required to get up and running.

Thank you for your help. I

Tony — Tue, 31 Dec 2013 04:07:22 GMT

Thank you for your help. I don't really want to change the code. Do you have any libraries to suggest me for compiling this program? Or any website can help me to rewrite the subroutine "OFILE", "RFLIE", and "RDATA".

With best regards,

Tony

Tony,

John_Campbell — Tue, 31 Dec 2013 04:58:32 GMT

Tony,

You have many things to change to get this program to run and probably more changes to make it run well. From the first example you have posted I can see that:

DOUBLE PRECISION FNAME : this indicates that FNAME is being used as an 8-byte character variable, as Fortran 66 did not have characters. You would be best advised to convert all character use to CHARACTER variables. (You need to check which F66 compiler was used to confirm how many characters were stored in a DOUBLE PRECISION variable). The most significant change from F66 to now is the introduction of character variables. It is much better to change to character variables, if you can identify when integer or real variables were used in this way.

IO appears to have a value of 5. I would change this to 15 ( greater than 10). F66 did not have a interactive / screen option so typically used units 5 and 6 for input and output. More recent compilers can use units 1 or 5 for input and 1 or 6 for output. Units 7 and 8 were also used by some compilers for the tape drive or an error unit.

The arguments (connect-specs) of the OPEN statement are also standardised with F90. READONLY can be replaced by ACTION='READ'. Most of the connect-specs can be omitted, as the defaults usually work. The following is probably all you need. I'd recommend that you always use iostat=.. for an OPEN statement, then check the value.

CHARACTER FNAME*8
OPEN ( unit=IO, file=FNAME, action='READ', iostat=IOSTAT )
if (iostat /= 0) write (*,*) 'Error opening file :',FNAME,' on unit',IO,' : iostat=',iostat

Knowing what other changes will be needed requires some knowledge of F66 and F90+. Other changes you will need to address have been the use of generic functions and also the standardization of DO loops.

Hopefully this will give you some understanding of what you have to do to fix the errors you have reported. I will look at what you have attached and provide further suggestions.

John

Thank you for your help. I

Tony — Tue, 31 Dec 2013 06:56:35 GMT

Thank you for your help. I have changed the open statements as your comments. I have changed the variables 'FNAME' and 'FNUL' from DOUBLE PRECISION to CHACATER FNAME*8,FNUL*8. I find out that XDAT and FMT are also in DOUBLE PRECISION in line 457, I don't know do I need to change them or not. I can't find which line the program set the IO as 5, I can only find the following statement: DATA IO5,IO6,IO20,IO21,IO22/5,6,20,21,22/ in line 374 in my attached file. After that, the same error occurred.

With best regards,

Tony

Hi Tony -

Lorri_M_Intel — Tue, 31 Dec 2013 12:28:00 GMT

Hi Tony -

Let me introduce you to the wonders of "traceback". Make sure you still build with the /traceback option, so the feature is enabled.
When you run your program, and it has a runtime error (like the one you have here) you also get information about where in the program it failed.
Included in this information is the call stack, starting in the runtime library, and giving information about where in the original source code the runtime error originated.

And, that is true with your program. The traceback lists where in "warps.f" the error occurs, including which routine, and line number.

So then, please, run your executable, and look for the traceback information.

It is a stack, where the top address will be in the runtime library, or perhaps Windows system library, but as you look down the list of traceback entries, you'll come across one that comes from source "warps.f", with a line number.

Look at that line number in the source, and see if there's anything "interesting" there.