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,077 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
2,459 Views

In solution explorer right click on the project and use the "add existing file" and "fixed format source files". .for is used for the old fixed format files and .f90 is used for the free format.

0 Kudos
carneiro__fernando
2,459 Views

"In solution explorer right click on the project and use the "add existing file" and "fixed format source files"".

There is nowhere I can choose fixed format files. But even if there was I am not sure if it would help.

When I right click solution explorer and use "add existing file" a window is opened and I can see the files there to choose. The options of files it shows for selection are "Common Intel(R) Visual Fortran Files (*.f90, *.for, *f, *fi, *fd)", and I can add the files I have.

The problem is that the compiler seems not to recognize the .for files sintax (which I believe might differ from .f90 one) and gives errors, so it's impossible to compile.

Other way I tried was: New > Fortran project from existing code

When I click compile, in the output box (show output from build) it reads all the files, giving errors and them seems to read a copy of them with new names "filename__genmod.f90" then stops and gives error.

I will attach the buildlog file it may help...

0 Kudos
mecej4
Honored Contributor III
2,459 Views

In standard fixed form Fortran source code, statements are supposed to end before or on column 72. You have several lines in, for example, integral.for, that exceed this limit. You can ask the compiler to accept longer lines (up to 132 columns) if you use the /extend-source option.

The files ending _genmod.f90 are generated because you specified /warn:interfaces.

It will be much easier to help if you attach the source file, or at least the relevant sections of it.

0 Kudos
mecej4
Honored Contributor III
2,459 Views

The lines of source shown in the error messages do not match those in the source files that you attached. Compile time errors are not "linkage errors".

You seem to be building a large program with scores of source files. Either provide all the sources needed, or work out the bugs by reading the error messages and taking corrective action.

0 Kudos
carneiro__fernando
2,459 Views

I am still getting error messages, this time It says it is due to lack of memory, which I believe can't be the actual reason...

After this message the program seems to continue to build and still find multiple errors... I tend to believe it is due to library linkage, but I'm just guessing (and I am probably wrong on that)

I am attaching the buildlog and 2 source files where the first errors happen...

0 Kudos
carneiro__fernando
2,459 Views

It is a large program with many source files.

I will provide all the sources needed. There are indeed many file. Would it be OK?

I just don't believe there is a code error, sintax error and those types. I am pretty sure it has to do with any kind of configurations or something, as some of the cold were programed using a very old version of MVB.

0 Kudos
gib
New Contributor II
2,459 Views

7zip is unable to open either of those files.  How did you create them?

0 Kudos
carneiro__fernando
2,459 Views

Used winrar

0 Kudos
mecej4
Honored Contributor III
2,459 Views

One source file, Jacobian_deg.for, is 9 megabytes long, contains almost 90 thousand lines of code, and some statements span over 1000 continued lines. Even with all optimizations disabled (/Od) and no checking or debugging options, on my PC (Windows 10, i5-8400, files on ramdisk), the compiler has not been able to compile this file after 30 minutes.

This source file is an abomination (probably computer-generated) and is probably a means of torturing any compiler. It should be fixed.

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

Gib: 7Zip had no problem extracting the source files from the RAR archive.

0 Kudos
JohnNichols
Valued Contributor III
2,458 Views

Your Jacobian .for has many calculations done 85 times using the same variables -- you  are not torturing a compiler - you are torturing yourself because there is no way to check this stuff. 

 

0 Kudos
carneiro__fernando
2,459 Views

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)

0 Kudos
mecej4
Honored Contributor III
2,459 Views

carneiro, fernando wrote:

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)

Yes, I am sure. The compiler flags that line and shows the offending character, 'o'. Please look at line 67. Depending on which text editor you use and the window width, you may need to scroll horizontally to the end of that line to see the 'o' in column 129. It is possible that you may be using the /extend_source option for only some files rather than for all if you do not see the error message.

Did a human being write the source code in Jacobian_deg.for? As John Nichols pointed out, how are you ever going to debug that code without spending a few years on it? Has anybody ever checked (there are standard methods for doing so) that the elements of the Jacobian contain the correct expressions for the derivatives?

0 Kudos
JohnNichols
Valued Contributor III
2,458 Views

As John Nichols pointed out, how are you ever going to debug that code without spending a few years on it? 

-------------------------------------------------------------------------------------------------------------------------------------------------------------

The average human makes 1 mistake in 10 math calculations, there is no way a human wrote that and it is error free.  

If a machine made the code - then someone under there is human code and as sure as eggs are eggs it will have errors, even normal statistical methods will not allow you to debug the code. 

-------------------------------------------------------------------------------------------------------------------------------------------------------------

There have to be standard libraries to do what you want to do - surely 

The code looks like something for a computer like the K Computer, not a small Intel machine 

 

0 Kudos
JohnNichols
Valued Contributor III
2,458 Views

