Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

How to Compile .for file

carneiro__fernando
3,072 Views

How can I compile a .for file in Visual Studio (integrated with intel parallel studio XE)?

I can create fortran projects but they are created as .f90 files.

I need to use and modify some functions of a project in which all files are .for. If I create an Intel(R) Visual fortran project (Console application: main program code, which creates the .f90 file) and copy and paste all the code from my .for file into this new .f90 file, it won't work.

I need to create a project where I can add all the .for files that I have to be able to compile and run. How can I do it? Is there any Visual Studio version that allows that or other thing I can do?

0 Kudos
30 Replies
andrew_4619
Honored Contributor II
622 Views

carneiro, fernando wrote:

Would it compile if waited longer?

The program is indeed large, so I expect it to take really long to compile... I need the function the way it is... wating few hours would be the smallest of my problems now

Here I wait and then I have those errors I've shown before... which I believe are not syntax or similar...

"File Solver_Lapack_normal.for has 'o' in column 129, which is a bug."

Are you sure it is "solver lapack normal"? Because here the longest line in this file has 70 columns... (and the file has 88 lines)

The source has bugs with illegal Fortran. You need to fix it. the fact that some other compiler did not detect these errors is not relevant. What do you expect  Intel Fortran  to do when if find illegal or non-standard Fortran  that does not conform to any Intel Fortan extension? It cannot know what the behaviour of some previous buggy compiler was and then replicate it.

0 Kudos
gib
New Contributor II
622 Views

Compiling jacobian_deg.for with /extend-source on my PC, ifort works for a few minutes (using more than 3 GB of RAM) then says:

Fatal compilation error: Out of memory asking for 69640.
compilation aborted for Jacobian_deg.for (code 1)

This PC has only 8 GB.

0 Kudos
mecej4
Honored Contributor III
622 Views

Since IFort did not complete (even after 30 minutes) compilation of the large file Jacobian_deg.for with the checking options shown in the build log, I tried some variations on that file in an attempt to reduce the compilation time.

The subroutine calculates Coef(i) for i = 1, 2, ..., 115. Each element of this array is calculated using a long expression that the compiler will have to parse and compile. The combined expressions for Coef(115) span over a thousand lines.

What if each expression were walled off from the others? I broke up the subroutine into contained subroutines Coef_1, Coef_2, ...,  Coef_115, and compiled with /Od. Ifort 19.1 took 222 seconds, but produced an object file!

I observed that the terms in the expressions could be reorganized into groups of six products, each such group representing the determinant of a 3 X 3 matrix. For example, Coef(1) is expressed as the sum of 648 products of x, y, z coordinates. By rewriting the expression using a function det3(), we can reduce the expression to 108 calls to det3(), and the code for Coef(1) is reduced from 135 lines to 36 lines. To explore this idea, I decided to work with only the first ten elements of Coef rather than all 115. I verified that the results produced were identical, whether computed using the original expressions, or with expressions in terms of det3(). I found that the run times were very similar.

The test program is attached. Further reductions in run time appear quite feasible since there are many repeated invocations of det3() with the same arguments. Rewriting the expressions in terms of det3() reduced the file size to a third, and the compilation time (with /O2 /extend-source) from 45 seconds to 2.3 seconds, while leaving the run time and result values unchanged.

I suggest to the OP to study the issues carefully and implement a plan to rearrange the calculations in such as way as to make them more efficient and at the same time reduce the compilation time to no more than, say, 5 minutes.

0 Kudos
andrew_4619
Honored Contributor II
622 Views

Given the original Jacobian_deg.must have been written by a program  the programmer must have understood the logic of the sequences required to compute the coefficients. It this begs the question as to why they chose to implement it in such a crazy way!

 

0 Kudos
JohnNichols
Valued Contributor III
621 Views

Given the original Jacobian_deg.must have been written by a program  the programmer must have understood the logic of the sequences required to compute the coefficients. It this begs the question as to why they chose to implement it in such a crazy way!

I think this is from the stuff done by MacNeil in the early 1990's at USC -- this is not a well known structural analysis school - say compared to Powell's group at UCB. 

I suspect the code was written for a UNIX Fortran that does not baulk at 500 continuation lines, but looking yesterday at other Fortran implementations they provide a limit of 100 lines. I have no idea if Intel Fortran has a limit - could not find it -- someone in this group will know  - but the program disappeared into never land fairly convincingly 

Surely there is a library that will determine a Jacobian?  I have not done a Jacobian since Uni -- luck I guess.

This also appears to be part of a long running research program, I could find a lot of papers but no code? 

