my code is:

 program
 ...
 ! Loop which I want to parallelize
 !$OMP parallel DO
 I = 1, N
 ...
 call FORD(i,j)
  ...
 !$OMP END parallel DO
 end program

  subroutine FORD(i,j)
  logical servo,genflg,lapflg
  dimension c(nvarc)
  dimension zl(3),zg(3),v1(3,3),v2(3,3),rn(3),
 .          rcg1(3),rcg2(3),ru1(3),ru2(3),
 .          rott1(3),rott2(3),velr(3),dt(3),
 .          dfs(3),ftu(3),fnr(3),amomet(3
  common /contact/ iab11,iab22,xx2,yy2,zz2,
 .                 ra1,rb1,rc1,ra2,rb2,rc2,
 .                 v1,v2,
 .                 xg1,yg1,zg1,xg2,yg2,zg2
  common /ellip/ b1,c1,f1,g1,h1,d1,
 .               b2,c2,f2,g2,h2,p2,q2,r2,d2
  common /root/ root1,root2
  common /tab1/
 .       itype(ndim1),nconti(5),nvarc,
 .       nconta,nconta1
  common /bal1/
 .       ra(5),rb(5),rc(5),
 .       amomen(ndim),fwall(6),press(3),wmomet(6,2),
 .       rot(ndim),ttheta(ndim*3),rstp(ndim*3),forces(ndim),
 .       ssampl(3,3),edserv(3,3),tdisp(ndim),adisp(ndim),vel(ndim),
 .       del(3),xmax(3)

CALL CONDACT(genflg,lapflg)
return
end subroutine

SUBROUTINE CONDACT(genflg,lapflg)
implicit double precision (a-h,o-z)
logical rflag,dflag,error,gmvflg,grvflg,ctrlflg,depflg
  parameter (ndim1 = 20002)
  parameter (ndim = 3*ndim1)
  parameter (nkmm = 9000000)
  parameter (nkwall = 50000)
  character*4 hed
  logical genflg,lapflg,fast
  dimension v1(3,3),v2(3,3)
  common /contact/ iab11,iab22,xx2,yy2,zz2,
 .                 ra1,rb1,rc1,ra2,rb2,rc2,
 .                 v1,v2,
 .                 xg1,yg1,zg1,xg2,yg2,zg2
  common /ellip/ b1,c1,f1,g1,h1,d1,b2,c2,f2,g2,h2,p2,q2,r2,d2
  common /switch/ nk
  common /root/ root1,root2
  common /nroot/ rt(5),nrt
  common /bal2/xmax(3)

 call function f(x)
 C
 C......
 C

 RETURN
 END

  function f(x)
  implicit double precision (a-h,o-z)
  common /contact/ iab11,iab22,xx2,yy2,zz2,
 .                 ra1,rb1,rc1,ra2,rb2,rc2,
 .                 v1,v2,
 .                 xg1,yg1,zg1,xg2,yg2,zg2
  common /ellip/ b1,c1,f1,g1,h1,d1,
 .               b2,c2,f2,g2,h2,p2,q2,r2,d2
  common /switch/ nk
  common /nroot/ rt(5),nrt
  dimension a(3,3),b(3),v1(3,3),v2(3,3)
  ..
  ..
  ..
  ..
  end

my question is inside the parallel loop, does all variable (within common block or outside of common block) in each subroutine are private? 1. If not, should I use threadprivate for the common blocks and private the variables in each subroutine after declaration? 2. Each thread passes through 2 subroutine and one function. Subroutines has some same common block and variables. if I use threadprivate common blocks for each subroutine, how do the variable values pass through the entire program for a single thread. Any help will be appreciated. Thanks.

I used the numbers spat out by the compiler for my weekly lotto pick, but I didn't win anything.  Oh well.

MODULE m20150828
  IMPLICIT NONE

  TYPE :: ParentType
    CHARACTER(:), ALLOCATABLE :: string
  END TYPE ParentType

  TYPE, EXTENDS(ParentType) :: ExtensionType
  END TYPE ExtensionType

  TYPE :: OtherType
    CHARACTER(:), ALLOCATABLE :: other_string
  END TYPE OtherType
END MODULE m20150828

PROGRAM p
  USE m20150828
  IMPLICIT NONE
  TYPE(OtherType), ALLOCATABLE :: array(:)
  CLASS(ExtensionType), ALLOCATABLE :: object

  ALLOCATE(object)
  object%string = 'initiating compiler self-destruct sequence!'

  ALLOCATE(array(1))
  array(1) = OtherType(OTHER_STRING=object%string)
END PROGRAM p

>ifort /check:all /warn:all /standard-semantics "2015-08-28 structure-constructor-ice.f90"
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0 Build 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

010101_14247 supplementary 22

catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in
 which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error, and its not even a given that they will be given.
compilation aborted for 2015-08-28 structure-constructor-ice.f90 (code 1)

This is a question I've wondered for a long time:

Can the beginning index for a Do-loop ever be <1 (e.g., 0)?

In recent practice, I discovered that using 0 as a starting value causes a crash, e.g., :

!     Initialize several variables for later use:
      do j = 0,N
        TwLev(j) = Tw_out + j*DeltaTwLev
        WaLev(j) = Wa_in
        HaLev(j) = Ha_in
      enddo

forrt1: severe (408) : fort: (3): Subscript #1 of the array TwLev has value 0 which is less than the lower bound of 1

The error message seems to indicate that 1 is the lowest acceptable integer.  Any thoughts on this?

If A.LIB calls routines in B.LIB, can A.LIB be built before B.LIB has been built?

The reason I'm asking this is for times when I'm not sure if A.LIB is actually calling any routines in B.LIB.  If B.LIB is being called, but I don't have it, will I get unresolved externals when building A.LIB or when building the final main program that pulls everything together?

I need my program to launch an app, as though from a command line. The problem is that I don't know the path to the app. I have tried various forms of SYSTEM, RUNQQ, FINDFILEQ, and FULLPATHQQ to no avail.

The particular present example is launching Adobe Reader, so I need to execute the file AcroRead32.exe. As far as I can see, my program needs the complete to this file in order to launch it. 

I know that I can do a SYSTEM call like "Dir C:\AcroRead32.exe /s > parsethis.txt", and then write code to extract the path from this txt output file. But surely there must be a better way? Even this solution assumes that the app is in the C: drive.

Isn't there some way to return the path to an arbitrary filename from within Fortran?

Intel Parallel Studio XE 2016, including Intel Visual Fortran Compiler 16.0, is now available. If your support license is current you can download and install this at no additional charge from the Intel Registration Center. 

Licensing Changes

With the 2016 version of our products, we are enforcing a limit of three installs per named-user license. If you have been a user of earlier versions, you'll need to upgrade the license file on your system in order to use the 2016 versions. (Earlier product versions will work with the new license.) The simplest way to do this is to reenter your serial number when prompted during install, but there are other options. Please refer to the following articles for more information:

• What to do when you see the message "Maximum number of activations exceeded"
• How to find the Host ID for the Named-User License
• Required Product License Upgrade for Intel Parallel Studio XE 2016
• How do I get a license file for an offline installation of Intel Parallel Studio XE 2016?
• How do I get my license file for Intel Parallel Studio XE 2016?

If you need help with licensing, please ask in our Licensing, Registration and Downloads forum or Intel Premier Support

Microsoft Visual Studio 2015 Information

If you have installed Microsoft Visual Studio 2015 (VS2015), be aware that the default VS2015 installation does not include C++ support, which means that Intel Visual Fortran integration won't install. If you are installing VS2015 new, select Customize and check the box for Visual C++ (see image below). Otherwise, do a Modify of VS2015 and make sure the Visual C++box is checked.

If you don't 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.

Intel Parallel Studio XE 2016, including Intel Fortran Compiler 16.0, is now available. If your support license is current you can download and install this at no additional charge from the Intel Registration Center. 

Licensing Changes

With the 2016 version of our products, we are enforcing a limit of three installs per named-user license. If you have been a user of earlier versions, you'll need to upgrade the license file on your system in order to use the 2016 versions. (Earlier product versions will work with the new license.) The simplest way to do this is to reenter your serial number when prompted during install, but there are other options. Please refer to the following articles for more information:

• What to do when you see the message "Maximum number of activations exceeded"
• How to find the Host ID for the Named-User License
• Required Product License Upgrade for Intel Parallel Studio XE 2016
• How do I get a license file for an offline installation of Intel Parallel Studio XE 2016?
• How do I get my license file for Intel Parallel Studio XE 2016?

If you need help with licensing, please ask in our Licensing, Registration and Downloads forum or Intel Premier Support

I am trying to use a numerical library called UMFPACK.  20 years ago it was all fortran, but today it's in C.  The attached fortran file is a supplied sample Main program to demonstrate calling umfpack from a fortran program.  The attached C file contains C wrapper routines being called from fortran.  When I build it, I get unresolved externals for all the C routines being called from fortran.

I looked at the Intel sample project called "Fortran-Calls-C", but the Microsoft C compiler wouldn't let me put  extern "C" into umfpack's c file.  Maybe that's a good thing, because I really don't want to be editing their C files because there is a large number of them.

How do I get this to work?

Hello

I've been developing a GUI from scratch using Fortran together with some C libraries (mainly OpenGL to draw the widgets). I know that there are many better alternatives for GUI generation and that I am reinventing the wheel, but I thought that it was a good exercise to learn all the object oriented features introduced with the Fortran 2003 standard which were quite new for me.

The point is that I already have something quite acceptable working and I wanted to improve it by making the GUI responsive while running long processes. For this purpose I have used the OpenMP tasks construct, and it works. However, the problem is that the threads involved in the task execution remain active consuming 100% of the CPU after the task completion.

I have tried setting the OMP_WAIT_POLICY variable to PASSIVE and KMP_BLOCKTIME to 0 but it does not solve the issue.

I know that OpenMP is not designed for this purpose but I thought that thanks to the task constructs it would be possible to use it and take advantage of its portability. However having the processors running at 100% while they should be idle waiting for new jobs is not acceptable.

Before moving to other alternatives I would like to know from the experts if I am doing something wrong with it or if I could rearrange the program somehow to avoid this behavior.

I am attaching a simplified code to reproduce the issue.

Thanks in advance!

module common_data

character(len=500) :: my_completed_tasks = ""

end module common_data


module my_routines
  use common_data
  use omp_lib
  implicit none

  contains

  subroutine run_task(name)
    character(len=1), intent(in) :: name

    print*, "Before task creation : thread id: ", omp_get_thread_num(), "/", omp_get_num_threads()
!$omp task shared(my_completed_tasks)
    print*, "Starting task ", name
    print*, "During task execution... thread id: ", omp_get_thread_num(), "/", omp_get_num_threads()
    call sleepqq(5000)
    my_completed_tasks = trim(my_completed_tasks)//""//name
    print*, "Task ", name, " completed"
!$omp end task
    print*, "After task creation: thread id: ", omp_get_thread_num(), "/", omp_get_num_threads()

  end subroutine

end module my_routines


program multitask

use common_data
use my_routines
implicit none
character(len=1) :: key
integer :: i

key = ""
i = 1

!create a team of threads using OpenMP to allow the parallel run of tasks in the background
!$omp parallel

!the main loop is executed by the master thread (mainly to use always the same thread for OpenGL operations)
!$omp master
do while (key.ne."q")

  ! { ... } gui related code and event processing

  write(*,"(a,i3,a)", advance="no") "iter ", i, "> "
  read(*,*) key

  !if an event fires a cpu consuming computation, launch a task that will be executed by other thread keeping the responsiveness of the gui
  call run_task(key)

  i = i + 1
  print*, "Completed tasks: ", trim(my_completed_tasks)

end do
!$omp end master
!$omp end parallel

end program multitask

Hi,

I am trying to do a Fortran code for my project and it requires Intel Fortran Compiler and Microsoft Visual Studio. I currently have the Intel Parallel Studio 2015 and Microsoft Visual Studio Community 2015. The problem is I am not getting the Intel Fortran template in the Visual Studio and I am not able to go ahead with my project. I also tried the trouble shooting part and found out that I am not able to find the VF packages or the Fortran folder which was specified in troubleshooting (VS2015: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Intel Fortran\VFPackages). I found out this by also trying the commands on the cmd prompt. Please help me with this.

Thanks in advance

Savan Rangegowda

Fortran applications that use the Rogue Wave* IMSL* Fortran Numerical Library, specify linking to the static library form of IMSL, and build under Microsoft Visual Studio 2015* (or from a command prompt environment using the Visual Studio 2015 C++ libraries) may get linker errors such as:

imslsuperlu.lib(scomplex.obj) : error LNK2001: unresolved external symbol _fprintf
imslsuperlu.lib(zmemory.obj) : error LNK2001: unresolved external symbol ___iob_func
imslsuperlu.lib(sutil.obj) : error LNK2001: unresolved external symbol _sprintf

The situations where this will appear involve use of IMSL routines that are based on the SuperLU library for solvers and linear algebra operators. Static linking is specified by referencing the IMSL INCLUDE files link_fnl_static.h or link_fnl_static_imsl.h, or if building from the command line and referencing environment variables LINK_FNL_STATIC, LINK_FNL_STATIC_HPC or LINK_FNL_STATIC_IMSL.

These errors are due to incompatibilities in the Microsoft Visual C++* static libraries introduced with Visual Studio 2015. The workaround is to link to the DLL (shared) form of the IMSL libraries. If using the INCLUDE file method, specify link_fnl_shared.h or link_fnl_shared_imsl.h. If linking from the command line, use the environment variables LINK_FNL_SHARED or LINK_FNL_IMSL. (The variants without "IMSL" use the Intel® Math Kernel Library to improve performance; those with "IMSL" do not.)

For more information on building applications with Rogue Wave IMSL, see Configuring Visual Studio for using the IMSL Fortran Numerical Library. If you need further assistance, please refer to Intel® Developer Support.

Hi,

After installing the Intel Visual Fortran Compiler 16.0 on Windows, I noticed that execution of internal write statements leads to Windows mutex handles being created for every internal write so that the number of process handles accumulates over the course of program execution (in my program to a great number). When using Intel(R) Visual Fortran Compiler 15.04, the number of handles does not increase for the same code/project.

Here is a test case that shows that reproduces on my system (Windows 7 x64). 

PROGRAM TestHandles1

    IMPLICIT NONE
    INTEGER(4) :: n
    CHARACTER(LEN=10) :: nchar, lchar
    !---------------------------------------
    DO n = 1, 100000
        WRITE(nchar,'(I0)') n
        WRITE(lchar,'(I0)') LEN_TRIM(nchar)
    ENDDO
    WRITE(*,*) "--> check number of process handles in Windows Task Manager"
    READ(*,*)

END PROGRAM TestHandles1

It does not seem to affect memory use, so I don't know if this is a bug or a feature - it seems harmless at this point. 

Best,
Andi

Dear,

I bought intel fortran compiler last year and I found some issues to use it, however I could not have access to premier site. Could you let me access there? 

Best,

Kunok

We are having issues on windows 7 visual studio 2012/2013, using the intel compiler version 15.
Package ID: w_ccompxe_2015.2.179 w_fcompxe_2015.2.179 w_compxe_2015.2.179w_mkl_p_11.2.2.179

This package contains:
       Intel(R) Math Kernel Library 11.2 Update 2 for Windows*

We are building both a shared and static library composed of D.F90, D_gen.F90
and H.gen.
We then link this library with the main.F90 both statically and shared and
with static or shared modules.

The following combinations work:
1. Shared library with shared modules.
2. Shared library with static modules.
3. Static library with static modules.

BUT, Static library with shared modules fail to link with undefined references.

I've attached the entire build for a simple example which displays the issue, the actual source with the cmake build is in libex/libex.

Also, It works fine all combinations for Intel compilers on linux.

Any help would be appreciated.

Thanks,
Scot

I am having problems with this line of code:

NEXTBL=SUM(MAXLOC(UNITY,MASK=(NSTRM(PORT,:)==SDMXOUT)))

Unity is an array, all containing the vlaue '1'; I am searching for the location within NSTRM for the value SDMXOUT.

For the current value of PORT, the Mask is False for all entries.  In versions up to XE 2015, under these circumstances, MAXLOC would return 0; under the compiler settings for XE 2016, it is returning 1 (I assume this means that the default for old_maxminloc has changed under this version.  (Incidentally, the documentation does not specify which option [no]old_maxminloc or old_maxminloc returns 0 or 1)

David

In the following snippet, Term1 is part of a larger equation:

real(4) :: Term1, T, Twb, Tref
T = Twb
Tref = 273.15

Term1 = ((2501.6 - 2.3263*(Twb-Tref)) / 2501.6 + 1.8577*(T-Tref) - 4.184*(Twb-Tref))

With the temps equal to each other, this term should go to 1.  In fact, by inspecting the form of the equation, it's obvious that it should go to 1.

However, in IVF - when I pause in debug - Term1 is evaluated as -63.62723

Here's the puzzler part:

When I sweep out the numerator w/ my cursor, it's evaluated as 2436.999

When I sweep out the denominator w/ my cursor, it's evaluated as 2436.999

Thus, Term1 should be evaluated very close to 1.0

But it's not!

What the deuce?

I recently upgraded to ifort 16.0 from ifort 15.0.3 for OS X and have encountered an ICE and also an unexpected segmentation fault. 

I experience the ICE when I have two derived types. The first is a component of the second. The first has an empty finalization procedure, which seems to cause the ICE. Both types have overloaded operators. 

module subtype
      implicit none

      type, public :: subtype_t

          real :: val

      contains
          final :: destructor
      end type subtype_t


      public operator (*)
      interface operator (*)
        module procedure op
      end interface


contains

      elemental function op(left,right) result(res)
          real,               intent(in)  :: left
          type(subtype_t),    intent(in)  :: right
          type(subtype_t) :: res

          res%val = left * right%val

      end function

      subroutine destructor(self)
          type(subtype_t),    intent(inout)   :: self

      end subroutine

end module

The above subtype_t is a component of a second derived type of similar structure as

module type
      use subtype
      implicit none

      type, public :: type_t

          type(subtype_t),    allocatable :: lvecs(:)

      end type type_t

      public operator (*)
      interface operator (*)
          module procedure op_two
      end interface


contains


     function op_two(left,right) result(res)
         real,               intent(in)  :: left
         type(type_t),       intent(in)  :: right
         type(type_t)    :: res

         res%lvecs = left * right%lvecs

     end function

end module

Trying to compile the above modules with ifort-16.0 -c -assume realloc-lhs produces an ICE. If the finalization procedure is commented out in subtype_t the code compiles without error. ifort-15.0.3 compiles in either case without error.

Assuming the finalization procedure has been commented out and the modules compile, I experience a run-time segmentation fault when testing the multiplication operator with ifort-16.0 using -assume realloc-lhs. 

program main
    use type
    implicit none

    type(type_t)    :: testing, res


    ! Allocate derived type component
    allocate(testing%lvecs(1))

    ! Assign values
    testing%lvecs(1)%val = 1.


    ! Test multiplication operation
    ! Seg-fault with ifort 16.0 using -assume realloc-lhs
    ! Executes without error using ifort 15.0.3
    res = 1. * testing


end program main

Source files are attached.