Compatibility with Windows 7 64-bit

[Mike_G_1]

I have been running Intel Fortran Compiler, version 10.0.027 in Windows 7

32-bit with no issues. Recently I switched to windows 7 64-bit. During instalation of fortran compiler

I had a "known compatibility issue" message. During compiling (from command prompt)

there were path issues from ifortvars.bat, "could not find link", etc. I assume 

there is a fix for this on-line but could not yet find it. Could you direct me to 

an appropriate fix?

Thank you

[TimP]

A more recent update of the compiler sèems the most likely solution.

[Mike_G_1]

Thank you for the response. It has been a few years since I purchased

the compiler. Would I have to purchase a new version or is there an update

for the compiler I have. If so, where?

Thank you.

[Kevin_D_Intel]

The “could not find link” message is typical of not having met the minimum Visual Studio requirement for our product so perhaps you did not have Visual Studio installed first under the new Windows 64-bit OS before installing the Intel Compiler version 10.0.

The Intel Compiler 10.0 version did not officially support Windows 7; however, I believe there are customers who are successfully using it under that OS. If you know the Visual Studio version you were using before and can install that, and then uninstall/reinstall the Intel Fortran 10.0 release so that it can integrate with that Visual Studio, then the Intel Fortran 10.0 compiler may work for you.

Intel Fortran Version 10.0.027 was the final update release back in 2007 for the 10.0 release. If you are not dependent on the older 10.0 release the we recommend upgrading your product.  If you are interested in upgrading to the latest Parallel Studio XE 2016 (16.0 compiler) then you would need to purchase a new subscription. I looked up your information and note your current subscription expired in 2008 so you cannot upgrade without a new subscription.

You can find the complete details about the current Parallel Studio XE 2016 release here, https://software.intel.com/en-us/intel-parallel-studio-xe. Pricing and information on available resellers can be found under Try & Buy button (right-side navigation).

A very important note, as with your earlier 10.0 version, the current PSXE 2016 version also has a requirement/dependence for Visual Studio.  If you do not have a supported Visual Studio installed (VS2010, 2012, 2013, 2015), a Fortran-only development environment based on VS2013 will be installed. However, this requires that the Microsoft Windows SDK for Windows 8.1 be installed, and Microsoft requires us to have you get that from them directly. Please see Install Windows SDK for VS2013 Shell for more details.

If you qualify, you may also be able to use the Free Microsoft Visual 2015 Community Edition, https://www.visualstudio.com/products/vs-2015-product-editions.

Hope that helps.

[Mike_G_1]

Thank you for your response.

The aim was to run my old compiler in command prompt in the newly

installed Windows 7 64-bit OS.

I managed to make this work as follows:

1) downloaded and installed .NET Framework 4 for Windows 7 64-bit.

2) downloaded and installed Microsoft Windows SDK for Windows 7 (64-bit version)

3) installed my originally purchased Visual Fortran Compiler - Version 9 

   (although I do not think this was required).

4) installed my most recent Visual Fortran Compiler - 10.0.027

5) changed one line in 'ifortvars.bat'

from 

call "C:\Program Files\Microsoft Platform SDK\SetEnv" /X64 /RETAIL

to

call "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv" /X64

Note that there are still compatibility issues within Visual Studio.

The irony in all this is that I switched to Windows 7 64 bit version

from the 32 bit OS so that I can access more memory. I have recently

installed 8GB of RAM. This has not worked.

As I now understand it (I hope), I have still ran into the 2GB RAM limit due

to the Windows environment. I understand the issue of dynamic allocation 

for large arrays [Ref. Memory Limits for Applications on Windows, Steve

Lionel]. The difficulty I have is that in my applications there is a large

interdependance of information and I am not clear that ALLOCATing and

DEALLOCATing arrays will work.

Is there anything else I can do within Windows etc. to have "real" access 

to about 6.5 GB of RAM or more, or am I now forced to abandon the Windows 

environment and go to a UNIX based system where memory is more accessible?

Additional comments/suggestions are appreciated.

Mike

[mecej4]

The difficulty I have is that in my applications there is a large interdependence of information and I am not clear that ALLOCATing and DEALLOCATing arrays will work