MacNeil appeared to be developing new FEM elements  - this may have been written by a grad student who knew no better and just copied and pasted a lot -- I have seen that before 

Where did you find the code and let us look at the original papers please -- it would be simpler to redevelop from modern libraries?

0 Kudos
carneiro__fernando
622 Views

mecej4 if I understood well you proposed 2 solutions: "What if each expression were walled off from the others?" and "rewriting the expression using a function det3()", right?

I think you implemented the second one, please correct me if I'm wrong.

*So*, can I just replace function jacobian_deg by jdet10 you've posted and run the program? Did the whole program compile with that modification?

 

Another thing I'd like to add that might be an alternative to help to end this for good:

I could get a modified version of the program (which is supposedly even less efficient in terms of running the program, but it might be compileable). Could you tell me if you are able to compile this one? (attached)

0 Kudos
mecej4
Honored Contributor III
621 Views

carneiro, fernando wrote:

mecej4 if I understood well you proposed 2 solutions: "What if each expression were walled off from the others?" and "rewriting the expression using a function det3()", right?

Neither is a complete solution. Those are ideas that can be used to construct a solution.

carneiro wrote:
 I think you implemented the second one, please correct me if I'm wrong.

I implemented both, separately. I provided a source file to illustrate the second idea. I implemented the first, but I did not provide the file.

carneiro wrote:
*So*, can I just replace function jacobian_deg by jdet10 you've posted and run the program? Did the whole program compile with that modification?

No, because the code is incomplete: it only calculates Coef(1) ... Coef(10). You will have to add matching code for Coef(11) to Coef(115).

carneiro wrote:
Another thing I'd like to add that might be an alternative to help to end this for good:

I could get a modified version of the program (which is supposedly even less efficient in terms of running the program, but it might be compileable). Could you tell me if you are able to compile this one? (attached)

Compiling this version of the code is trivial, but I don't see the relation between this and the code that you posted earlier. I do observe that this code also exhibits bad programming techniques, such as writing

(q*x1)/4-(q*x10)/2-(q*x12)/2-(q*x14)/2-(q*x16)/2+(q*x2)/4+(q*x3)/4+(q*x4)/4+(q*x5)/4+(q*x6)/4+(q*x7)/4+(q*x8)/4

instead of grouping similar terms and writing

q*((x1+x2+x3+x4+x5+x6+x7+x8)/4-(x10+x12+x14+x16)/2)

or

(sum(coord(1,1:8))/4-sum(coord(1,10:16:2))/2)*q

As suggested earlier, instead of showing us bad code, please provide references to the mathematical expressions that the code is attempting to represent.

0 Kudos
LRaim
New Contributor I
621 Views

It is possible that these long statements have been created by another program. 

0 Kudos
andrew_4619
Honored Contributor II
621 Views

Luigi R. wrote:

It is possible that these long statements have been created by another program. 

Certain not possible. No one coded so many 1000s  of complex  lines like  that!

0 Kudos
mecej4
Honored Contributor III
621 Views

After mulling over the issues discussed in this thread, I have a solution to offer.

I moved all the (computer generated) coefficients and indices into three data files, and wrote a subroutine (about 20 lines) that calculates the 115 coefficients for a given set of nodal coordinates coord(3,20). This subroutine is to be called once for each 3-D element in the FEA mesh. 

I have provided a short program to call this subroutine with 20 random point coordinate triplets and print the coefficients coef(1:115). Before calling the subroutine, the program calls (just once is enough) another setup subroutine to read the coefficients from the data files and set up values in the constant coefficient arrays.

The data files are:

  • File idx.txt contains a sorted list of ordered triplets of element node numbers (1 to 20) with which the 3 X 3 determinants need to be evaluated. There are 1140 such distinct ordered triplets, rather than 20 X 20 X 20 = 8000 (unordered, and with repetitions).
  • File djac.txt contains the exponent arrays dqjac, drjac and dtjac, and is 115 lines long.
  • File det3s.txt contains 73968 sorted lines with the following structure

  1   2   3  10 -3 128

which signifies that Coef(10) receives a contribution that is (-3/128) times the determinant of the coordinates of nodes 1, 2 and 3. Note that each triplet of node numbers can contribute to more than one element of the Coef array, and each such contribution comes with its own multiplier of the determinant.

I have verified that the reorganized subroutine yields the same results as Fernando's enormous subroutine with some random point coordinates.

If you wish to test the new code with more than one compiler, please note that they would probably provide different random numbers for the coordinates, so you may wish to provide your own fixed coordinates for the twenty points.

0 Kudos
Reply