Hello,

I just upgraded my Linux compiler suite to 17.0 (from the latest 16.xx), and tried to recompile VASP (Fortran+MPI). Now I am getting the error message shown in the subject. I did compile the complete source code. Any idea what's wrong? I tried Open MPI as well as MPICH (recompiled with the new Intel suite for good measure). Here is the complete message:

constrmag.f90:(.text+0x4780): undefined reference to `for_realloc_lhs'

Given that VASP is one of the most heavily used HPC codes, I suspect I'm not the first to run into this problem.

Any ideas?

Thanks in advance,

  Herbert

A new version of Xcode is now available, but based on previous painful experience I do not want to upgrade until I am sure it works with the Intel Fortran compiler. Which version(s) of Xcode is compatible with the new 2017 compiler? Thanks!
 

Makefile

FC = ifort
FCFLAGS= -O0 -debug -traceback -check -ftrapuv

TARGETS= clean birrp

OBJSOC= strlen.f diagnostic.f math.f rtpss.f zlinpack.f coherence.f fft.f rarfilt.f utils.f dataft.f filter.f response.f weight.f  birrp.f
all:  $(TARGETS)    

clean:$
        rm -f *.o *.mod
        rm -f birrp
        
birrp:$(OBJSOC)
        $(FC) $(FCFLAGS) -o $@ $(OBJSOC)

# General compile rules

.SUFFIXES: .f .o

.f .o:    
    $(FC) $(FCFLAGS) -c -o $@ $<

I compile the code

./birrp < n128.in
 select the input level (0=basic,1=advanced): input the number of output time series: input the number of input time series: select tbw for prolate data window (1 to 4): input the data sample interval: input the initial section length and maximum number of sections:  table of output periods by section length
   125.0000       83.33334    
   62.50000       41.66667    
   31.25000       20.83333    
   15.62500       10.41667    
   7.812500       5.208333    
   3.906250       2.604167    
   1.953125       1.302083    
  0.9765625      0.6510417    
 are these values acceptable (y or n)? input the robustness and leverage parameters (0 and >0.99 are recommended): input the 2nd stage coherence threshold: input the output filename root: input the output level (-3 to 3): input the number of data pieces: input the length of the ar filter (0 for none, <0 for filename): select the file mode (0=separate ascii files, 1=separate binary files 2=all component ascii files 3=ts ascii file: select the input mode (0=by points, 1=by date/time): input the number of points to read: input the number of filter parameters (<0 for filename): input the data filename: input the number of points to skip: input the number of filter parameters (<0 for filename): input the data filename: input the number of points to skip: input the number of filter parameters (<0 for filename): input the filter filename: input the data filename: input the number of points to skip: input the number of filter parameters (<0 for filename): input the filter filename: input the data filename: input the number of points to skip: input the number of filter parameters (<0 for filename): input the filter filename: input the data filename: input the number of points to skip: input the number of filter parameters (<0 for filename): input the filter filename: input the data filename: input the number of points to skip:forrtl: error (182): floating invalid - possible uninitialized real/complex variable.
Image              PC                Routine            Line        Source             
birrp              0000000000656D55  Unknown               Unknown  Unknown
birrp              0000000000654977  Unknown               Unknown  Unknown
birrp              00000000006077D4  Unknown               Unknown  Unknown
birrp              00000000006075E6  Unknown               Unknown  Unknown
birrp              00000000005BF7F6  Unknown               Unknown  Unknown
birrp              00000000005C30B7  Unknown               Unknown  Unknown
libpthread.so.0    00007FD7D61433D0  Unknown               Unknown  Unknown
birrp              0000000000431396  xmedian_                 2078  math.f
birrp              000000000056B85A  MAIN__                    782  birrp.f
birrp              000000000040292E  Unknown               Unknown  Unknown
libc.so.6          00007FD7D5B85830  Unknown               Unknown  Unknown
birrp              0000000000402829  Unknown               Unknown  Unknown
Aborted (core dumped)

I am attaching the folder.Downloadb.tar.gz

I may have found a compiler bug on Linux, for ifort version 17.0.0 on a Debian 'testing' distribution (uname -a: Linux e5470 4.6.0-1-amd64 #1 SMP Debian 4.6.4-1 (2016-07-18) x86_64 GNU/Linux).

The following Fortran code snippet hangs indefinitely within the loop, with CPU at 100%, if compiled with optimization options -O2 -xHost. It works with a previous ifort release; with gfortran; or if the inner loop 'dot_product' is rewritten term by term, as in the listing below.

subroutine k2r_foldinto_WScell(kvec_conventional,nplanes,bzplanes_array,already_inside_before_folding, && kvec_folded)
  implicit none integer,parameter :: ndimens=3
  real(kind(0.d0)),intent(IN) :: kvec_conventional(ndimens)
  integer,intent(IN) :: nplanes
  real(kind(0.d0)),intent(IN) :: bzplanes_array(ndimens+1,nplanes) ! Indexed in: xyz d/2, iplane.
  logical,intent(OUT) :: already_inside_before_folding

  real(kind(0.d0)) kvec_folded(ndimens), & ! Indexed in: xyz.& kvec_relative(ndimens), && bz_distance_squared, max_bz_distance_squared
  integer iplane,closest_bz !, idimen

  already_inside_before_folding = .true.
  kvec_folded(1:ndimens) = kvec_conventional(1:ndimens) ! Assume initially that no folding is needed.
234 continue
  max_bz_distance_squared = dot_product( kvec_folded, kvec_folded ) ! Get the search started: distance from Gamma.

  closest_bz = 0 ! Initial trial assumption that the point is closest to the BZ instance around Gamma, conventionally labeled as 0.
  do iplane=1,nplanes
     kvec_relative(1:ndimens) = kvec_folded(1:ndimens) - bzplanes_array(1:ndimens,iplane) ! Intel ifort 17.0.0 bug with -O2 and -mavx:
   ! bz_distance_squared = dot_product( kvec_relative,kvec_relative )
   ! Workaround:
    bz_distance_squared = kvec_relative(1)*kvec_relative(1) + &&                   kvec_relative(2)*kvec_relative(2) + &&                   kvec_relative(3)*kvec_relative(3)
      if( bz_distance_squared.lt.max_bz_distance_squared ) then
        max_bz_distance_squared = bz_distance_squared
        closest_bz = iplane
      endif
    enddo ! iplane
    if( closest_bz.gt.0 ) then
      kvec_folded(1:ndimens) = kvec_folded(1:3) - bzplanes_array(1:ndimens,closest_bz)
      already_inside_before_folding = .false.
      goto 234
    endif
end subroutine k2r_foldinto_WScell

Thanks for any possible confirmation/feedback,

--

Alberto. 

Hi

After I update my mac os from 10.10 to 10.11 xcode does not recognize intel fortran compiler . I did some modification which was changing the address of compiler manually to intel fortran compiler installed directory in ifort plugins file which was in :

/Library/Application Support/Developer/6.4/Xcode/Plug-ins/IFORT 15.0 Compiler.xcplugin

my xcode version was 6.4 and intel compiler was 2015 update 2 . everything was fine (except debugger when using module or allocatable variable ) . again I updated my mac to Sierra in last week and Xcode 6.4 was not compatible with this version of mac so I updated my xcode to 8.0 . again xcode did not recognized my intel fortran compiler . after some searching web I find out I have to create a Shared folder and put the plugin inside it like :

/Library/Application Support/Developer/Shared/Xcode/Plug-ins/IFORT 15.0 Compiler.xcplugin

Now xcode recognize my intel fortran compiler but when i use build ther is a error ( intel fortran works in terminal and I can compile my fortran file inside terminal using ifort myfile)

ipo: warning #11016: Warning unknown option -no_deduplicate

ld: file not found: /Users/Alfred/Library/Developer/Xcode/DerivedData/main-cmdzktxskmwirzcgutlzgyrrqxgd/Build/Intermediates/main.build/Debug/main.build/Objects-normal/x86_64/main_lto.o

Command /opt/intel/composer_xe_2015.2.132/bin/intel64/ifort failed with exit code 1

I Updated the DVTPlugInCompatibilityUUID in info.plist with xcode 8 UUID but still get this error . 

Hi all, i'm trying to build netcdf-4.4.1. with intel parallel studio xe 2016 update 3 in Red Hat Enterprise Linux Server 7.2, following this url:

https://software.intel.com/en-us/articles/performance-tools-for-software-developers-building-netcdf-with-the-intel-compilers

It presents the following error when running make:

libtool: compile:  icc -DHAVE_CONFIG_H -I. -I.. -I../include -I/opt/hdf5/include -I/opt/curl/include -O3 -xHost -ip -no-prec-div -static-intel -MT libnetcdf4_la-nc4file.lo -MD -MP -MF .deps/libnetcdf4_la-nc4file.Tpo -c nc4file.c  -fPIC -DPIC -o .libs/libnetcdf4_la-nc4file.o
nc4file.c(2322): error: identifier "H5LT_FILE_IMAGE_DONT_COPY" is undefined
                        H5LT_FILE_IMAGE_DONT_COPY|H5LT_FILE_IMAGE_DONT_RELEASE
                        ^

nc4file.c(2322): error: identifier "H5LT_FILE_IMAGE_DONT_RELEASE" is undefined
                        H5LT_FILE_IMAGE_DONT_COPY|H5LT_FILE_IMAGE_DONT_RELEASE
                                                  ^

compilation aborted for nc4file.c (code 2)
make[2]: *** [libnetcdf4_la-nc4file.lo] Error 1
make[2]: Leaving directory `/root/libs/netcdf-4.4.1/libsrc4'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/libs/netcdf-4.4.1'
make: *** [all] Error 2
^C[1]+  Exit 2                  make &>make.log

