Old Fortran Program

[JohnNichols]

Steve:

I came across an old Fortran program from UCLA.  It is a very useful program and the site provides a copy of the program complied in Compaq Fortran in 32 bit.

I tried unsuccessfully yesterday to compile the program.  I broke it down into reasonable units and slowly worked to fix some things.

But when I get to the FEM module - it starts and never stops on the compiler.  I stepped through it by adding back a line at time, but could not spot the error.  If I did not have a working EXE I would wonder, but there is a working exe in Windows.

Any ideas, I enclose the original code and the modifications I made. It is an interesting program that has the potential to save lives in earthquakes so I am keen to get it working.  If I cannot I will rewrite the algorithms in C#. 

JMN

[JohnNichols]

It is on Windows 7.1 VS 2013 Professional and Latest Intel Compiler.

[JohnNichols]

It is on Windows 7.1 VS 2013 Professional and Latest Intel Compiler.

[JohnNichols]

64 bit Dell Precision machine running Intel Processor

[TimP · Accepted solution]

There appear to be plenty of real vs. double precision inconsistent usages.    Strange that they express double precision constants in just 8 digits, as was the custom for single precision on the 36-bit platforms of the old days.

gfortran  lists them more expeditiously.

What happens if you do a wholesale editor conversion to make them all the same, e.g real(real64) ?

http://fortranwiki.org/fortran/show/Real+precision

Obsolescent f77 style CHARACTER declarations and statement functions shouldn't be a problem, if in fact they are used in accordance with f77.

I suppose it's a bug when ifort chokes on bad source files.  I'm not surprised that -real-size:64 doesn't fix this.

As far as parameters passed between procedures were concerned, CVF could work with inconsistent real types in almost single precision due to both single and double precision being passed in consistent x87 register format.  I don't know whether ifort ia32 /arch:IA32 would tolerate this.

[JohnNichols]

Tim:

Thanks for the reply. 

I have some old Fortran code written in 1967 at UCB by some very good programmers in Fortran and it compiles quickly and efficiently. This is just a nightmare to fix. 

I have data and answers, but I spent most of yesterday just getting it to a part way stage of working.  But back to the fold.

Wish 1:  C# would work nice with Fortran.  Steve C# is not going away and the ability to work seamlessly would be nice.

Wish 2: FORTRAN IS SPELT FORTRAN AND NOTHING ELSE NO MATTER WHAT ANYONE SAYS

Wish 3: Chinese for lunch

(1 out of 3 is not bad)

JMN

[JohnNichols]

Steve:

OK, so I start to rewrite the program to make it - compile.

I get this far and am told  when I compile it is not a valid windows program.

When I uncomment DVLAST

REAL FDV(16008, 16008)

!REAL DVLAST(16008, 16008)

!REAL BASAL(16008,16008)

never had this before.

Help

JMN

[Steven_L_Intel1]

I don't see the behavior you describe. I do see /warn:interfaces reporting multiple errors in the sources.

[Steven_L_Intel1]

Builds and runs fine for me with those arrays uncommented. The arrays aren't big enough to pose a problem with exceeding 2GB static code and data. Are you running on the same system you are building on?

[JohnNichols]

Error 1  fatal error LNK1248: image size (AFB68000) exceeds maximum allowable size (80000000) LINK 
 

Steve:

This is the error that I got when I ran the one with the arrays declared. 

JMN

[JohnNichols]

Steve:

If I create a new Console Application and load the Shell-copy.for program, which is all of it - after ten minutes I see the screen attached.

Yes I am running it on the same machine

JMN

[Steven_L_Intel1]

If you get the link error, that means there is too much data for Windows and yes, you'll get an error that it is not a valid executable. I didn't see that when I tried it.

When you have the whole thing in one source, it can take a long time. I'll take a look at this.

[JohnNichols]

Steve:

it is some obscure error, when the program compiles on this machine it is fast, I have a 1 TB flash drive, the slowest thing on this device is the Intel Processor.

I feel that a rewrite is needed - proceeding slowly

JMN

[FortranFan]

John Nichols wrote:

...

Wish 1:  C# would work nice with Fortran.  Steve C# is not going away and the ability to work seamlessly would be nice.

..

C# (and any other Microsoft .NET language e.g., Visual Basic) does indeed work well with Fortran.  What specific issues are you facing?

[FortranFan]

John Nichols wrote:

..

I feel that a rewrite is needed - proceeding slowly

..