Why will it not work? You dynamically allocate your big arrays at the start of your program, and they will all coexist until the end of the program. No individual array may exceed 2 GB, but the total can be above that limit. Here is an example, related to solving N linear equations when the N X N matrix contains M non-zero elements. The CSR (compressed sparse row) representation of a sparse matrix is used, and we need integer arrays IA(N), JA(M) and double precision arrays X(N), B(N), A(M). Try the following example code twice, using the 32-bit compiler first and then the 64-bit compiler. For the values shown for M and N, the arrays together consume 3.4 billion bytes (somewhat less than 3.4 GB), well above the 2 GB limit of a single object.

program memory_hog
integer, parameter :: N = 50000000, &
                      M = 200000000
integer, allocatable :: ia(:),ja(:)
double precision, allocatable :: A(:),x(:),b(:)
integer isize,dsize

allocate(ia(N), ja(M), A(M), x(N), b(N))
isize=size(ia)+size(ja)
dsize=size(A)+size(x)+size(b)
write(*,*)'Used 4 X ',isize,' bytes for integer arrays,'
write(*,*)'and  8 X ',dsize,' bytes for real arrays'
write(*,*)'Total memory used ',4_8*isize+8_8*dsize,' bytes'
end program

[Mike_G_1]

Thank You !

Mike

[Mike_G_1]

This will be another topic change from the original query...

I am trying to transfer information in arrays from main program to subroutines,

subroutines to subroutines, functions to subroutines etc. The simple program

below does not return the dynamic array information back to main program.

What am I missing?

Thanks again for your help,

Mike

      PROGRAM MEMORY

      IMPLICIT DOUBLE PRECISION (A-H,O-Z)

      PARAMETER (M=248302796) ! 1.85 GB for static array

      COMMON /A/A(M)

      ALLOCATABLE :: B(:),C(:)

      ALLOCATE (B(M),C(M))

      CALL ENTRIES

      WRITE(*,*) A(1),B(1),C(1)

      END

      SUBROUTINE ENTRIES

      IMPLICIT DOUBLE PRECISION (A-H,O-Z)

      PARAMETER (M=248302796) ! 1.85 GB for static array

      COMMON /A/A(M)

      ALLOCATABLE :: B(:),C(:)

      ALLOCATE (B(M),C(M))

      DO 1 I=1,1 ! M

      A(I)=4.0D0*DATAN(1.0D0)

      B(I)=4.0D0*DATAN(1.0D0)

      C(I)=4.0D0*DATAN(1.0D0)

1    CONTINUE

      WRITE(*,*) A(1),B(1),C(1)

      RETURN

      END

[mecej4]

Please read a Fortran text book/manual and go through some of the tutorials that are available. Fortran is, by tradition, a procedural programming language. Some OOP features have been added during the last decade, but in general nothing happens unless you code for it.

Your subroutine has no dummy arguments, so its only means of sharing variables with the main program is the common block. The common block that you showed does not contain B or C in it, so any changes you make to B and C are local to the subroutine. The variables B and C in the main program have no connection with the variables of the same names in the subroutine, because there is no name association between variables in independently compilable program units.

Should you decide to use allocatable variables as subprogram arguments, there are a number of rules and restrictions that you should know and comply with. One of the rules is that an allocatable variable may not be a member of a common block.

[Mike_G_1]

I have been looking/searching for this for a while. I am confused on how to use

dummy arguments for the allocatable arrays to communicate outside the subroutine.

Please be patient with me. I have been using Fortran 77 all my life.  The material on-line

just confused me more. Is there a simple fix to the program/subroutine example I gave?

Thanks again,

MIke

[mecej4]

I did not succeed in an attempt to divine your intentions from the code in #8, and without knowing those intentions I have no idea what to tell you. So, please write a verbal description of what you wish to do. 

There is one scenario in which the code can be kept simple. In this, you declare and allocate the dynamic arrays in the main program or in Subroutine A, and pass them to other subprograms Subroutine B, etc., as if they were statically allocated arrays. This will suffice and work as long as those other subprograms consume or modify the values of the dynamic arrays, but do not allocate, deallocate or enquire the allocation status of the arrays.

If the restrictions in the preceding paragraph are not acceptable, then you have to declare the relevant subprogram arguments as allocatable, and the calling subprogram(s) must be provided with explicit interfaces to the called subprograms. In this case, you will need to go through several exercises to learn about the rules and how to debug programs with this feature. You will also need to decide whether to use modules to contain these subprograms with allocatable arguments, or to provide explicit interfaces in another way.