Any ideas to fix this?

Thanks in advance

I am running into an issue with compiling code with ifort 16 which worked with previous versions of ifort and works with e.g. gfortran. The code in question is here:

https://gist.github.com/astrofrog/47ee268a8e71dc6760ec3e0e1b4beca7

and I have put a tar file for convenience here:

https://dl.dropboxusercontent.com/u/3770121/ifort_issue.tgz

I have tried to boil it down to as simple a code as possible. When compiling using make.sh, I get the following error:

grid_geometry_cartesian_3d.f90(11): error #6457: This derived type name has not been declared.   [GRID_CELL]

  type(grid_cell) :: cell

-------^

compilation aborted for grid_geometry_cartesian_3d.f90 (code 1)

However, if I rename one of the 'equal' functions, everything works as expected. Is this a bug in ifort?

Thanks!

Tom

Basically I have a derived type that represents a cell and I wanted it to have pointers to its neighbours. This is the data structure I would like to have:

module XYZ
...
    type pointerToCellContainer
        type( cellType ), pointer :: p
    end type pointerToCellContainer
...
    type cellType(nDOFs, nEQs)
        integer(itp), len :: nDOFs
        integer(isp), len :: nEQs
        ...
        type( pointerToCellContainer ), dimension(2) :: nb
        ...
    contains
        ...
    end type cellType
