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]

Dear Guys:

Thank you for your replies.

I enclose screen shots for the various steps I have followed to address the matter.

I enclose the build log for the VS Project Build for the original shells, exactly the same as the Fortran file for the IFORT Build.

Path shows the path command fixed for the Compiler Fortran

What I cannot understand is why the exe size for the IFORT build is 5 MB and for the VS build is 0.5 MB?

I was trying to run the VS build using shell < sh.inp at a command prompt. It did not work, just disappeared. So while I was typing this, I went into shells and put in real file open commands not implicit commands as Prof Bird had them.

It ran beautifully thank you.

I had an iteration time of about 10 seconds.

So why is the IFORT build so big, why does the IFORT build take 45 seconds per iteration and the VS studio 9 seconds?

It has been fun.

JMN

[Steven_L_Intel1]

The size difference is because the default for builds in VS is to link to DLL libraries while the default for the command line is static libraries.

[FortranFan]

John Nichols wrote:

...

I enclose the build log for the VS Project Build for the original shells, exactly the same as the Fortran file for the IFORT Build.

...

What I cannot understand is why the exe size for the IFORT build is 5 MB and for the VS build is 0.5 MB?

...

So why is the IFORT build so big, why does the IFORT build take 45 seconds per iteration and the VS studio 9 seconds?

...

John,

1. I think you're using the wrong terminology in terms of "VS Project Build" and "IFORT Build": it should be build using the Visual Studio IDE versus the command line (or a makefile/batch script).  Note you're getting to the same thing in both these approaches i.e., IFORT compiler.  It is just that in the former you're doing so via a user-interface in the form of Visual Studio whereas you're interacting with IFORT more directly in the latter via commands and like.  If the compiler options are the same, the output (exe/dll files, etc.) will be equivalent (identical even) with both the approaches.
2. You don't provide information on the compiler options you use with the 2 approaches: Visual Studio project (.vfproj) file and the command line syntax/file utilites you use.  With the command line build that creates the larger size file, it is possible you've some "debug" type of configuration specified with lower or no optimization which results in a larger file and slower execution.

By the way, do your comments in this thread along the lines of "this old Fortran program won't work, hence rewrite in C#", "this UCLA code is hugely problematic",  "MKL doesn't work nicely with VS" have an underlying purpose of some sort since the reality is highly positive in getting such code to work reliably and efficiently using Intel Fortran.  I don't think they are necessary to elicit assistance from readers on this forum.

[JohnNichols]

Dear Steve:

Does the difference between static and dynamic libraries explain the difference in time of 9 and 45 seconds. The 9 seconds has been achieved by 2 people and the 45 I timed last night?

Thanks for your help.

JMN

[JohnNichols]

Dear Fortran Fan:

I really appreciate your comments and to a large extent I agree and understand them.

It would be extremely counter productive to comment further in this case, sometimes it is best to let dogs lie sleeping in the sun, but I honestly see your point and will try not to repeat this mistake. From my experience, the people on this board are some of the best Fortran programmers in the world, and they share their knowledge unstintingly. (Myself excluded)

The interesting issue for me was the mkl libraries, I know I have tinkered with them before, but it was a deal harder than I anticipated, but I did not realize that there were similar routines in the ISML and MKL libraries. I have a copy of the numerical analysis library in Fortran and it has been useful up to this problem.

In hindsight I should have set up a small mkl problem and learnt the system before I leapt blindly into 12000 lines of code.

Intel make the best Fortran compiler in the world - this forum is great and so I can be productive.

JMN

[Steven_L_Intel1]

There should be no timing difference for static vs. DLL.

[Steven_L_Intel1]

John,

For your big Shells program, you can get it to compile by setting the project property Fortran > Diagnostics > Check Routine Interfaces to No. This is a bug which we will investigate and fix. Issue ID is DPD200255939.

[JohnNichols]

Steve:

Thanks.

Does this mean that the declarations of some variables may not match across the calls?

JMN

[JohnNichols]

Steve:

Worked perfectly : thank you

[FortranFan]

John Nichols wrote:

Steve Lionel (Intel) wrote:

John,

For your big Shells program, you can get it to compile by setting the project property Fortran > Diagnostics > Check Routine Interfaces to No. This is a bug which we will investigate and fix. Issue ID is DPD200255939.

Steve:

Thanks.

Does this mean that the declarations of some variables may not match across the calls?

JMN

Since it is only the Debug and not the Release configuration that is having the problem, I'd suggest just doing what Steve suggests i.e., turn off the interface checking only for the Debug configuration, an easy thing to do in Visual Studio.  This way, you can cross-check the code, especially if you make changes, by building the Release version every now and then.

[Steven_L_Intel1]

It means that there's a bug in the compiler's checking code - I don't know if there's a mismatch as it never got that far. Probably not, would be my guess based on what I saw so far.

[Steven_L_Intel1]

The compiler problem triggered by /warn:interface has been fixed for the 15.0 release later this year. It may also get fixed for 14.0 Update 4 (July, I think).

[Steven_L_Intel1]

We've fixed the bug that prevented the big Shells program from compiling. This fix should appear in both 15.0 and 14.0 Update 4.