Going by your original comment and this quote, I gather you're rather keen on rewriting the code and presumably doing so in C#.  Considering the effort required to finish such a task and the fact that the code had worked in Compaq Fortran (per UCLA site info), I find your keenness quite strange.  Having ported quite a few large projects from Compaq Fortran to Intel Fortran (and amazed how easy that was) and assuming the UCLA site is being truthful about a working version in 32-bit Compaq Fortran, I feel one can almost guarantee this code will work in Intel Fortran.  Sure, one may need to follow a few things as explained by Steve in https://software.intel.com/en-us/articles/migrating-from-compaq-visual-fortran, but it's nothing compared to the effort of a rewrite.  I suggest a reconsideration of your plan unless that is your end goal any way, in that C# and .NET are the tools you now prefer, in which case the compiler issues here are largely immaterial and they are not the true reason for a rewrite.

A side-bar: I also find your approach contrary to the myth you showed interest in dispelling in https://software.intel.com/en-us/forums/topic/505761.  I feel it is akin to dropping Fortran at the proverbial "drop off a hat": if everyone felt compelled to rewrite working code on account of a few compiler difficulties, Fortran would indeed be dead or die soon!

Besides, I'd feel compelled to retain Shells as code that can definitely work freely on a broad range of platforms (hardware architectures) under some public license (e.g., GNU) and either keep it as Fortran or in the worst case, as C++ (gcc) or Python.  I do also code extensively in C#, Visual Basic.NET, VBA, etc. and I would not pick a Microsoft "product" as my tool of choice for Shells.

My 2 cents,

[JohnNichols]

Dear Fortran Fan:

Thank you for your comments. This shells code is problematic.  It is in a field I barely understand in terms of the physics, it has some very old constructs mixed with modern and it has some interesting steps in the logic. I need it however to do stuff I want to do.

My initial concern was that I would run into the same Fortran compiler problem and as I do not fully understand the physics I was worried that I would be stopped again.  The problem of the compiler not returning is not a nice one to run into, it is one of those obscure errors I am sure Steve will solve. I started for 20 minutes in C# last night, but after the comments this morning and thinking about it I decided if it needs a rewrite then in Fortran is the best choice, but fix all of the bugs one line at  time and make sure it is working. 

I have one working version so I can compare the answers. I spent the day reworking the code and taking out all of the implicit opens and the non declared variables, so far. There are about 12 major routines and I just finished the second.  I am making all of the variables Double Precision and Integer(8), makes it easy to work.  The data format in the files is really interesting, and it is read twice to determine the lengths of each data set.

The real problem is that the author used the ISML library and I do not have the research funds to buy it. The matrix inversion program in the ISML program if I read this code correctly uses a single vector to hold the standard matrix A for X = b.  The method used to construct the vector version of the A matrix is not that obvious to follow, I will work it out but I am not looking forward to it.  There are several excellent invertors that can handle a square matrix, I will probably use the NAG one, although CONTE and DE BOOR"S is always a simple backup. (Speed would be an issue, or th...

C---------------------------------------------------------------------
C                           COMMON statements
C
C Note: Un-named COMMON passes INTEGER variables used in the
C       INTEGER  FUNCTION INDEXK, to avoid passing these same
C       through long sequences of subprograms.
       COMMON LDA,NUCA,MXWORK

C
C   Statement function replacing INTEGER FUNCTION subprogram INDEXK:
       INDEXK(IROW,JCOLUM) = (JCOLUM-1)*LDA + NUCA + IROW - JCOLUM + 1

I have never used a function like INDEXK - (see above) and the use of common blocks is nice but archaic. Fixing them is not a big problem.

(How the heck does INDEXK - work) Intel Fortran did not seem to like it - see below.

TOPONE=MAX(TOPONE,K(INDEXK(I,I)))

So Fortran it is, I reckon about a week allowing for all of the likely stuff going wrong.

Regards

JMN

[FortranFan]

Attached is a zip file of my attempt at compiling and linking this program.  With the settings I tend to use, the compiler does hang up on pure.for when I select the Debug configuration, regardless of whether the target platform is 32-bit or 64-bit.

However, the Release configuration (even with /O3 setting) for both the target platforms compiles and links without any issues - you can peruse the BuildLog.htm file in the zip for details.  Of course, the crucial call to DLSLRB solver from IMSL is commented out, so the code won't execute correctly.

It took less than 10 minutes to get this far after downloading <Shell - Copy.for> from OP - kudos to Intel on making it so easy to rebuild old Fortran programs in Visual Studio.

Steve,

Any idea why pure.for causes the compiler to hang up in Debug mode?

[FortranFan]

John Nichols wrote:

...

C---------------------------------------------------------------------
C                           COMMON statements
C
C Note: Un-named COMMON passes INTEGER variables used in the
C       INTEGER  FUNCTION INDEXK, to avoid passing these same
C       through long sequences of subprograms.
       COMMON LDA,NUCA,MXWORK

C
C   Statement function replacing INTEGER FUNCTION subprogram INDEXK:
       INDEXK(IROW,JCOLUM) = (JCOLUM-1)*LDA + NUCA + IROW - JCOLUM + 1