x1=coord(1,1);x2=coord(1,2);x3=coord(1,3);x4=coord(1,4);
      x5=coord(1,5);x6=coord(1,6);x7=coord(1,7);x8=coord(1,8);
      x9=coord(1,9);x10=coord(1,10);x11=coord(1,11);x12=coord(1,12);
      x13=coord(1,13);x14=coord(1,14);x15=coord(1,15);x16=coord(1,16);
      x17=coord(1,17);x18=coord(1,18);x19=coord(1,19);x20=coord(1,20);

      y1=coord(2,1);y2=coord(2,2);y3=coord(2,3);y4=coord(2,4);
      y5=coord(2,5);y6=coord(2,6);y7=coord(2,7);y8=coord(2,8);
      y9=coord(2,9);y10=coord(2,10);y11=coord(2,11);y12=coord(2,12);
      y13=coord(2,13);y14=coord(2,14);y15=coord(2,15);y16=coord(2,16);
      y17=coord(2,17);y18=coord(2,18);y19=coord(2,19);y20=coord(2,20);

      z1=coord(3,1);z2=coord(3,2);z3=coord(3,3);z4=coord(3,4);
      z5=coord(3,5);z6=coord(3,6);z7=coord(3,7);z8=coord(3,8);
      z9=coord(3,9);z10=coord(3,10);z11=coord(3,11);z12=coord(3,12);
      z13=coord(3,13);z14=coord(3,14);z15=coord(3,15);z16=coord(3,16);
      z17=coord(3,17);z18=coord(3,18);z19=coord(3,19);z20=coord(3,20);

 

Your code can be viewed as a simple set of recursion relations - it should occupy no more than about 500 lines of LISP code or 1500 lines of Fortran code at the most. 

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

And it should compile in a few seconds. 

0 Kudos
mecej4
Honored Contributor III
2,459 Views

Fernando: As an example of how to proceed, consider the first error in the build-log of #5. The compiler detected a mismatch in the argument list in the call to Output_Tecplot_uv. The subroutine contains 14 dummy arguments. The call to it in Output_backup.for(126) contains 12. The arguments nodez_local and scale are missing from the call. If the missing actual arguments are required, you must include them in the call, after providing correct values if these arguments are INTENT(IN) or INTENT(IN OUT).

Treat the remaining error messages on mismatched argument lists similarly.

These mismatches are found because you provided the /warn:interfaces option. Otherwise, they would have gone undetected, caused crashes or yielded incorrect results.

0 Kudos
gib
New Contributor II
2,459 Views

mecej4:  I see that 7Zip on my PC does it, but not 7Zip on my laptop.  I must replace it.

0 Kudos
gib
New Contributor II
2,459 Views

When I try to compile jacobian_deg.for with my old ifort, I get errors that I don't understand, e.g.

Jacobian_deg.for(167): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: ) ,
     1         - (x7*y8*z4)/64 - (x8*y4*z7)/64 + (x8*y7*z4)/64
              ---------------------------------------------------------------^

This happens with the first 6 statements (defining coef(1),..,coef(6)) then the compiler gives up:

fortcom: Fatal: There has been an internal compiler error (C0000005).
compilation aborted for Jacobian_deg.for (code 1)

As far as I can see there is no missing ')' at the end of line 167.  The statement does occupy 130 lines - maybe that's too long, although the error message implies that it wants more.

0 Kudos
JohnNichols
Valued Contributor III
2,458 Views

The lines are longer than 72 and there is a ) missing at the end of the statement

Are these from Macneal's publications on beam bending - from the early 1990's look like NASA stuff????

0 Kudos
JohnNichols
Valued Contributor III
2,458 Views

Sorry - the ) was my mistake 

set lines to 132 characters and then have a very large empty hard drive - after 25 minutes the jacob one crashed out of space -- 

Better still - rewrite it 

0 Kudos
mecej4
Honored Contributor III
2,181 Views

gib wrote:

When I try to compile jacobian_deg.for with my old ifort, I get errors that I don't understand, e.g.

Jacobian_deg.for(167): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: ) ,
     1         - (x7*y8*z4)/64 - (x8*y4*z7)/64 + (x8*y7*z4)/64
              ---------------------------------------------------------------^

This happens with the first 6 statements (defining coef(1),..,coef(6)) then the compiler gives up:

fortcom: Fatal: There has been an internal compiler error (C0000005).
compilation aborted for Jacobian_deg.for (code 1)

As far as I can see there is no missing ')' at the end of line 167.  The statement does occupy 130 lines - maybe that's too long, although the error message implies that it wants more.

Gib, unless you use the /extend-source option, when given a fixed-form source file the compiler will ignore anything beyond column-72, and that is the reason for its apparently finding mismatched parentheses.

Only one continuation mark is used in the source code: '1'. This is so even for a statement with over 500 continuation lines, so it becomes necessary to refer to lines by line numbers.

0 Kudos
Reply