...
end module XYZ

While the module compiles fine when i try to atribute a cell to the pointer in the main program the compiler returns the error

main.f90(130): error #6795: The target must be of the same type and kind type parameters as the pointer.   [P]
        mesh%cellList(cID)%nb(1)%p => mesh%cellList(cID-1)
---------------------------------^
main.f90(131): error #6795: The target must be of the same type and kind type parameters as the pointer.   [P]
        mesh%cellList(cID)%nb(2)%p => mesh%cellList(cID+1)
---------------------------------^

My main doubt is if I'm actually trying to do something not allowed by the 2008 standard or if it's just a syntax problem. I'm doing this code to teach myself some features that I never got to use in production code (mainly parameterized derived types, submodules and other OO features) so workarounds and alternative design solution are also welcome.

Hi all, after build netcdf 4.4.1, i'm trying to build netcdf-fortran 4.4.4 (netcdf 4.4.1 is ok), with intel parallel studio xe 2016 update3, in rhel Enterprise Server 7.2.

'configure' and 'make' are ok, but 'make check' stops with:

ftst_rengrps.F(49): error #6404: This name does not have a type, and must have an explicit type.   [NF_NETCDF4]
      call check(nf_create(FILE_NAME, NF_NETCDF4, ncid))
--------------------------------------^
compilation aborted for ftst_rengrps.F (code 1)
make[2]: *** [ftst_rengrps.o] Error 1
make[2]: Leaving directory `/root/libs/netcdf-fortran-4.4.4/nf_test'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/root/libs/netcdf-fortran-4.4.4/nf_test'
make: *** [check-recursive] Error 1
^C
[1]+  Exit 2                  make check &>check.log

Asked netcdf-support, and here is the answer:

Hello,

Unfortunately I'm not familiar with intel parallel studio; it clearly looks like a compiler issue, but I don't have an environment where I can try to recreate this problem.

The Intel documentation provides some instructions for compiling netCDF-Fortran, found at the following address:

* https://software.intel.com/en-us/articles/performance-tools-for-software-developers-building-netcdf-with-the-intel-compilers

It may be able to provide some additional information that I lack.

I'm sorry I can't provide a more immediately useful or applicable answer, but hopefully this information will be helpful!

Have a great day,

-Ward

All log files are atthached

I´m stuck at this point and I hope your help make my day ;)

Thanks!!

Hi all,

Recently our university has upgraded from ifort 12 to ifort 15, and now if I compile code with "-mcmodel=medium -shared-intel", it no longer runs on our cluster (though it does if I revert to the ifort 12 compiler).

For example, I created the following simple test file:

program progtest
implicit none

integer i

do i = 1, 10
  print*, i
enddo

end

If I compile it with "ifort -O2 -C progtest.F90 -o progtest" and run it on the cluster, it works. If I compile it with "ifort -O2 -C -mcmodel=medium -shared-intel progtest.F90 -o progtest" then I get the following error:

./progtest: symbol lookup error: ./progtest: undefined symbol: __intel_new_feature_proc_init

Obviously the actual code I need to run is more complicated, hence the need for the mcmodel=medium, but I'm stumped why it doesn't work when compiling with ifort version 15.0.0.

Can anyone offer any help?

Many thanks,

Liam

Hello,

I am facing an issue with Intel 16.0.3.210.

The issue is that when we want to have 1D pointer to a 3D array that is contained into a type, the compiler is reporting that the data target must be simply contiguous or of rank one.

However, when the array is not contain into a type, it does work. The issue is also not present in Intel 15.x or 14.x series.

Any ideas ?

Thank you

program test

  implicit none


 type :: t_con
 real, allocatable :: array(:,:,:)
 end type

 integer, parameter :: N=30
 real, allocatable, target :: a(:,:,:)
 real, pointer :: p(:)
 real, pointer :: p1(:)
 type(t_con), target  :: t_a


 allocate(a(N,N,N))
 allocate(t_a%array(N,N,N))

 a=0.0
 t_a%array = 0.0

 p(1:30) => a(:,:,3)

 p(2) = 500.0

 print *, p(2), a(2,1,3)


 p1(1:30) => t_a%array(:,:,3)

 p1(2) = 200.0
 print *, p1(2), t_a%array(2,1,3)

 nullify(p)
 deallocate(a)
 deallocate(t_a%array)



end program test

Doctor Fortran in "Thirty-Eight"

Dear intel team,

I am part of a larger group of developers that work on a quantum chemistry code  written in Fortran that was founded a few decades ago. We made now an initiative to identify some "hidden bugs" in the code for several reasons. As the code grew over the years people started coding using some Fortran constructs that are considered today as bad practice because they result in side effects that are error prone and hard to debug. In particular, we tried to identify bugs related to uninitialized variables, which I tried to identify with -ftrapuv available in the ifort 15.0.2 compiler for a Linux cluster. Old parts of the code, however, frequently employ variables with the SAVE attribute. There are several subroutines where those variables are initialized if a certain flag is given and incremented by some value otherwise. In the latter, the compiler is not  able to identify that initialization was correctly performed in an previous (initial) subroutine call. Unfortunately, there are too many variables with the SAVE attribute to simply change the code. There is another social aspect that some members of the community refuse such a re-writing. Is there a solution to that problem or any plans to provide a mechanism to detect uninitialized save variables. When using the gfortran compiler with the -fnit-(real/integer/logical)=something_silly flag the program does not abort when variables with save attributes are accessed.

Kind regards,

Ben

I compiled this code with ifort 17.0 and it gives segfault.

https://gist.github.com/appleparan/be9eb47be87f5440c8008118492b4f10

It works with gfortran 6.2 but ifort fails. Is this ifort's bug?

This is traceback

#0  0x0000003a06a7a96c in free () from /lib64/libc.so.6
#1  0x0000000000563e7b in for_dealloc_allocatable ()
#2  0x00000000004057ca in MAIN__ ()
#3  0x0000000000403ade in main ()
#4  0x0000003a06a1ecdd in __libc_start_main () from /lib64/libc.so.6
#5  0x0000000000403969 in _start ()

gnu libc version status

ldd (GNU libc) 2.12
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

ifort version status

ifort (IFORT) 17.0.0 20160721
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

FFTW version 3.3.5 compiled with --enable-avx --enable-openmp

I have this issue with ifort 12.1 as well as 17.0

I upgraded my Intel C++ and Fortran compilers last week (September 26-30, 2016) to the Intel 17 versions 17.0.0 and immediately ran into what appears to be a compiler bug due to improper inlining of code. My  code did not have this problem with 16.0.3, which I had previously been using. I have not yet been able to get a simple reproducer, so I can only supply the symptoms. My code fails in what appears to be a two or three level inlined code. When it tries to do a sufficiently deep inline expansion I get a run time segmentation violation. The author of this section of the code (which is a huge multideveloper project) is trying to do very aggressive inlining, and this same code has been used intensively since Intel version 15. I experimented with different compilation options and discovered that using the arguments "-no-ip -fno-inline" to replace the argument "-ip" for ifort enables my code to again run properly. I tracked down the location of the offending subroutine, which was quite simply a single loop and when I removed this as a sub-subroutine (i.e. a contains routine inside another subroutine) and simply added the loop to replace the original call, then the code will also again run. This is the basis for my suspicion that the problem is with the compiler doing something wrong when it tries to inline this code. My only guess is that some memory access was messed up by the inlining, perhaps a stack overflow. If I can create a simple reproducer I will supply it to this forum, but for now I just wanted to get this bug documented somewhere.

All,

I'm hoping you can help with this. I just tried this simple program:

program test
   implicit none

   integer :: estat, cstat
   character(len=255) :: cmsg

   estat = -999
   cstat = -999
   cmsg  = "notfilled"

   call execute_command_line("/bin/cp ~/yayay ~/alskalkd", &
      exitstat=estat, cmdstat=cstat, cmdmsg=cmsg)
   write (*,*) 'estat: ', estat
   write (*,*) 'cstat: ', cstat
   write (*,*) "cmsg:  ", trim(cmsg)

end program test

Nothing too fancy or anything. I do not have a file called "yayay" in my home, so I expected to see cmdmsg to have something and yet:

(276) $ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.0.098 Build 20160721
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

(277) $ ifort test.F90 && ./a.out
/bin/cp: cannot stat ‘/home/mathomp4/yayay’: No such file or directory
 estat:            1
 cstat:            0
 cmsg:  notfilled

So, we see that cp failed (as it should) but cmdmsg was never changed. I suppose I'm wondering, given the standard:

CMDMSG (optional) shall be a default character scalar. It is an INTENT (INOUT) argument. If an error condi-
tion occurs, it is assigned a processor-dependent explanatory message. Otherwise, it is unchanged.

have I encountered the dreaded "processor-dependent" result of nothing? EXITSTAT seems to have been set to non-zero (which is the return status of the cp call), but...no cmdmsg.

Hello All, I have been facing and issue with respect to Intel Fortran complier while compiling a program called TIEGCM. Which is an open source application.

/opt/intel17/compilers_and_libraries_2017.0.098/linux/mpi/intel64/bin/mpif90 -fc=ifort -r8 -heap-arrays -I. -I/opt/tiegcm2.0/tiegcm_trunk/src -I/usr/local/netcdf-4.1.3/include -I/opt/esmf/esmf/DEFAULTINSTALLDIR/mod/modO/Linux.intel.64.mpiuni.default -I/opt/esmf/esmf/DEFAULTINSTALLDIR/include  -O3  -DLINUX  -DMPI  -c -o output.o /opt/tiegcm2.0/tiegcm_trunk/src/output.F
ifort: command line remark #10411: option '-openmp' is deprecated and will be removed in a future release. Please use the replacement option '-qopenmp'
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(437): error #6633: The type of the actual argument differs from the type of the dummy argument.   [RHO]
     |  diags(ix)%units,rho,diags(ix)%levels,lev0,lev1,
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(459): error #6633: The type of the actual argument differs from the type of the dummy argument.   [QJI_TN]
     |  diags(ix)%units,qji_tn(lev0:lev1-1,lon0:lon1),diags(ix)%levels,
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(494): error #6633: The type of the actual argument differs from the type of the dummy argument.   [TEC]
     |  diags(ix)%units,tec(:),'lon',lon0,lon1,'lat',lat,lat,0)
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(520): error #6633: The type of the actual argument differs from the type of the dummy argument.   [UI]
     |    diags(ix)%units, ui(:,:,lat),diags(ix)%levels,
---------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(548): error #6633: The type of the actual argument differs from the type of the dummy argument.   [VI]
     |    diags(ix)%units, vi(:,:,lat),diags(ix)%levels,
---------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(576): error #6633: The type of the actual argument differs from the type of the dummy argument.   [WI]
     |    diags(ix)%units, wi(:,:,lat),diags(ix)%levels,
---------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(599): error #6633: The type of the actual argument differs from the type of the dummy argument.   [TOTAL_HEAT]
     |  diags(ix)%units,total_heat(lev0:lev1-1,:),diags(ix)%levels,
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(621): error #6633: The type of the actual argument differs from the type of the dummy argument.   [CO2_COOL]
     |  diags(ix)%units,co2_cool,diags(ix)%levels,lev0,lev1,
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(643): error #6633: The type of the actual argument differs from the type of the dummy argument.   [NO_COOL]
     |  diags(ix)%units,no_cool,diags(ix)%levels,lev0,lev1,
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(666): error #6633: The type of the actual argument differs from the type of the dummy argument.   [SIGMAPED]
     |  diags(ix)%units,sigmaped(lev0:lev1-1,lon0:lon1),
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(689): error #6633: The type of the actual argument differs from the type of the dummy argument.   [SIGMAHAL]
     |  diags(ix)%units,sigmahal(lev0:lev1-1,lon0:lon1),
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(711): error #6633: The type of the actual argument differs from the type of the dummy argument.   [LAMDAPED]
     |  diags(ix)%units,lamdaped(lev0:lev1-1,lon0:lon1),
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(733): error #6633: The type of the actual argument differs from the type of the dummy argument.   [LAMDAHAL]
     |  diags(ix)%units,lamdahal(lev0:lev1-1,lon0:lon1),
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(759): error #6633: The type of the actual argument differs from the type of the dummy argument.
     |    diags(iex)%units,exyz*100.,diags(iex)%levels,lev0,lev1,'lon',
-------------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(763): error #6633: The type of the actual argument differs from the type of the dummy argument.
     |    diags(iey)%units,exyz*100.,diags(iey)%levels,lev0,lev1,'lon',
-------------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(767): error #6633: The type of the actual argument differs from the type of the dummy argument.
     |    diags(iez)%units,exyz*100.,diags(iez)%levels,lev0,lev1,'lon',
-------------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(792): error #6633: The type of the actual argument differs from the type of the dummy argument.   [BXYZ]
     |    diags(ibx)%units,bxyz,'lon',lon0,lon1,'lat',lat,lat,0)
---------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(795): error #6633: The type of the actual argument differs from the type of the dummy argument.   [BXYZ]
     |    diags(iby)%units,bxyz,'lon',lon0,lon1,'lat',lat,lat,0)

It goes on ...

Kindly Help !!

I

Hello,

I have run some tests using the trial version of the Intel Parallel Studio XE 2017 and I am considering purchasing a licence.

However, before I do I have a few questions relating to which edition I should purchase.

I suspect that the Composer Edition is all that I will require, but I noticed that the Processional Edition has the following extra components, Intel Advisor, Intel Inspector and Intel Vtune Amplifier XE3. 

Can you confirm that confirm that with the Composer Edition I can still use optimatization flags like -xCORE_AVX2 and -ipo, as I have used these options in my testing.

Thanks,

Simon

Hi, i tried to install parallel studio xe 2016 (file is l_mpi_p_5.1.3.223) for fortran compiler to linux opensuse .  I installed it by install.sh then i sourced it to .bashrc as "source /opt/intel/compilers_and_libraries_2016/linux/bin/compilervars.sh intel64" but ifort doesnt work.

when i try :

/opt/intel/compilers_and_libraries_2016/linux/bin # ./compilervars.sh

the error is :

"compilervars.sh [-arch] <arch> [-platform <platform>]

  <arch> must be one of the following:
      ia32           : Set up for IA-32 target.
      intel64        : Set up for Intel(R)64 target.
  <platform> must be of the following:
      linux          : Set to Linux target.(default)
      android        : Set to Android target.

If the arguments to the sourced script are ignored (consult docs
for your shell) the alternative way to specify target is environment
variables COMPILERVARS_ARCHITECTURE to pass <arch> to the script
and COMPILERVARS_PLATFORM to pass <platform>
./compilervars.sh: line 73: return: can only `return' from a function or sourced script

ERROR: architecture is not defined. Accepted values: ia32, intel64, mic"

what should i do? help me please!

There is no architecture file as intel 64 at " /opt/intel/compilers_and_libraries_2016/linux/bin" folder.

Dear all,

I have the following type variable:

  TYPE::tMACROCELLNODE
   INTEGER                                        :: nElem
   INTEGER                                        :: AA
   INTEGER                                        :: IDnode
   INTEGER                                        :: IDmCell
   REAL(KIND=8),ALLOCATABLE,DIMENSION(:)          :: WFX
   REAL(KIND=8),ALLOCATABLE,DIMENSION(:)          :: WFY
   !
   REAL(KIND=8),ALLOCATABLE,DIMENSION(:)          :: WFtime
   REAL(KIND=8),ALLOCATABLE,DIMENSION(:)          :: WFpdf
   !
   REAL                                           :: qs
  ENDTYPE

During my program, I allocate it as:

first of all:

ALLOCATE(MACROCELLNODE(npairs))

and then

DO i.....

       ALLOCATE(MACROCELLNODE(i)%WFX(n))
...
...

My question is:

Is it possible deallocate only one field of it?

for example:

i=10
DEALLOCATE(MACRCELLNODE(i)%WFX(:))

Thank to all of you

Diego