I have never used a function like INDEXK - (see above) and the use of common blocks is nice but archaic. Fixing them is not a big problem.

(How the heck does INDEXK - work) Intel Fortran did not seem to like it - see below.

...

Look here - https://software.intel.com/en-us/node/467492 - for information on statement functions, "syntactic sugar" from old that was made obsolescent in the Fortran 95 standard.

However Intel Fortran generally works perfectly fine with statement functions, but I don't know if there is a compiler setting that forces an error on an obsolescent feature and you're applying such a setting.

[FortranFan]

John Nichols wrote:

Dear Fortran Fan:

Thank you for your comments. This shells code is problematic.  It is in a field I barely understand in terms of the physics, it has some very old constructs mixed with modern and it has some interesting steps in the logic. I need it however to do stuff I want to do.

My initial concern was that I would run into the same Fortran compiler problem and as I do not fully understand the physics I was worried that I would be stopped again.  The problem of the compiler not returning is not a nice one to run into, it is one of those obscure errors I am sure Steve will solve. I started for 20 minutes in C# last night, but after the comments this morning and thinking about it I decided if it needs a rewrite then in Fortran is the best choice, but fix all of the bugs one line at  time and make sure it is working.

I have one working version so I can compare the answers. I spent the day reworking the code and taking out all of the implicit opens and the non declared variables, so far. There are about 12 major routines and I just finished the second.  I am making all of the variables Double Precision and Integer(8), makes it easy to work.  The data format in the files is really interesting, and it is read twice to determine the lengths of each data set.

The real problem is that the author used the ISML library and I do not have the research funds to buy it. ...

So Fortran it is, I reckon about a week allowing for all of the likely stuff going wrong.

...

Glad you've decided to stick with Fortran.  Based on what you say here, a rewrite in C# would be an even harder task.

You may have seen Steve's blog on some recent books on Fortran: https://software.intel.com/en-us/blogs/2013/12/30/doctor-fortran-in-its-a-modern-fortran-world.  The main book he reviews is written by IMSL folks and they have a good section on a systematic approach to upgrading old code - worth a read and following their recommendations for your task.

Re: IMSL routine DLSLRB and replacing it an open source alternative, check out http://www.netlib.org - I feel even LAPACK should work in this situation.

[jimdempseyatthecove]

John Nichols wrote:

C---------------------------------------------------------------------

C   Statement function replacing INTEGER FUNCTION subprogram INDEXK:
       INDEXK(IROW,JCOLUM) = (JCOLUM-1)*LDA + NUCA + IROW - JCOLUM + 1

I have never used a function like INDEXK - (see above) and the use of common blocks is nice but archaic. Fixing them is not a big problem.

(How the heck does INDEXK - work) Intel Fortran did not seem to like it - see below.

Think of statement function (declared between the end of the variable declarations and the first executable statement) as an analog of the C preprocessor (or Fortran preprocessor)

#define INDEXK(IROW,JCOLUM)  (JCOLUM-1)*LDA + NUCA + IROW - JCOLUM + 1

Jim Dempsey

[JohnNichols]

Dear All:

Thanks for the help.  I only write code for myself so I never get to the release stage, that idea never occurred to me.  I wonder what is happening.  I thought I was going crazy for a few hours at one stage. 

Why anyone would use inline functions is beyond me, makes the code to hard to read.

The failure to use implicit none has the potential to leave in bizarre errors, so I will keep working through the code.  It has already turned up some interesting problems. One set of variables was not declared, used as multipliers and included in a common block. It was then set to the appropriate values later in the code. 

Like all things Fortran it is a learning experience. 

Let me recount a recent experience, this masters student wants to do image recognition of cracks in pavements. He has this wonderful camera takes really excellent high resolution shots, he took the shots and I suggested we look at the problem a little first before he presented the idea to the committee, I asked him to write a short program to colour the picture either black or white depending on the colour of the existing pixel, was colour enough to tell where the crack was on the picture.

He went away and I looked at the problem. took about ten minutes to write the code to do the exercise. Actually it worked, at least as far as human vision was concerned. The student talked to his friend in engineering who said - use matlab. Took them several hours to get a matlab program running. he showed it to me on the Monday. Strange I thought, I asked why not use a program, his friend only learnt matlab. 

So I suggested that we translate the photo into an array of integers and contour it based on height criteria.  I did that in about 20 minutes, I have an excellent contouring package from Australia that was originally published in BYTE. I offered the student the program code, but he said matlab. They are still trying in matlab to get the output.

As engineers, we learnt to code in Fortran, Not hard and useful.  (My solution was in C# as it has some nice image manipulation routines. )

Why are we teaching matlab is beyond me, even a simple problem is hard.

JMN