What is the most recent Intel Fortran that will install for Mac OS 10.10.5?

Thanks, Michael

The following code segfaults because the explicit allocation in the type casting does not work any more with ifort2018 beta. I filed a bug report already. A workaround is given.

module event_base
  implicit none
  private
  public :: event_callback_t
  public :: event_callback_nop_t
  public :: eio_callback_t
  public :: dispatch

  type, abstract :: event_callback_t
     private
  end type event_callback_t

  type, extends (event_callback_t) :: event_callback_nop_t
     private
  end type event_callback_nop_t

  type, abstract :: generic_event_t
     real, dimension(:), allocatable :: sqme
  end type generic_event_t

  type :: eio_callback_t
     class(event_callback_t), allocatable :: callback
   contains
     procedure :: set_parameters => eio_callback_set_parameters  
  end type eio_callback_t

contains

  subroutine eio_callback_set_parameters (eio, callback, i)
    class(eio_callback_t), intent(inout) :: eio
    class(event_callback_t), intent(in) :: callback
    integer, intent(in) :: i
    allocate (eio%callback, source = callback)
  end subroutine eio_callback_set_parameters

  subroutine dispatch (eio, event_callback)
    type(eio_callback_t), intent(inout) :: eio
    class(event_callback_t), allocatable, intent(in) :: event_callback
    !!! Workaround:
    ! type(event_callback_nop_t) :: tmp
    if (allocated (event_callback)) then
       call eio%set_parameters (event_callback, 1)
    else
       call eio%set_parameters (event_callback_nop_t (), 0)
       ! call eio%set_parameters (tmp, 0)
    end if
  end subroutine dispatch

end module event_base

program main
  use event_base

  type(eio_callback_t) :: eio
  class(event_callback_t), allocatable :: foo
  call dispatch (eio, foo)

end program main

Dear all,

currently I am working on the parallelization of a Monte Carlo code for particle transport written in FORTRAN 77 using OpenMP and the Intel Fortran Compiler (version 2017). I have successfully implemented the parallelization and on several tests in general I obtain a better performance (up to 30% faster) than the original parallelization scheme of the code, which relies of running several processes in parallel using a Batch Queuing System.

However, my problem is when the particles information (energy, position, direction) is read from a file (each line of this file contains the information of one particle, and therefore several read operations are done during the simulation) the performance of the code using OpenMP drops severally and then it is similar to the performance obtained with the original parallel implementation. Therefore I am essentially losing the original advantage of the OpenMP implementation when a file is used as an input for the simulation.

I really do not know if I am using the best approach and therefore I would like to ask you for advice. My approach is that each thread opens the file with its own unit number, as shown in the following snippet:

