Urgent Help Requested in Running Intel FORTRAN on Windows

[chatdumkc_edu]

Hello Steve Lionel,

This is a SOS.  I have old FORTRAN files (F77 version) in a folder on my desktop.  What I need to do is to compile and run these files.  I am using Windows and have Intel Visual FORTRAN with IMSL libraries.  The steps I used are as below:

1.  Open the Fname.for file using Microsoft Visual Studio 2008.

2.  Now from the "File" menu (top left hand corner of the pane), I am choosing the "Add to Existing Project" or "Add to New Project".

3.  Then I am going to the "Build" menu (top of the pane) and using the option "Build Solution"

On the solution pane I am getting the message: 0 errors 0 warnings (means that compilation is done).

4. Now when I am trying to run the program by choosing "Start without Debugging" -the problem crops up and the message says: "Unable to Start Program 'C\Users\chatd\Desktop....\Special Function\Debug\Special Function.exe'  "

The System cannot find the file specified.  

I do not know how to resolve this problem as I cannot locate the *.exe file either.  Need URGENT help on this.  Any pointers?  

- thanks,

Deb Chatterjee 

[chatdumkc_edu]

Mecej4:

Let me summarize what I understood from your last post:

1. I am using a straightforward *.FOR compiler (IFORT 11) and you are stating that I can use USE XXX_YYY instead of EXTERNAL XXX_YYY.  If that is true what you are saying is that I can just use the *.F90 usage of the IMSL in version 11.1 that I have. The IMSL manual (online) showed differently - that is USE XXX_YYY, I thought was restricted to source files ending in *.F90 extensions.  Well I must have been wrong. I always use double precision arithmetic because of stringent numerical accuracy especially in case of electromagnetic scattering problems. So, that part I am hoping will also be taken care of through this generic declaration. 

2. I shall do what you have stated. But before that let me do the changes and try recompiling and running.  Question is: do I again build after I have added the source file (*.for) in the VPROJ?

3. Why suddenly the source files (*.for) are not getting automatically added in the VPROJ?

Thanks a lot for your help, mecej4.

- Deb Chatterjee 

[FortranFan]

mecej4 wrote:

... In short, you are not using a Fortran 77 compiler. The IFort 11 compiler treats a .for file as a Fortran9X source file in fixed format. ...

OP seems to imply wanting to stick to FORTRAN 77.

Deb C.,

Is that really what you want?  If so, yes you can remain with FORTRAN 77 and depending on your setting in Visual Studio, you can use .for or .f extension, etc.  However, your comments in general suggest it would really help if you start from the beginning again and first read up on Visual Studio, then how Intel Fortran integrates with it, and after that how to set up basic projects with Intel Fortran in Visual Studio - lots of documentation online and with your installation of Intel Fortran. 

[TimP]

Where you are interfacing with IMSL, I agree with mecej4 in recommending the IMSL USE interface, regardless of whether you choose .for (same effect as .f) fixed form source or free form.  As mentioned above, choice of fixed format doesn't switch the compiler out of accepting Fortran 90/95/2003 as well as f77 syntax.

I didn't understand your reservations about double precision.  With ifort, double precision is the same as real(selected_real_kind(12)) , which evaluates to real(kind=8) for ifort. I would hope that the IMSL USE interfaces for double precision would accept either spelling.

There are some issues in generic interfaces as to whether the various methods of arriving at double precision are considered to match, but I haven't seen you indicating you face such issues.

I personally have never seen any of the Fortran 90 versions of IMSL, as I've long given up using that.

[mecej4]

Tim Prince wrote:
I personally have never seen any of the Fortran 90 versions of IMSL, as I've long given up using that.

Many of the functions and subroutines in IMSL versions FNL-6 and FNL-7 are no longer available with a pure F77 interface. To the point, the Airy function with generic name CAI that the OP uses in his code maps to specific routines C_CAI and Z_CAI. However, even these specific routines take optional second arguments and, therefore, are tricky if not impossible to call from strict F77 code. The argument lists of the specific routines are not even mentioned in the documentation (see http://www.roguewave.com/portals/0/products/imsl-numerical-libraries/fortran-library/docs/7.0/sfun/sfun.htm, Chap.8, "CAI"). One may look at their interfaces in the provided source file numerical_libraries_f90.f90, but even then the problems with calling them from F77 code remain.

[Deb_C_]

Tim Prince wrote:

Where you are interfacing with IMSL, I agree with mecej4 in recommending the IMSL USE interface, regardless of whether you choose .for (same effect as .f) fixed form source or free form.  As mentioned above, choice of fixed format doesn't switch the compiler out of accepting Fortran 90/95/2003 as well as f77 syntax.

Well, that's very good news for oldies like me.

Tim Prince wrote:

I didn't understand your reservations about double precision.  With ifort, double precision is the same as real(selected_real_kind(12)) , which evaluates to real(kind=8) for ifort. I would hope that the IMSL USE interfaces for double precision would accept either spelling.

Did not quite catch this.  But you maybe correct. I'll try out (following mecej4's prescription), and then if the code runs with no hassles I'll let the forum know.