[Mike_G_1]

The sample program and subroutine in #8 uses the static array A in a common block.

The remaining two arrays B and C are ALLOCATABLE arrays after reaching the 2 GB

static limit. The first entry in these arrays is written first in the subroutine and then

in the main program... WRITE(*,*) A(1),B(1),C(1)

The results are as follows

3.14, 3.14, 3.14

3.14, 0.00, 0.00

The second line should be the same as the first if the arrays are properly transferred to the main program.

I know I am missing something here (providing explicit interfaces, dummy arguments ??).

My questions is as in #10 above.

Thank you for your patience,

Mike

[mecej4]

The variables B and C in the main program have nothing to do with the variables B and C in the subroutine. You are misleading yourself if you think that by merely giving the pair of variables the same names in the two places you are unifying them. In fact, the variables B(1) and C(1) in the main program are uninitialized, so the program is not a valid program at all.

To see this better, consider the following simplified version in which the variable A and the common block have been removed.

      PROGRAM MEMORY
      IMPLICIT DOUBLE PRECISION (A-H,O-Z)
      PARAMETER (M=4)
      ALLOCATABLE :: B(:),C(:)
      ALLOCATE (B(M),C(M))
      CALL ENTRIES
      WRITE(*,*) B(1),C(1)
      END
      
      SUBROUTINE ENTRIES
      IMPLICIT DOUBLE PRECISION (A-H,O-Z)
      PARAMETER (M=4)
      ALLOCATABLE :: B(:),C(:)
      ALLOCATE (B(M),C(M))
      DO I=1, M
         B(I)=I*2
         C(I)=I*3
      END DO
      WRITE(*,*) B(1),C(1)
      RETURN
      END

The variables B and C in the main program are "undefined" (contents are unknown, may contain random debris from previous task that wrote to those memory locations) on line-7. Some compilers can generate code to catch such errors. Such a compiler will tell you, for instance:

Runtime Error: mike.f90, line 7: Reference to undefined variable B(1)

Try changing the names of B and C in the main program to something else. 

The second line should be the same as the first if the arrays are properly transferred to the main program.

That is  a fundamental misunderstanding. B and C are local variables. The local variables in each independent subprogram constitute an independent namespace. In fact, once you compile the program, unless you are producing debug symbols, the names B, C, ... do not even exist in the OBJ or EXE files, having been replaced by offsets in the local stack frame. As soon as the RETURN statement in the subroutine is executed, the variables B and C of the subroutine go "out of scope", i.e., they no longer exist. Variables can be "transferred" (your terminology; "shared" is more apt) between subprograms by (i) module association, (ii) host association, (iii) argument association and (iv) common block association. None of these associations exist for B and C.

Here is an even simpler program to drive this point home. Run it with various options such as /check:all, /warn:all and /standard-semantics. Ifort is sometimes able to catch such errors, if asked, but in general it is a professional class compiler with a focus on producing fast code and capable of doing "what the programmer intended" on a variety of Fortran codes of uncertain pedigree and long history.

program mike1
implicit none
integer i
!
call entry()
!
write(*,*) 'In main program:'
write(*,*) 'Variable i: offset = ',loc(i)
write(*,*) '            value  = ',i
end program

subroutine entry()
implicit none
integer i
!
i=15
!
write(*,*) 'In subroutine:'
write(*,*) 'Variable i: offset = ',loc(i)
write(*,*) '            value  = ',i
!
return
end subroutine

Try Silverfrost/Salford Fortran 95 (it is free for personal use). It is fast, very good at trapping errors and just the right tool for learning Fortran 95.

[FortranFan]

Mike G. wrote:

I have been looking/searching for this for a while. I am confused on how to use dummy arguments for the allocatable arrays to communicate outside the subroutine.Please be patient with me. I have been using Fortran 77 all my life.  The material on-line just confused me more. Is there a simple fix to the program/subroutine example I gave? Thanks again, MIke

Mike G.,

