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.

COMPUTER IMPLEMENTATION OF THE FINITE ELEMENT. O/S 360 FORTRAN CODE FOR FINITE ELEMENT METHODS. Majority of the program would remain unchanged for more. FORTRAN BASED FINITE ELEMENT APPLICATIONS IN A SCRIPTING. Gnadsmekanik l¨ar ut tekniker f ¨or att implementera finita element program. 152 Appendix E Fortran Code of the Finite Element Program Containing the Concrete Plasticity Model. Chapter 2 - Basic Elements of FORTRAN. 2.3 Structure of a FORTRAN Statement. A program consists of a series of statements designed to accomplish the goal of the task.

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#.

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)? 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: 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. Fogware Digital Giggle Snort Hotel. 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. 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 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 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.