Tim Prince wrote:

There are some issues in generic interfaces as to whether the various methods of arriving at double precision are considered to match, but I haven't seen you indicating you face such issues.

I personally have never seen any of the Fortran 90 versions of IMSL, as I've long given up using that.

IMSL is the main attraction for me to use FORTRAN.  Particularly I have to use a lot of complicated numerical math in my work; if I had to develop the routines myself to the degree of accuracy that IMSL has - particularly (the special functions with complex arguments). The numerical quadrature routines can even handle pole and branch point singularities in the path of integration.  I would be very skeptical if any other software such as MATLAB would do all that to the degree of complication that IMSL (or perhaps NAG) does.

Recommend that you fall in love with IMSL all over again. It can be your princess. :-)

[Deb_C_]

mecej4 wrote:

However, even these specific routines take optional second arguments and, therefore, are tricky if not impossible to call from strict F77 code. The argument lists of the specific routines are not even mentioned in the documentation (see http://www.roguewave.com/portals/0/products/imsl-numerical-libraries/for..., Chap.8, "CAI"). One may look at their interfaces in the provided source file numerical_libraries_f90.f90, but even then the problems with calling them from F77 code remain. 

I have access to that online documentation for IMSL.  The point is that I am creating a *.FOR source code and not *.F77 as you have pointed out. So, I am hoping that if I make the changes to the IMSL routines - the way you have indicated in an earlier post, it will compile & execute fine.  

My problem seems to be, following your prescription, that VS is seeing the VPROJ empty. It probably has nothing to do with *.FOR or *.F77 environment.  

So, if I make the (minor) changes as you have suggested to the source code - use IMSL differently than I am using now - and then fill the VPROJ the way you have indicated, I should not see any problems.

I shall let the bloggers know by COB tomorrow.

- thanks as always,

Deb C. (aka Deb Chatterjee) 

[mecej4]

Deb. C wrote:
So, if I make the (minor) changes as you have suggested to the source code - use IMSL differently than I am using now - and then fill the VPROJ the way you have indicated, I should not see any problems.

I don't think that you should count on that. There are numerous algorithmic errors (variables used without initialization, misnamed common blocks and subroutine arguments, etc.) in the program, which you will encounter only after you succeed in compiling and linking. 

[Steven_L_Intel1]

While I agree with those who suggest that you move on to more modern Fortran syntax, don't feel that you are required to do so. Intel Fortran supports Fortran 77 and IMSL supports using it with Fortran 77.

The basic issue here is that you didn't add your source file to the project. Doing so is automatic if you add a new source file, using the project menus, while in the project, but simply creating a project doesn't add existing sources.

[chatdumkc_edu]

Steve & Mecej4:

Thanks a lot for your help and advice. I could finally clean the code and have it compiled and linked with the IMSL on my Intel Visual FORTRAN (version 11.1).  I have attached the source code and  the buildlog.htm file here.

There is something quite interesting and although mecej4 had mentioned it earlier, I am not sure why it works and if I can do the same in all my other source codes. The issue is with IMSL routines.

The code I finally got to run (error-free), is somewhat different than mecej4 had suggested me to do. I have excluded (just to see if it would work or not), the commands:

   IMPLICIT NONE

   USE CAI_INT

Instead I had called (adventurously) the IMSL routine Z_CAI to see if it would mingle error-free with F77. (The Z_CAI is actually suitable for F90 interface.) I expected errors and I thought that I shall go back to the commands that mecej4 had suggested.  Instead as you can see in the buildlog.htm file, that it worked and indicating that IMSL routines specifically indicated as appropriate for F90 interface, will also work for F77 interface.

I wonder why?  (The attached Airy.zip file has both files for your perusal.) 

Anyways thanks Steve and mecej4. You guys are god & angels to the entire FORTRAN community.

- Deb Chatterjee (aka Deb C.) 

[Steven_L_Intel1]

Deb,

If you don't have USE CAI_INT, do NOT call Z_CAI, which as you say is the "Fortran 90" interface. While the program may build, it will not execute correctly. In this case, CAI has an optional argument SCALING which, if you don't have the USE, will not be communicated properly to CAI and it will read uninitialized memory. In cases of more complex IMSL routines, arrays will be passed incorrectly and you'll get run-time errors or wrong results. Don't use EXTERNAL if you're using an explicit interface or module.

I also strongly recommend against using the type-specific names such as Z_CAI, CDSQRT, etc. Use the generic names (CAI, SQRT) instead. It will help you avoid other problems.