C$OMP0PARALLEL DEFAULT(SHARED)

      omp_iam = OMP_GET_THREAD_NUM()
      omp_size = OMP_GET_NUM_THREADS()

      nnphsp = INT(omp_iam*nshist/omp_size)+1

      UNIT_PHSP = 44 + omp_iam
      OPEN(UNIT=UNIT_PHSP,FILE=NAME_PHSP,FORM='UNFORMATTED',ACCESS='
     *DIRECT', RECL=PHSP_RECL,STATUS='OLD',IOSTAT=IERR_PHSP)

C$OMP0END PARALLEL

The file containing the particle information is divided among the threads through the nnpsh variable. Therefore none of the threads reads the same line during the simulation. Then, in order to read a line the following code is used:

      READ(UNIT_PHSP,REC=nnphsp,IOSTAT=IERR_PHSP) latchi,ESHOR
     *T,X_PHSP_SHORT,Y_PHSP_SHORT, U_PHSP_SHORT,V_PHSP_SHORT,W
     *T_PHSP_SHORT

I would like to know if there is a better approach to the above mentioned. A distinctive characteristic of this code is that due to the stochastic nature of the Monte Carlo simulation the threads do not access the file at the same time or in an ordered way. Each time that a new particle is going to be simulated its information is read from the file. Thanks for your help!

The example given on the GCC page for the same, uses /dev/urandom is as follows:

          subroutine init_random_seed()

            use iso_fortran_env, only: int64

            implicit none
            integer, allocatable :: seed(:)
            integer :: i, n, un, istat, dt(8), pid
            integer(int64) :: t

            call random_seed(size = n)
            allocate(seed(n))
            ! First try if the OS provides a random number generator

            open(newunit=un, file="/dev/urandom", access="stream", &
                 form="unformatted", action="read", status="old", iostat=istat)

            if (istat == 0) then
               read(un) seed
               close(un)
            else
            .
            .
            end if
            call random_seed(put=seed)

          end subroutine init_random_seed

I have a couple of questions:

• Shouldn't the 'FORM' of the file opened be "BINARY"?
• I don't understand how much data the READ pulls from /dev/urandom.
• Here /dev/urandom is just used to initialize the seed for RANDOM_NUMBER(). But is there a way I can directly use /dev/urandom?

Hi,

I'm writing some FORTRAN code that calls a C library, and having issues when I compile the code with -O3. The code that is breaking is this:

Subroutine create_qsched_tasks(nr_threads)
Use, Intrinsic :: ISO_C_BINDING
Use cell_list_module
  Use quicksched
Implicit None

Integer, Intent(In) :: nr_threads
Integer(Kind=C_INT), Dimension(1:number_cells) :: cell_res, sorts
Integer(Kind=C_INT) :: i, j ,k, id, p, id2, temp
Integer(Kind=C_INT), Target :: data(0:10)
Type(C_PTR) :: dat_ptr

dat_ptr = C_LOC(data(0))

qsched = f_qsched_create()
call qsched_init(qsched,Int(nr_threads, C_INT), 0)
do i=1,number_cells
  cell_res(i) = qsched_addres(qsched, qsched_owner_none, qsched_res_none)
  print *, i
  data(0) = i
  sorts(i) = qsched_addtask(qsched, type_sort, 0, dat_ptr, int(c_sizeof(type_sort), C_INT), cell_list(i)%cell_count)
  call qsched_addlock(qsched, sorts(i), cell_res(i))
end do

The qsched_addtask function runs some code, but also contains 

 printf("data is %i, size is %i\n", *(int*)data, data_size);

where data is a void* and is argument 4, and data_size is argument 5. The output from this code is:

1
data is 0, size is 4
2
data is 0, size is 4
3
data is 0, size is 4

However with -O2 I get:

1
data is 1, size is 4
2
data is 2, size is 4
3
data is 3, size is 4
 

The function itself seems to work fine, as following this code I have another statement:

do i=0, x_cells+1
  do j=0, y_cells+1
    do k=0, z_cells+1
      id = 1+i+(x_cells+2)*(j+(y_cells+2)*k)
        data(0) = id
        temp = qsched_addtask(qsched, type_vdw_self, 0, dat_ptr, int(c_sizeof(type_sort),C_INT), cell_list(id)%cell_count)
        call qsched_addlock(qsched, temp, cell_res(id))
        call qsched_addunlock(qsched, sorts(id), temp)
...

which functions completely as expected, and the value stored in data(0) is passed correctly to the C library.

The interoperable function in question is as follows:

    Integer(Kind=C_INT) Function qsched_addtask(s, types, flags, data, data_size, cost) BIND(C)
      Use, Intrinsic :: ISO_C_BINDING
      Implicit None

      Type(C_PTR), VALUE :: s
      Integer(Kind=C_INT), Intent(In), VALUE :: types
      Integer(Kind=C_INT), Intent(In), VALUE :: flags
      Type(C_PTR), VALUE :: data
      Integer(Kind=C_INT), Intent(In), VALUE :: data_size
      Integer(Kind=C_INT), Intent(In), VALUE :: cost

    End Function

Am I doing something wrong that means the compiler thinks it can optimise away the value stored in data(0) in the first case?

Thanks

Aidan Chalk

GETPID() is a function that is part of the IFPORT module. I am using this function in a module called 'random.f90', which in-turn is USEd in the main program 'test_rand.f90'

1. Upon not USEing IFPORT, compilation of the moduled results in the following error:

   $ ifort -c random.f90
   random.f90(47): error #6404: This name does not have a type, and must have an explicit type.   [GETPID]
               pid = GETPID()
   ------------------^
   compilation aborted for random.f90 (code 1)

2.  But if I add a USE IFPORT statement at the beginning, the compilation goes through without any errors, but linking results in an error I don't understand:
   

   $ ifort random.mod test_rand.f90
   test_rand.f90(3): error #6406: Conflicting attributes or multiple declaration of name.   [RANDOM]
       USE random
   --------^
   compilation aborted for test_rand.f90 (code 1)

According to the IFPORT article, they are both valid way of using functions from the Portability module, but both run into errors. I am using the GETPID() function exactly as described in its Intel reference, with the variable 'pid' defined as an INTEGER.

Using Gfortran, the code compiles and runs correctly (of course, without the USE IFPORT statement), so, for portability, I would like to get it working without the explicit USE statement. Any ideas on what I might be doing wrong?

ifort 18 feature request: using F08 atomic subroutines with array components (using an integer array component of a derived type coarray together with atomic_define)

I am currently demanding something from the Fortran 2008 language that may not be explicitly specified by the standard. Also, there might be some reason that such a feature can't be implemented in a safe manner, that I am not aware of. Nevertheless, ifort as well as gfortran/OpenCoarrays do support the use of derived type coarrays with an (integer) array component together with F2008 atomic subroutines: https://github.com/MichaelSiehl/Atomic_Subroutines--Using_Coarray_Arrays_to_Allow_for_Safe_Remote_Communication

Gfortran/OpenCoarrays does fully support this. But with ifort 18 beta (and probably with ifort 17 as well -I don't have access to it yet-) support is only partly implemented: we can use an integer array component with atomic_define for local access to the derived type coarray array component (one array element only of course), but for remote references we get 'error #8583: COARRAY argument of ATOMIC_DEFINE/ATOMIC_REF intrinsic subroutine shall be a coarray.' (I am leaving out atomic_ref here, because I use atomic_ref only for local references to an integer array component of a derived type coarray, which works well with ifort yet).

I set up an example of a customized synchronization procedure using atomic subroutines, here: https://github.com/MichaelSiehl/Atomic_Subroutines--How_the_Parallel_Codes_may_look_like--Part_2 . The code in the src folder compiles and runs using gfortran/OpenCoarrays, but ifort 18 can't handle the following statement in the OOOPimsc_admImageStatus_CA.f90 source file (line 265):

call atomic_define (Object_CA [intImageNumber] % mA_atomic_intImageActivityFlag99(intArrIndex,1), intImageActivityFlag)

(here, 'Object_CA' is a derived type coarray and 'mA_atomic_intImageActivityFlag99' is an integer array component)

ifort 18 beta generates the above mentioned compile time 'error #8583: COARRAY argument of ATOMIC_DEFINE/ATOMIC_REF intrinsic subroutine shall be a coarray' with that.

On the other hand, if we omit only the remote reference '[intImageNumber]', ifort does compile the code into a working application (not really working of course, because there is no remote reference any more):

call atomic_define (Object_CA % mA_atomic_intImageActivityFlag99(intArrIndex,1), intImageActivityFlag)

If we only omit the array index, we get the correct compiler 'error #6360: A scalar-valued argument is required in this context':

call atomic_define (Object_CA [intImageNumber] % mA_atomic_intImageActivityFlag99, intImageActivityFlag)

Thus, my current main question: Are there any doubts that the above remote reference to an array component using atomic_define shouldn't be implemented with ifort yet?

Best Regards

The attached code leads to a seg fault with ifort2018beta, however works with gfortran 4.8., 4.9., 5, 6, 7, and 8 as well as nagfor 6 and PGF17.3. It also worked with ifort 17.0.3, so this clearly is a regression. I filed this as a report to the support under the number 02772804.

This is the message from the backtrace etc.:

 PDG(out) =  -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6

forrtl: severe (174): SIGSEGV, segmentation fault occurred

Image              PC                Routine            Line        Source             

whizard_test       000000000041133D  Unknown               Unknown  Unknown

libpthread-2.19.s  00007F983ACBD330  Unknown               Unknown  Unknown

libc-2.19.so       00007F983A967D2C  cfree                 Unknown  Unknown

whizard_test       000000000042406D  Unknown               Unknown  Unknown

whizard_test       0000000000404E5D  Unknown               Unknown  Unknown

whizard_test       0000000000403536  Unknown               Unknown  Unknown

whizard_test       0000000000402A1E  Unknown               Unknown  Unknown

libc-2.19.so       00007F983A906F45  __libc_start_main     Unknown  Unknown

whizard_test       0000000000402929  Unknown               Unknown  Unknown

I need to run a code written in Fortran 77. I want to know in which part of this web page I can download the compiler composerxe-2011.7.256?. Thank you!

I am trying to add the compiler to use it with XCode, I have version 8.3.2, but it seems to be missing from the list of available compilers there, any idea why this happens? I did set up all the environmental variables beforehand. I also can't run the compiler from the terminal window, I get the following error: 

Undefined symbols for architecture x86_64:

  "_gemm_", referenced from:

      _MAIN__ in ifortkGcltQ.o

ld: symbol(s) not found for architecture x86_64

This is the code I was trying to compile:

program test

implicit none
real, dimension(2,2) :: testA, testB, testC

testA = 1
testB = 1
testC = 0  ! I don't think I need this line, but it shouldn't matter

call gemm(testA, testB, testC)

write(*,*) testC

end program test

Hi all,

I'm having a double free or corruption problem when trying to use the Reallocate function (from Fortran 90 Numerical Recipes) within an OpenMP parallel do directive

*** glibc detected *** ./myprog: double free or corruption (out): 0x00007ffdf7d770f0 ***

Here is the reallocate function :

FUNCTION reallocate_iv(p,n)
    INTEGER(I4B), DIMENSION(:), POINTER :: p, reallocate_iv
    INTEGER(I4B), INTENT(IN) :: n
    INTEGER(I4B) :: nold,ierr
    allocate(reallocate_iv(n),stat=ierr)

    if (ierr /= 0) call &
	nrerror('reallocate_iv: problem in attempt to allocate memory')
    if (.not. associated(p)) RETURN
	nold=size(p)

    reallocate_iv(1:min(nold,n))=p(1:min(nold,n))
    deallocate(p)
END FUNCTION reallocate_iv

and here is the main body of the code calling reallocate within an OpenMP parallel do directive :

Integer, Dimension(:), POINTER :: col_sprZ
Integer :: nnz, size,spr_perc,spr_size

!$OMP PARALLEL PRIVATE (size,spr_size,,col_sprZ,nnz)
!$OMP DO SCHEDULE(DYNAMIC)
do kk=1,NB
      spr_size = nint((spr_perc*9.*size**2.)/100.)
      Allocate(col_sprZ(spr_size));
      !! here Call a Subroutine which calculates nnz and col_sprZ (sparse format storage)
      col_sprZ => Reallocate(col_sprZ,nnz);
      - - - - - - - - - - - - -
      Deallocate(col_sprZ);
enddo
!$OMP END DO
!$OMP END PARALLEL

The code works perfectly and yields good results if I discard/comment the OpenMP directive or compile with the -O0 -openmp  -heap arrays. It works also fine if I keep the openmp directive and compile with -O3 -openmp -heap arrays but use a classic temporary allocatable array to reallocate col_sprZ instead of the reallocate function.

I also noticed that the problem could disappear if I decrease the size of the array col_sprZ. I haven't the required authorization to check if the problem is caused by the stack size limits.

I am using intel composer 13.1.3 on Linux.

Did anyone understand or see the cause of this problem ? Thanks !

Hi 

I use Intel Fortran compiler. my array is 2 dimensions an it's boundary is between 1 to 16.

this is my code and why fortran print a(0,0) and a(17,17) equal to 0 and 0

program hirarchichal_detreministic
          implicit none

          integer, parameter:: N=4 !initial core
          integer, parameter:: ns=1 !number of steps
          integer, parameter:: nn = n**(ns+1)
          integer, dimension (1:nn,1:nn):: a !adjacency matrix

          integer:: i, j, k, ii, m, l

          real::p(nn)

          open(1,file='out')

          a = 0
          print*,sum(a), a(0,0), a(17,17)
          pause

          !******************************************
          !initial fully connected network; ns=0
          a(1:n,1:n)=1

          do i=1,n
			 a(i,i)=0
          enddo
          !******************************************
          print*,sum(a), a(0,0), a(17,170)
          do i=1,ns

			 do k= 2, n-1

				    do ii= k*(n**i)+1, (k+1)*(n**i)

						  do j=k*(n**i)+1, (k+1)*(n**i)
								!print*,i,k,ii,j
								l = mod(ii,n**i+1)
								m = mod(j,n**i+1)
								a(ii,j) = a(l,m)
								print '(20(I2,2x))',sum(a), i, k, ii, j, l, m
						  enddo

						 ! pause
				    enddo
			 enddo
          enddo
          print*,"fd"
		  Do i=1, nn
			 !k=sum(a(1:nn,i))
			 !p(k)=p(k)+1.
			 do j=1,nn
				 write(1,*)i,j, a(i,j)
			 enddo
		  enddo

		  p=p/sum(a)
		   print*,"fd/"
		  do i=1,nn
			 write(1,*)i,p(i)
		  enddo
          end

this is my code and why fortran print a(0,0) and a(17,17)

Hi all,

I am debugging a friend's code. At some point he calls a subroutine with the wrong number of arguments, actually he gives more actual arguments than dummy ones. I didn't spot the error until I used the -warn all option to compile. Is this the expected behaviour?

Using Intel Fortran Compiler for Intel64, Version 15 on Linux CentOS 6

Thanks in advance,

NL

I am trying to run a program on intel (some options are better supported by it) but the problem comes when I try to compile the file. The makefile itself works but the makefile.in has some issues with the flags. 

The makefile.in file: 

# Makefile.LINUX.in

WARN = -ansi -fullwarn

PLATFORM = LINUX
#F90 = mpif90
cc = mpicc
CC = mpicc
AR = xiar rcv
RANLIB = xiar -ts

MPI_LIBS =

PARMETIS_LIBS = -L/opt/parmetis -lparmetis
METIS_LIBS = -lmetis

#HDF5_DIR = /opt/hdf5
#HDF5_INC = -I$(HDF5_DIR)/include
#HDF5_LIB = -L$(HDF5_DIR)/lib -lhdf5_fortran -lhdf5hl_fortran -lhdf5 -lhdf5_hl -lz

# compile with -DNOHDF to disable hdf5 support

# with optimization
CFLAGS = -c -O3
OPTFFLAGS = -c -O3 -DMPIDEFS2 -DLIT_SKIP_HOOKS -DNOHDF
CDPOPTFFLAGS = -c -O3 -DMPIDEFS2
VERYOPTFFLAGS = -c -O3 -xW -DMPIDEFS2 -DLIT_SKIP_HOOKS

DEBUGFLAGS = -C -debug extended -traceback -DNOHDF
DBGFFLAGS = -c -g -O0 $(DEBUGFLAGS) -DMPIDEFS2 -DDEBUG_MODE -DLIT_SKIP_HOOKS
CDPDBGFFLAGS = -c -g -O0 $(DEBUGFLAGS) -DMPIDEFS2 -DDEBUG_MODE

FLD =

and the error that comes up

(cd src ; make "FFLAGS = -c -O3 -DMPIDEFS2 -DLIT_SKIP_HOOKS -DNOHDF ")
make[1]: Entering directory '/home/igarcia/U-Arizona/compiled/lit1.1-1_int/src'
c -O3 -DMPIDEFS2 -DLIT_SKIP_HOOKS -DNOHDF   -I. precision_m.f90
make[1]: c: Command not found
make[1]: [Makefile:45: precision_m.o] Error 127 (ignored)

I don't really know what I am doing wrong since the c option in gfortran and ifort is the same... perhaps a syntax error. 

Do I use SIMD or should I use MPI, when I need no "message passing"? Or are they both equivalent?

I have lots of functions and subroutines in modules, which I will have to turn ELEMENTAL (some of them IMPURE), and also bring in lots of structural changes, if I am to use SIMD. Of course, if MPI, I won't really have to change anything.

The IMPURities in procedures mainly come in due to calls to RANDOM_NUMBER. But I could pre-generate arrays of random numbers instead.

So will using SIMD be worth the effort?

Hello,
I have been looking at the behavior of the check:bounds compiler option, and in particular I read through this forum thread. I had a memory corruption in a program I'm writing (which I fixed now) that I think should have been caught by the run-time check. I adapted an example from the forum thread to demonstrate the behavior:

      program ex

        implicit none

        call modify(5)

      contains

        subroutine modify(n)

          implicit none

          integer :: n
          real(kind=8) :: a(3)

          print*, a(1:n)

          CALL modify2(a(1:n),n)

          a(1:n) = 10.5D0

        end subroutine modify

        subroutine modify2(a,n)

          implicit none
          integer :: n
          real(kind=8)  :: a(n)

          a(1:n) = 10.0
          print*, a(1:n)

        end subroutine

      end

The behavior I am questioning is: Visual fortran gives me the error "Subscript #1 of the array A has value 4 which is greater than the upper bound of 3" at line 20. I agree that indeed, I go out of bounds at that moment. I understand why I do not get the error at line 30, since I think Fortran allows to pass only parts of arrays and then access the subsequent elements simply because they are contiguous in memory.
However, I do not understand why I do not get a runtime error at line 18: I am explicitely asking Fortran to pass an array of size n=5, when a is only size 3. Should that not result in a warning? Or what is the use of allowing such behavior?

Thanks in advance!
Etienne Pellegrini

EDIT: I am running Intel Parallel Studio XE 2016 Composer, Version 16.0.0046.12

Hi,

I have a problem with the time spent on compile, I work with a program with several huge equations and for this reason the intel fortran spent about 9 minuites to compile the program. My question is, there is some options to make the compile faster?

DESCRIPTION     =       INTEL ($SFC/$SCC)
DMPARALLEL      =        1
OMPCPP          =       # -D_OPENMP
OMP             =       # -openmp -fpp -auto
OMPCC           =       # -openmp -fpp -auto
SFC             =       ifort
SCC             =       icc
CCOMP           =       icc
DM_FC           =       mpif90 -f90=$(SFC)
DM_CC           =       mpicc -cc=$(SCC) -DMPI2_SUPPORT
FC              =       time $(DM_FC)
CC              =       $(DM_CC) -DFSEEKO64_OK 
LD              =       $(FC)
RWORDSIZE       =       $(NATIVE_RWORDSIZE)
PROMOTION       =       -real-size `expr 8 \* $(RWORDSIZE)` -i4
ARCH_LOCAL      =       -DNONSTANDARD_SYSTEM_FUNC  -DWRF_USE_CLM
CFLAGS_LOCAL    =       -w -O3 -ip #-xHost -fp-model fast=2 -no-prec-div -no-prec-sqrt -ftz -no-multibyte-chars
LDFLAGS_LOCAL   =       -ip #-xHost -fp-model fast=2 -no-prec-div -no-prec-sqrt -ftz -align all -fno-alias -fno-common
CPLUSPLUSLIB    =       
ESMF_LDFLAG     =       $(CPLUSPLUSLIB)
FCOPTIM         =       -O3
FCREDUCEDOPT    =       $(FCOPTIM)
FCNOOPT         =       -O0 -fno-inline -no-ip
FCDEBUG         =       # -g $(FCNOOPT) -traceback # -fpe0 -check noarg_temp_created,bounds,format,output_conversion,pointers,uninit -ftrapuv -unroll0 -u
FORMAT_FIXED    =       -FI
FORMAT_FREE     =       -FR
FCSUFFIX        =
BYTESWAPIO      =       -convert big_endian
RECORDLENGTH    =       -assume byterecl
FCBASEOPTS_NO_G =       -ip -fp-model precise -w -ftz -align all -fno-alias $(FORMAT_FREE) $(BYTESWAPIO) #-xHost -fp-model fast=2 -no-heap-arrays -no-prec-div -no-prec-sqrt -fno-common
FCBASEOPTS      =       $(FCBASEOPTS_NO_G) $(FCDEBUG)
MODULE_SRCH_FLAG =     
TRADFLAG        =      -traditional-cpp
CPP             =      /lib/cpp -P -nostdinc
AR              =      ar
ARFLAGS         =      ru
M4              =      m4
RANLIB          =      ranlib
RLFLAGS         =
CC_TOOLS        =      $(SCC) 

###########################################################
######################
# POSTAMBLE

FGREP = fgrep -iq

ARCHFLAGS       =    $(COREDEFS) -DIWORDSIZE=$(IWORDSIZE) -DDWORDSIZE=$(DWORDSIZE) -DRWORDSIZE=$(RWORDSIZE) -DLWORDSIZE=$(LWORDSIZE) \
                     $(ARCH_LOCAL) \
                     $(DA_ARCHFLAGS) \
                      -DDM_PARALLEL \
                       \
                      -DNETCDF \
                       \
                       \
                       \
                       \
                       \
                       \
                       \
                       \
                       \
                       \
                      -DUSE_ALLOCATABLES \
                      -DGRIB1 \
                      -DINTIO \
                      -DKEEP_INT_AROUND \
                      -DLIMIT_ARGS \
                      -DCONFIG_BUF_LEN=$(CONFIG_BUF_LEN) \
                      -DMAX_DOMAINS_F=$(MAX_DOMAINS) \
                      -DMAX_HISTORY=$(MAX_HISTORY) \
                      -DNMM_NEST=$(WRF_NMM_NEST)
CFLAGS          =    $(CFLAGS_LOCAL) -DDM_PARALLEL  \
                      -DMAX_HISTORY=$(MAX_HISTORY) -DNMM_CORE=$(WRF_NMM_CORE)
FCFLAGS         =    $(FCOPTIM) $(FCBASEOPTS)
ESMF_LIB_FLAGS  =    
# ESMF 5 -- these are defined in esmf.mk, included above
 ESMF_IO_LIB     =    -L$(WRF_SRC_ROOT_DIR)/external/esmf_time_f90 -lesmf_time
ESMF_IO_LIB_EXT =    -L$(WRF_SRC_ROOT_DIR)/external/esmf_time_f90 -lesmf_time
INCLUDE_MODULES =    $(MODULE_SRCH_FLAG) \
                     $(ESMF_MOD_INC) $(ESMF_LIB_FLAGS) \
                      -I$(WRF_SRC_ROOT_DIR)/main \
                      -I$(WRF_SRC_ROOT_DIR)/external/io_netcdf \
                      -I$(WRF_SRC_ROOT_DIR)/external/io_int \
                      -I$(WRF_SRC_ROOT_DIR)/frame \
                      -I$(WRF_SRC_ROOT_DIR)/share \
                      -I$(WRF_SRC_ROOT_DIR)/phys \
                      -I$(WRF_SRC_ROOT_DIR)/chem -I$(WRF_SRC_ROOT_DIR)/inc \
                      -I$(NETCDFPATH)/include \
                      
REGISTRY        =    Registry
CC_TOOLS_CFLAGS = -DNMM_CORE=$(WRF_NMM_CORE)

 LIB_BUNDLED     = \
                      $(WRF_SRC_ROOT_DIR)/external/fftpack/fftpack5/libfftpack.a \
                      $(WRF_SRC_ROOT_DIR)/external/io_grib1/libio_grib1.a \
                      $(WRF_SRC_ROOT_DIR)/external/io_grib_share/libio_grib_share.a \
                      $(WRF_SRC_ROOT_DIR)/external/io_int/libwrfio_int.a \
                      $(ESMF_IO_LIB) \
                      $(WRF_SRC_ROOT_DIR)/external/RSL_LITE/librsl_lite.a \
                      $(WRF_SRC_ROOT_DIR)/frame/module_internal_header_util.o \
                      $(WRF_SRC_ROOT_DIR)/frame/pack_utils.o 

 LIB_EXTERNAL    = \
                      -L$(WRF_SRC_ROOT_DIR)/external/io_netcdf -lwrfio_nf -L/gpfs1/home/Libs/INTEL/NETCDF4/netcdf-4.4.1.1_with_v17/lib -lnetcdff -lnetcdf     

LIB             =    $(LIB_BUNDLED) $(LIB_EXTERNAL) $(LIB_LOCAL) $(LIB_WRF_HYDRO)
LDFLAGS         =    $(OMP) $(FCFLAGS) $(LDFLAGS_LOCAL) 
ENVCOMPDEFS     =    
WRF_CHEM        =       0 
CPPFLAGS        =    $(ARCHFLAGS) $(ENVCOMPDEFS) -I$(LIBINCLUDE) $(TRADFLAG) 
NETCDFPATH      =    /gpfs1/home/Libs/INTEL/NETCDF4/netcdf-4.4.1.1_with_v17
HDF5PATH        =    
WRFPLUSPATH     =    
RTTOVPATH       =    
PNETCDFPATH     =    

bundled:  io_only 
external: io_only $(WRF_SRC_ROOT_DIR)/external/RSL_LITE/librsl_lite.a gen_comms_rsllite module_dm_rsllite $(ESMF_TARGET)
io_only:  esmf_time wrfio_nf   \
          wrf_ioapi_includes wrfio_grib_share wrfio_grib1 wrfio_int fftpack

######################
------------------------------------------------------------------------
Settings listed above are written to configure.wrf.
If you wish to change settings, please edit that file.
If you wish to change the default options, edit the file:
     arch/configure_new.defaults
NetCDF users note:
 This installation of NetCDF supports large file support.  To DISABLE large file
 support in NetCDF, set the environment variable WRFIO_NCD_NO_LARGE_FILE_SUPPORT
 to 1 and run configure again. Set to any other value to avoid this message.
  

Testing for NetCDF, C and Fortran compiler

This installation of NetCDF is 64-bit
                 C compiler is 64-bit
           Fortran compiler is 64-bit
              It will build in 64-bit

iitmlogin5:/moes/home/yang/WRF_chem/WRFV3 $ ./compile em_real > compile.log
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.2.144 Build 20140120
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

ar: creating libesmf_time.a
ar: creating ./libio_grib_share.a
ar: creating ../libio_grib1.a
0.10user 0.28system 0:00.34elapsed 111%CPU (0avgtext+0avgdata 29804maxresident)k
0inputs+160outputs (0major+25859minor)pagefaults 0swaps
0.50user 0.32system 0:00.77elapsed 106%CPU (0avgtext+0avgdata 34384maxresident)k
0inputs+312outputs (0major+28532minor)pagefaults 0swaps
0.34user 0.35system 0:00.64elapsed 108%CPU (0avgtext+0avgdata 34116maxresident)k
0inputs+400outputs (0major+28753minor)pagefaults 0swaps
0.75user 0.38system 0:01.10elapsed 103%CPU (0avgtext+0avgdata 42540maxresident)k
0inputs+576outputs (0major+29966minor)pagefaults 0swaps
ar: creating libwrfio_int.a

real    0m0.601s
user    0m0.340s
sys     0m0.304s
0.17user 0.46system 0:00.63elapsed 100%CPU (0avgtext+0avgdata 54824maxresident)k
0inputs+304outputs (0major+36351minor)pagefaults 0swaps
ar: creating libfftpack.a
1.54user 0.24system 0:01.76elapsed 101%CPU (0avgtext+0avgdata 43680maxresident)k
0inputs+416outputs (0major+30901minor)pagefaults 0swaps
0.49user 0.33system 0:00.78elapsed 107%CPU (0avgtext+0avgdata 45160maxresident)k
0inputs+320outputs (0major+30938minor)pagefaults 0swaps
opening Registry/registry.dimspec
including Registry/registry.dimspec
opening Registry/Registry.EM_COMMON
including Registry/Registry.EM_COMMON
opening Registry/registry.io_boilerplate
including Registry/registry.io_boilerplate
opening Registry/io_boilerplate_temporary.inc
including Registry/io_boilerplate_temporary.inc
opening Registry/registry.fire
including Registry/registry.fire
opening Registry/registry.avgflx
including Registry/registry.avgflx
opening Registry/registry.stoch
including Registry/registry.stoch
opening Registry/registry.les
including Registry/registry.les
opening Registry/registry.cam
including Registry/registry.cam
opening Registry/registry.clm
including Registry/registry.clm
opening Registry/registry.ssib
including Registry/registry.ssib
opening Registry/registry.lake
including Registry/registry.lake
opening Registry/registry.diags
including Registry/registry.diags
opening Registry/registry.afwa
including Registry/registry.afwa
opening Registry/registry.rasm_diag
including Registry/registry.rasm_diag
opening Registry/registry.sbm
including Registry/registry.sbm
opening Registry/registry.elec
including Registry/registry.elec
opening Registry/registry.bdy_perturb
including Registry/registry.bdy_perturb

real    0m0.403s
user    0m0.100s
sys     0m0.340s
opening Registry/registry.hyb_coord
including Registry/registry.hyb_coord
opening Registry/registry.new3d_wif
including Registry/registry.new3d_wif

real    0m0.401s
user    0m0.109s
sys     0m0.324s
Registry INFO variable counts: 0d 2275 1d 124 2d 1068 3d 842
REGISTRY WARNING: aerod(grid%sm31,grid%sm32,grid%sm33,itrace): aerod_b is not a variable or number; ignoring it
REGISTRY WARNING: aerod(grid%sm31,grid%sm32,grid%sm33,itrace): aerod_bt is not a variable or number; ignoring it
REGISTRY WARNING: om_tmp: om_tmp_b is not a variable or number; ignoring it
REGISTRY WARNING: om_tmp: om_tmp_bt is not a variable or number; ignoring it
REGISTRY WARNING: om_s: om_s_b is not a variable or number; ignoring it
REGISTRY WARNING: om_s: om_s_bt is not a variable or number; ignoring it
REGISTRY WARNING: om_u: om_u_b is not a variable or number; ignoring it
REGISTRY WARNING: om_u: om_u_bt is not a variable or number; ignoring it
REGISTRY WARNING: om_v: om_v_b is not a variable or number; ignoring it
REGISTRY WARNING: om_v: om_v_bt is not a variable or number; ignoring it
REGISTRY WARNING: om_ml: om_ml_b is not a variable or number; ignoring it
REGISTRY WARNING: om_ml: om_ml_bt is not a variable or number; ignoring it
REGISTRY WARNING: field_sf: field_sf_b is not a variable or number; ignoring it
REGISTRY WARNING: field_sf: field_sf_bt is not a variable or number; ignoring it
REGISTRY WARNING: field_pbl: field_pbl_b is not a variable or number; ignoring it
REGISTRY WARNING: field_pbl: field_pbl_bt is not a variable or number; ignoring it
REGISTRY WARNING: field_conv: field_conv_b is not a variable or number; ignoring it
REGISTRY WARNING: field_conv: field_conv_bt is not a variable or number; ignoring it
REGISTRY WARNING: ru_tendf_stoch: ru_tendf_stoch_b is not a variable or number; ignoring it
REGISTRY WARNING: ru_tendf_stoch: ru_tendf_stoch_bt is not a variable or number; ignoring it
REGISTRY WARNING: rv_tendf_stoch: rv_tendf_stoch_b is not a variable or number; ignoring it
REGISTRY WARNING: rv_tendf_stoch: rv_tendf_stoch_bt is not a variable or number; ignoring it
REGISTRY WARNING: rt_tendf_stoch: rt_tendf_stoch_b is not a variable or number; ignoring it
REGISTRY WARNING: rt_tendf_stoch: rt_tendf_stoch_bt is not a variable or number; ignoring it
REGISTRY WARNING: rand_pert: rand_pert_b is not a variable or number; ignoring it
REGISTRY WARNING: rand_pert: rand_pert_bt is not a variable or number; ignoring it
REGISTRY WARNING: pattern_spp_conv: pattern_spp_conv_b is not a variable or number; ignoring it
REGISTRY WARNING: pattern_spp_conv: pattern_spp_conv_bt is not a variable or number; ignoring it
REGISTRY WARNING: pattern_spp_pbl: pattern_spp_pbl_b is not a variable or number; ignoring it
REGISTRY WARNING: pattern_spp_pbl: pattern_spp_pbl_bt is not a variable or number; ignoring it
REGISTRY WARNING: pattern_spp_lsm: pattern_spp_lsm_b is not a variable or number; ignoring it
REGISTRY WARNING: pattern_spp_lsm: pattern_spp_lsm_bt is not a variable or number; ignoring it
REGISTRY WARNING: rstoch: rstoch_b is not a variable or number; ignoring it
REGISTRY WARNING: rstoch: rstoch_bt is not a variable or number; ignoring it
REGISTRY WARNING: field_u_tend_perturb: field_u_tend_perturb_b is not a variable or number; ignoring it
REGISTRY WARNING: field_u_tend_perturb: field_u_tend_perturb_bt is not a variable or number; ignoring it
REGISTRY WARNING: field_v_tend_perturb: field_v_tend_perturb_b is not a variable or number; ignoring it
REGISTRY WARNING: field_v_tend_perturb: field_v_tend_perturb_bt is not a variable or number; ignoring it
REGISTRY WARNING: field_t_tend_perturb: field_t_tend_perturb_b is not a variable or number; ignoring it
REGISTRY WARNING: field_t_tend_perturb: field_t_tend_perturb_bt is not a variable or number; ignoring it
ADVISORY: RSL_LITE version of gen_comms is linked in with registry program.

real    0m0.667s
user    0m0.320s
sys     0m0.378s

catastrophic error: **Internal compiler error: segmentation violation signal raised** 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.
compilation aborted for module_bl_temf.f90 (code 1)

real    0m1.313s
user    0m0.966s
sys     0m0.383s
make[3]: [module_bl_temf.o] Error 1 (ignored)

#######################################################################################################################

I am using , Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.2.144 Build 20140120.... does anyone have any idea then do let me know. In addition, I am using WRF V3.9. If any suggestions by anyone, it will be highly appreciated. I have tried bunch of NETCDF v4.4.1.1/ NETCDF 4.4.1 libraries, no luck.  

Hi All,

While linking with mpif90, I met the following error:

 [....omitted other shell message that means that files .o were successfully created.... ]

ar -r comes_htc.a A11.o   ABFOR5.o   ACC3.o   AUTOGEN.o   BCOND.o   BFLUX5_new.o   BMMFRONTbaseFINAL.o   C60_franek.o   C60maecenas_nottc.o   C90.o   CASTEM.o   Cor1.o   CRC.o   DAMAGE.o   DERIV.o   DERIVtriang.o   ERSTOP.o   FIXINT.o   fluxext.o   FORMBE.o   FORMDE.o   FPAR.o   GAUSSL.o   GAUSSP.o   HMTRA5.o   ICOND.o   INOUT.o   LOCEPSEQ.o   MATPROP.o   MYALLOC.o   MYOPEN.o   MYTIME.o   NONLOC.o   PERM.o   PRMEFF.o   promat.o   PRVAP.o   READCNTL.o   READINPUT.o   RHSCAL.o   RPC.o   SATBGM.o   SATDER.o   SATUR_A.o   SATUR_B.o   SATUR_C.o   SFR.o   SFRtriang.o   SIEP.o   SIGHIS.o   smoothing.o   STORAGEBIN.o   TEMHIS.o   TLOOP.o   USERMAT.o   VARCA2S.o   WATPROP.o   fems_interface.o   FINDLOCAL.o   PARALLEL.o comate.o   comdam.o   comesh.o   comfems.o   comfron.o   comgdl.o   comm1nl.o   comphys.o   comsiep.o   control.o   ctimdis.o kdtree.o findloc.o cbridge.o
/opt/openmpi/bin/mpif90 -cxxlib comes_htc.a -m64 -W1 -lm -openmp -L/opt/intel/mkl/lib/intel64 -mkl -L/usr/include/metis -lmetis -L/opt/gidpost/source -lgidpost -L/opt/fems/parallel64/lib -lfems -lperfm -L/opt/fems/parallel64/lib -lfems -lperfm -o comes_htc_bin.exe
/opt/intel/composer_xe_2015.3.187/compiler/lib/intel64/for_main.o: In function `main':
for_main.c:(.text+0x2a): undefined reference to `MAIN__'
make: *** [comes_htc] Error 1

My project is a mix of c and fortran files, but the main file is HMTRA.f90 (a fortran 90 file).

I've attached the Makefile and Makefile.inc that contains all the rule for compilation and linking. The error stated above comes on the linking phase. I've reported more than Error row because you can find which rule of Makefile have caused the Error.

I am almost desperate now. Any suggestion is appreciated. Thank you very much!

I know the Windows version of the update is now compatible with Microsoft Visual Studio 2017, but I was wondering if the Mac version of the update is compatible with the newly released Mac Visual Studio 2017 as well.

Thanks