topic Tim: in Intel® Fortran Compiler

Old Fortran Program

JohnNichols — Thu, 17 Apr 2014 15:37:42 GMT

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

It is on Windows 7.1 VS 2013

JohnNichols — Thu, 17 Apr 2014 15:39:31 GMT

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

It is on Windows 7.1 VS 2013

JohnNichols — Thu, 17 Apr 2014 15:39:36 GMT

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

64 bit Dell Precision machine

JohnNichols — Thu, 17 Apr 2014 15:41:18 GMT

64 bit Dell Precision machine running Intel Processor

There appear to be plenty of

TimP — Thu, 17 Apr 2014 16:18:27 GMT

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.

Tim:

JohnNichols — Thu, 17 Apr 2014 16:35:34 GMT

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

Steve:

JohnNichols — Thu, 17 Apr 2014 18:01:23 GMT

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

I don't see the behavior you

Steven_L_Intel1 — Thu, 17 Apr 2014 18:08:31 GMT

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

Builds and runs fine for me

Steven_L_Intel1 — Thu, 17 Apr 2014 18:13:21 GMT

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?

Error 1 fatal error LNK1248:

JohnNichols — Thu, 17 Apr 2014 19:09:36 GMT

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

Steve:

JohnNichols — Thu, 17 Apr 2014 19:15:26 GMT

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

If you get the link error,

Steven_L_Intel1 — Thu, 17 Apr 2014 20:14:10 GMT

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.

Steve:

JohnNichols — Thu, 17 Apr 2014 20:34:11 GMT

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

Quote:John Nichols wrote:

FortranFan — Thu, 17 Apr 2014 21:40:16 GMT

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?

Quote:John Nichols wrote:

FortranFan — Thu, 17 Apr 2014 23:14:00 GMT

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,

Dear Fortran Fan:

JohnNichols — Fri, 18 Apr 2014 03:42:09 GMT

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 the Intel one.)

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

Attached is a zip file of my

FortranFan — Fri, 18 Apr 2014 04:16:00 GMT

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?

Quote:John Nichols wrote:

FortranFan — Fri, 18 Apr 2014 04:44:09 GMT

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.

Quote:John Nichols wrote:

FortranFan — Fri, 18 Apr 2014 05:35:00 GMT

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.

Quote:John Nichols wrote:

jimdempseyatthecove — Fri, 18 Apr 2014 12:50:44 GMT

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