Finite Element Fortran Program For Sale
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#.
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. 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.
Windows 7 64 bit activator скачать. After the activator works reboot the system. After rebooting, you can safely enjoy work of licensed activated windows 7 in corpore.
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. And I would not pick a Microsoft 'product' as my tool of choice for Shells.
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 AX = 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. 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 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?
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 -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. 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: 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 - I feel even LAPACK should work in this situation.
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. 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. F90 introduced the first reasonable alternative to statement functions. Up to about 10 years ago, statement functions often had better in-line optimization than alternatives. About the time compilers began fixing limitations of internal subprograms, they also started to drop the limitations on how the old statement functions could be combined with f90 syntax (according to restrictions placed on them in the standard). I put in the caution about using statement functions in accordance with f77 since much usage of them prior to f77 involved inadvertent use of extensions of various compilers (some of those reflected in the internal procedures of f90).
Tim: I spent an enjoyable morning inside the program. Once I had been taught that it would compile as release it was not that hard, just had to go back to putting write statements at the error points This reminded me of Microsoft Fortran 3.3.1 and the old Compaq portable. It was nice in those days, it took 40 minutes to compile a program so you had lots of free time to do things, Now with the flash drive this thing runs in no time, so you only leave your seat to get another coke. Thanks for the note on inline functions, I have programmed since 1978, but there is no way I would use such a beast. It appears to be working.
The problems this morning related to DATA statements not being read properly, my fault. I am now at the stage of sorting out the Stiffness matrix and turning it from a vector to an array. John Nichols: Attached is a zip archive containing two files: the source file from, modified just enough to allow us to replace the calls to IMSL routines by equivalent calls to MKL routines, and an input file that I created. I tested the IMSL and MKL versions using Step-7 of the instructions. To compile the source files, do i fort /Qmkl /fpscomp:filesfromcmd shellsm.f OR ( ifort /Qimsl /fpscomp:filesfromcmd shells.f, for the unmodified version). Download the input data files named in the instructions to the working directory on your machine.
Then, at the command line, do shellsm. Dear MECEJ4 Thank you for your kind work on this project.
I have not used the Fortran compiler directly since the 1990's so it did not cross my mind. It is a brilliant suggestion.
I have never played with the MKL libraries before this program. I spent yesterday afternoon looking at the documentation for the MKL libraries and had thought I had found the packed solver in the MKL library would replace the ISML library. I went through the parameters and had sorted out how to make the call. Your kind email landed about that time and looking inside your code, I noticed that you had found the error in the packing code that one variable was ignored in the transform equation. I had printed out results and the variable always had a value of zero, so I had ignored that issue, but thanks for the fix.
Finite Element Code
As you kindly showed it works nicely with ifort. I would also like to learn why I am having so much trouble with MKL. I have set the 32 bit environment variables, turn on the release mode and set the box inside the program properties to INCLUDE MKL libraries. The program compiles, but does not find the MKL. I am running mkvars in the VS command prompt window.
But when I check the environment variables there is no sign of the added MKL variables. Am I supposed to make all the link connections inside the program properties instead of taking the shortcut step. I prefer not to go fooling with the system variables. There is no problem using the IFORT, but not getting the other way going knaws at my mind.
( I realize knaw is obsolete, but so am I in this modern world.) Professor Bird from UCLA has developed an excellent idea. He has split the world's surface into essentially triangular shapes, he joins them with appropriate boundary conditions and then solves the FEM mesh he has created to determine the stress and strain tensors. It is a major undertaking and he is to be congratulated on doing such an excellent job on such a massive task. This code is 12000 lines and it is well commented. He also has a program to generate synthetic earthquake catalogs. Ie estimates of future seismicity (SEC).
This program also uses the packed solver, so I will go straight to the IFORT solution. SEC takes as one of its input files an output file from shells. I am looking to slowly vary the variables within the SHELLS program to generate a set of solutions and then use them in the SEC to get a huge range of catalogs. From that I will look to estimates of the death toll.
So thank you for all the help. While I have been working on this project I stumbled across a plan of a pipe crusher from IOWA State Uni in a 1913 book. YOu can see the PDF of the original as an attachment. This was state of the art in 1913 at the best AG Eng school in the world. We have come a long way in a century.
JMN JMN Attachments. John, regarding your comments on storing a square matrix in a vector: This is indeed common, especially if the matrix is tightly banded or sparse. A variety of techniques has been developed to take advantage of the extreme memory storage savings that is possible. One that I learned many years ago is called 'skyline' storage, but even this is old technology and better ones probably exist. In general, they all aim to extract only the populated elements of the matrix and then 'line them up' in a vector with appropriate pointers to maintain their original matrix locations. Is your problem, by any chance, related to finite element analysis (FEA)?
If so the above is very likely. JMN: I did not use your modified version of the PeterBird source file, since I wanted to start with the reference source file, which the authors have documented quite well.
In substituting the IMSL calls by MKL/Lapack calls, all that I need to do in addition was to replace the INDEXK statement function declarations to indexk(irow, jcolum) = (jcolum-1).lda + nlca + nuca + irow - jcolum + 1 To make this work, I added NLCA to the blank common, and set LDA = NLB+NLB+1+NUB in Subroutine KSIZE. Creating a project for IFort using MKL is easy. Start VS, create a new Intel Fortran console application, and add the single Fortran file to the project sources. Next, in the project properties, go to Configuration Properties-Fortran-Libraries and select one of the options for 'Use Intel Math Kernel Library'.
If you have a working IFort/MKL installation, you should be able to build the project with no special Fortran options. The (subjective) impression that I have gathered about the SHELLS program is that it is high quality. One measure of the quality is that I was able to make the conversion from IMSL to MKL with little effort. I have built and run the program with three different compilers, 32-bit and 64-bit, and they all yielded similar results.
We have to be careful in judging such codes that we do not apply today's standards to code from fifteen years earlier. ASIDE:By 'knaw' do you mean 'gnaw' but by a toothless antagonist? Steve: - Do I have to do something like this to get the Shells program working nicely with the MKL routine ie use an OBJCOMMENT?!call dgbsv(n,nlca,nuca,nrhs,A,ldab,ipiv,B,ldb,info) Because I can not get them to run nicely at the moment.
The LAPACK program works nicely once I add in the statement below. John - add the line:!DEC$ OBJCOMMENT LIB:'mkllapack95.lib' to your source (just after the PROGRAM statement is fine.) The LAPACK routines are not linked in by default. Dear MECEJ4: Professor Bird has a vast set of programs all in Fortran. I will slowly work my way through them working out how to use them to solve my problems.
Finite Element Method Pdf
I was looking at the MKL problem with the VS version of shells, so I took some time and read the ISML, MKL and Numerical Recipes in Fortran stuff on the packed routines. (I would not be surprised if they all share a common ancestry, although it would be nice if they used the same symbols. So I added the F90 Numerical Recipes in Fortran routines into shell and failed. Going back one step I got the F77 recipes code to work for the first stage of the dgbs program. The shells program iterates about 50 times on an array that in real terms is 32000 by 32000. In the MKL version an iteration is a few minutes, in the ISML it is a lot longer, but in the F77 version the following code: do 18 k=1,n write(.,.)k,n dum=a(k,1) i=k if(l.lt.n)l=l+1 do 14 j=k+1,l if(abs(a(j,1)).gt.abs(dum))then dum=a(j,1) i=j endif 14 continue indx(k)=i if(dum.eq.0.) a(k,1)=TINY if(i.ne.k)then d=-d do 15 j=1,mm dum=a(k,j) a(k,j)=a(i,j) a(i,j)=dum 15 continue endif do 17 i=k+1,l dum=a(i,1)/a(k,1) al(k,i-k)=dum do 16 j=2,mm a(i,j-1)=a(i,j)-dum.a(k,j) 16 continue a(i,mm)=0. 17 continue 18 continue takes 4.5 hours for a single iteration.
MKL is way faster, but not nice to link in. Steve: I cannot get the shells program to execute after compiling within VS 2013 using the MKL libraries. It executes after being compiled with IFORT and /QMKL etc from a command prompt. This is a brand new installation of Windows 7.1 on a Dell Intel Core 7 processor, with lots of ram and a 1 TB flash drive. VS 2013 Professional was installed two weeks ago, with all the updates needed, the Latest Fortran was installed along with MKL after VS. There are no other VS studios or Intel Fortran I have used the VARBATS command and when I develop the program properties, they are in release mode with the MKL Link option selected. If they compile, then when the program runs it crashed VS or gives me a MKL.lib.dll not found error.
How do I take an old Fortran program - create a new VS solution, add a call to a MKL routine mainly GBSV for example so that it will run when it is compiled. Shells is a pretty straightforward program, the implicit none problem aside, it does run in IFORT and gives answers that look reasonable.
MKL is significantly faster than ISML for this routine and much much faster than the Numerical Recipes in Fortran. Clearly I am missing something simple. Can you please try SHELLSM.f. It compiles with IFORT but if you can get it to compile on VS and even start I will be very happy. You do not need input files, it will not even start. You might try in debug mode as it will not even compile or tell you the offending code.
Am I missing some link or DEC commands? That is what I mean by not run nicely. JMN Attachments. So the problem is the run-time error about the missing DLL?
That's because the path to the MKL DLLs aren't added to PATH by default. Right click on 'Computer' on your desktop and select Properties. Click on Advanced System Settings, then Environment Variables on the Advanced tab.
Under System Variables, scroll down to Path. Select that and click Edit.
Insert at the end:;%IFORTCOMPILER14%redist intel64 mkl;%IFORTCOMPILER14% redist ia32 mkl Click OK, OK, OK. That should remove the DLL error. You may need to log out and in again for that to take effect. I can see the problem with the large Shell source not compiling and will send that on to the developers. Consider this: do 918 k=1,n write(.,.)k,n smallestMag(k)=abs(a(k,1))! SmallestMag(n) i=k if(l.lt.n)l=l+1 do 14 j=k+1,l if(abs(a(j,1)).gt.smallestMag(k))then smallestMag(k)=abs(a(j,1)) i=j endif 14 continue indx(k)=i 918 continue do 18 k=1,n if(smallestMag(k).eq.0.) a(k,1)=TINY if(i.ne.k)then d=-d do 15 j=1,mm dum=a(k,j) a(k,j)=a(i,j) a(i,j)=dum 15 continue endif do 17 i=k+1,l dum=a(i,1)/a(k,1) al(k,i-k)=dum do 16 j=2,mm a(i,j-1)=a(i,j)-dum.a(k,j) 16 continue a(i,mm)=0.
17 continue 18 continue Jim Dempsey. Jim: I will run it tonight and let you know. The problem with the packed array, is that it is almost all still zeros.
Finite Element Method Book
The bound limit is 1400 for 32000 nodes, but on most lines there are only three triangles, ie triangle 1 can touch say 2,3 and 4 but not the other 10,000 triangles. (I printed out a few sets of the rows). It would be a lot more efficient to pack a duple with the (I,J) and a vector with the value from A. Should be able to do it with a lot less entries. Why play with zeros at all? In the matrix manipulation you never play with more than one value or two values at a time, so a lookup of an ordered I,J has got to be a lot faster. Perhaps I am missing a point.
The point of using two do k loops is to increase cache locality (at least L2),.AND. Should the 0 plus other data not fit entirely in RAM, then decrease then number of page faults. Note, with cache line of 64 bytes, 16 floats fit in cache line. The first loop is reading down a column with a stride of 32000. Assuming no data in cache to begin with the first column read will encounter 32000 (cache lines) requiring 32000 x 64 bytes of cache, which is 2MB, which generally fits in L3 cache. Running the code will verify if it helps or not.
It is a simple enough change to test. John Nichols, #30 wrote:(emphasis added) The shells program iterates about 50 times on an array that in real terms is 32000 by 32000. In the MKL version an iteration is a few minutes, in the ISML it is a lot longer, but in the F77 version the following code: takes 4.5 hours for a single iteration. MKL is way faster, but not nice to link in.
JMN I don't know which problem you ran and obtained results, but when I ran the MKL version SHELLSM.f on a laptop with an i7-2720QM CPU, with 4 cores X 2 hyperthreads/core= 8 threads, on the problem data listed in #24, the matrix is 32016 X 32016, with upper and lower bandwidth = 1451, and the program took only 8.5 seconds per iteration. The same program when run on a tablet/laptop with an i5-4200U CPU (2 cores, 4 threads) takes 9.5 seconds/iteration, so you should be able to get decent throughput on a properly outfitted engineering workstation with a multi-core CPU. I got part of the changes running and it was way faster. As it finished the code gave me an access violation issue and I was trying to sort it out. 7 year old got in the road. I ran the Shells program from the IFORT build and got 45 seconds per iteration. If you are getting 9 seconds per run, then I am not running on separate processors, but you are.
MKL and VS are a dud together and it is time to forget this combination. IFORT and MKL are the way to go. (Like going back to the 80s) I have two machines, a Dell Precision which I like because I can take it anywhere and a special build using an ASUS motherboard and a lot of processing power, but it is not portable so it plays music most of the day. The IT guys say it is the fastest in the building.
They like it, because when I upgrade it they got the parts, that are better than what they normally have. I believe I have the only special build in the building. It is time to move onto the next program in the shell set. John Nichols wrote: MKL and VS are a dud together and it is time to forget this combination.
IFORT and MKL are the way to go. (Like going back to the 80s) I think that you are laboring under a couple of misconceptions. VS does not include a Fortran compiler, libraries or runtime DLLs. It gives you a language-sensitive and customizable editor and a GUI front-end for using the same compiler and libraries as you use when building at the command line.
Compiler options that you specify in the compiler invocation from the command line have equivalent configuration / menu choices. When you say 'Build' from the VS IDE, what happens is the same sequence of events that happens when you compile from the command line. Think of VS as an agent which collects all your desired options, and issues the correct command on your behalf, in the correct command line syntax (which, you say, is 'like going back to the 80s'). In a sense, the IDE lets you issue commands without being caught in the act of committing decadent deeds. As Steve Lionel has stated, it is quite easy to use MKL from VS or the command line for a project that consists entirely of Fortran sources and the simplest way of using MKL is sufficient.
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. 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,. 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. 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. 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.