Would you be open to the idea of "begin at the beginning" and retool yourself on Fortran?  Looking at your code and questions, I suggest putting aside everything you have done with FORTRAN 77 and restart with a book or two i.e.,, if you want to follow a structured approach.  Or, quick, ad hoc approach, you can try "free" resources online such as Wiki Fortran, etc.  Here're some suggestions:

FORTRAN 90 for Engineers and Scientists 1st Edition 
by Larry Nyhoff (Author), Sanford Leestma (Author) 
http://www.amazon.com/FORTRAN-Engineers-Scientists-Larry-Nyhoff/dp/0135197295/ref=sr_1_3?s=books&ie=UTF8&qid=1438539336&sr=1-3&keywords=fortran+90+for+scientists+and+engineers 

and/or
Fortran 95/2003 for Scientists & Engineers 3rd Edition 
by Stephen Chapman (Author) 
http://www.amazon.com/Fortran-95-2003-Scientists-Engineers/dp/0073191574/ref=sr_1_4?s=books&ie=UTF8&qid=1438539336&sr=1-4&keywords=fortran+90+for+scientists+and+engineers 

Or resources such as

http://www.egr.unlv.edu/~ed/fortran (find a downloadable PDF file here) 

and 

http://fortranwiki.org/fortran/show/Tutorials 

If you're interested in advancing yourself further in Fortran, you can also try recommendations by Dr Fortran as suggested here: https://software.intel.com/en-us/blogs/2013/12/30/doctor-fortran-in-its-a-modern-fortran-world

[FortranFan]

Mike G. wrote:

.. I know I am missing something here (providing explicit interfaces, dummy arguments ??).  .. 

It appears you might be trying to do something along the lines shown below.  You can look up the resources I suggested in my previous message to get a lot of details on various facilities now available in the Fortran language using which you can develop clear, concise, robust code that is also easier to write than with FORTRAN 77 e.g., no need to use all upper case, free-form code such as no need to start from column 7 and so forth, use explicit typing, use modules to get explicit interfaces, etc.  If you're keen, you should look into most of such facilities.

module m

   use, intrinsic :: iso_fortran_env, only : WP => real64  !.. set working precision for floating point values

   implicit none !.. implicit typing fraught with danger, use implicit none always

   private  !.. Content can set to PRIVATE by default for safety and benefits associated
            !   with "information hiding"


   real(kind=wp), parameter :: PI = 4.0_wp*atan(1.0_wp)  !.. You can define named constants to achieve clarity

   !.. You can make certain content publicly available
   public :: WP
   public :: PI
   public :: ENTRIES

contains

   subroutine ENTRIES(B, C)

      !.. Argument list
      real(kind=wp), intent(inout) :: B(:)  !.. read up on assumed shape arrays, very valuable
      real(kind=wp), intent(inout) :: C(:)

      B = PI  !.. use Fortran array handling as much as you can
      C = PI

      !..
      print *, " In ENTRIES: B(1), C(1) = ", B(1), C(1)

      return

   end subroutine ENTRIES

end module m

program Memory

   use m, only : WP, PI, ENTRIES  !.. Look up MODULE facility in Fortran; tremendous benefit

   implicit none   !.. implicit typing is fraught with danger; avoid it

   integer, parameter :: M = 2 !.. M set to 2 for illustration
                               !   You can retry with your larger value

   real(kind=WP), allocatable :: A(:), B(:), C(:)
   integer :: istat  !.. variable to error handle allocation
   character(len=80) :: erralloc  !.. variable to grab any allocation diagnostics

   allocate (A(M), B(M), C(M), stat=istat, errmsg=erralloc)
   if (istat /= 0) then
      print *, " allocation of B/C failed. istat = ", istat, ", errmsg = ", erralloc
      stop
   end if

   A = PI  !.. No need to invoke a procedure if variable just needs to be
           !   initialized to a constant like so
   call ENTRIES(B, C)  !.. But you can invoke a procedure if you want to

   write(*,*) " In program Memory: A(1), B(1), C(1) = ", A(1), B(1), C(1)

   stop

end program Memory

Upon execution,

  In ENTRIES: B(1), C(1) =    3.1415926535897931        3.1415926535897931
  In program Memory: A(1), B(1), C(1) =    3.1415926535897931        3.141592653
5897931        3.1415926535897931

Good luck,

[Mike_G_1]

Thank you !

Your your efforts are greatly appreciated.

Mike