When I installed 2019 Update 4 (cluster version) on a CentOS box, I_MPI_ROOT gets set to /opt/intel/intelpython3 after running 

> /opt/intel/parallel_studio_xe_2019/psxevars.sh intel64

which causes library and modules errors when compiling Fortran routines. 

Shouldn't I_MPI_ROOT be set to /opt/intel/compilers_and_libraries/linux/mpi/ ?  

Consider the code below, which has nested derived-types with default initialisation in it.

module mod

implicit none
private

type, public :: a
   integer :: i = 5
end type a

type, public :: b
   type(a) :: n
end type b

interface b
   module procedure create_b
end interface b

contains

   function create_b() result(x)
      type(b) :: x
      x%n = a()
   end function create_b

end module mod


program definit

use mod
implicit none

type(b) :: u

print *, same_type_as(u, b())

end program definit

I have several issues with the code and ifort (beta release):

(1) Without the constructor create_b and "interface b", ifort complains that

definit.f90(25): error #8212: Omitted field is not initialized. Field initialization missing:   [N]
print *, same_type_as(u, b())
^

I have reported this as a bug, but was told that this is not legal fortran. But I think default initialisation in nested derived-types is pretty clear (at least if I read Metcalf "7.5.4 Default initialisation of components", edition from 2011, correctly). Please correct me if I am wrong.

(2) As a work-around I tried to add explicit default initialisation

type, public :: b
   type(a) :: n = a()
end type b

which works fine. And I also tried adding create_b (where I explicitly need to initialise component n with x%n = a(), probably the same problem mentioned in (1)). But now I get

definit.f90(36): error #8250: The argument to the SAME_TYPE_AS intrinsic function must be an object of extensible type.
print *, same_type_as(u, b())

Why are u and b() (without the create_b interface) accepted, but not type(b) as a function result of create_b? In general type(b) is an extensible type and all three arguments should be accepted by same_type_as, right?

With ifort 19.x I get a segfault when I pass a temporary array of a certain length to an internal procedure. This works fine with gfortran and pgf90.  Is this a bug in the compiler?

Hello

I have a piece of code where I got an array which is part of a declared type (DT) that all of a sudden changing value. I have protected the whole DT so nothing can change it out of its module file. By making a simple change this odd behaviour does not occur.

type father 


real, allocatable :: odd_array(:)

type(son1),allocatable :: s1 
type(son2),allocatable :: s2
type(son3),allocatable :: s3 
end type 

type son1 

real, allocatable :: ar1(:)
end type 

type son2 

real, allocatable :: ar2(:)
end type 

type son3 

real, allocatable :: ar3(:)
end type 


interface son1
module procedure son1_constructor
end interface 
type(father), allocatable , protected :: test(:)


(...)

function son1_constructor(size_) 
implicit none 
integer, intent(in) :: size_
type(son1) :: son1_constructor

allocate(son1_constructor% ar1(size_) )
end function

(...)

function father_constructor(size_1, size_2,size_3,size_odd) 
implicit none 
integer, intent(in) :: size_,size_1, size_2,size_3,size_odd
type(father) :: father_constructor

allocate(father% son1)
allocate(father% son2)
allocate(father% son3)
allocate(father% odd_array(odd)  )   ! this array's value change randomly (memory corrupted?)
father% son1 = son1_constructor(size_1)
father% son2 = son1_constructor(size_2)
father% son3 = son1_constructor(size_3)
end function
subroutine SETUP 
 
(...)
allocate(test(1000)) 

test(1) = FATHER_CONSTRUCTOR(10,12,15,100)
(...) ! for test(2) etc.
end subroutine 

As you will note the array % odd_array seems to have memory corruption. If I instead DO NOT allocate within the 'father_constructor' but rather doing it in the subroutine which is calling  the constructor all will be good.

Also if I change the father_constructor to a subroutine then everything also works.

So I found the solution, HOWEVER, why is this happening?

I would really appreciate if someone could spot an obvious mistake

I have found a bug in a large program where a subroutine was written as:

program main
  implicit none

  real, dimension(6) :: x
  call f(x, 7)
  write (*,*) x
contains
  subroutine f(x, n)
    integer :: n
    real, dimension(n) :: x

    integer :: i

    do i = 1, n
      x(i) = 0.0
    end do
  end subroutine f
end program main

This program runs fine with ifort and bounds checking even though the code is obviously buggy. Is there an option to catch those kind of bugs? Obviously, I need an option that checks this kind of bugs at run-time where the dimension of the arrays is not statically known as here.

Hi,

i was chasing data race conditions in an omp environment and found that having a derived type with allocatable components the culprit. According to google there was once a problem but I wonder whether it is still virulent.

Here is an example code:

Module rrr
  Type :: aaa
    real(kind=8), allocatable :: b(:,:)
  end type aaa
contains
  Subroutine Subrrr(a)
    real(kind=8), intent(inout) :: a(:,:)
    write(*,*) loc(a)
  end Subroutine Subrrr
  Subroutine Subzzz(a)
    type(aaa), intent(inout) :: a(:)
    integer :: i
    do i=1,size(a)
      write(*,*) i,loc(a(i)%b)
    end do
  end Subroutine Subzzz
end Module rrr
Program test
  use rrr, only: subrrr, aaa, subzzz
  real(kind=8), allocatable :: x(:,:)
  integer :: i
  type(aaa), allocatable :: y(:)
  allocate(y(1))
  do i=1,size(y)
    allocate(y(i)%b(20,20),source=0.0D0)
    write(*,*) i,loc(y(i)%b)
  end do
  write(*,*) "@@@@@@@@@@@@@@@@@@@"
  !$omp parallel do firstprivate(y)
  Do i=1,10
    call subzzz(y)
  end Do
  !$omp end parallel do
  write(*,*) "@@@@@@@@@@@@@@@@@@@"
  allocate(x(20,20),source=0.0D0)
  write(*,*) loc(x)
  !$omp parallel do firstprivate(x)
  Do i=1,10
    call subrrr(x)
  end Do
  !$omp end parallel do
end Program test

When compiled with ifort 17.08 or 19.04 and the -qopenmp flag only the ouptut is

          1        23209329389632
 @@@@@@@@@@@@@@@@@@@
           1        23209329389632
           1        23209329389632
           1        23209329389632
           1        23209329389632
           1        23209329389632
           1        23209329389632
           1        23209329389632
           1        23209329389632
           1        23209329389632
           1        23209329389632
 @@@@@@@@@@@@@@@@@@@
        23209329385600
       140720494867472
        23194232672272
        23202940038928
        23207230320272
        23192018079760
        23200742231824
        23209327480336
        23205037198992
        23196430479248
        23198527639440

when compiled with "gfortran -fopenmp" the output is:

          1       94311007887248
 @@@@@@@@@@@@@@@@@@@
           1       94311007930896
           1       22394831899520
           1       22394764790656
           1       22394764791344
           1       94311007932272
           1       22394496355200
           1       22394630572928
           1       22394362137472
           1       22393422613376
           1       22394295028608
 @@@@@@@@@@@@@@@@@@@
       94311007932272
       22394831900208
       22394764791344
       22394362137472
       22394764791344
       94311007935488
       22394295028608
       22394496355200
       94311007935488
       22393422613376
       22394630572928

So it looks as if when compiled with ifort, the array y(i)%b is not copied, where as when using gfortran it is.

Any idea?

Cheers

Hi there,

I am wondering whether it is possible to setup the OMP environment, namely, OMP_PLACES and OMP_PROC_BIND by the executable at the start of the program, so NOT via bashrc etc. The reason is that users may forget to or not be aware of how to do the proper bashrc settings.

I found an old thread where people used

success = SETENVQQ("OMP_PLACES=cores")

form inside the executable, which is what I want too, but I am wondering whether that has any effect at all once the program runs.

I tried this:

Program Test
  !$ use omp_lib
  USE IFPORT, only: SETENVQQ
  implicit none
  character(len=50) :: val
  integer :: istat
  !$ write(*,*) omp_get_proc_bind()
  call GET_ENVIRONMENT_VARIABLE(name="OMP_PROC_BIND",value=val,Status=istat)
  write(*,*) "OMP_PROC_BIND: ", trim(adjustl(val))
  istat = SETENVQQ("OMP_PROC_BIND=spread")
  call GET_ENVIRONMENT_VARIABLE(name="OMP_PROC_BIND",value=val,Status=istat)
  write(*,*) "OMP_PROC_BIND: ", trim(adjustl(val))
  !$ write(*,*) omp_get_proc_bind()
End Program Test

and the ouput was that:

          0
 OMP_PROC_BIND: 
 OMP_PROC_BIND: spread
           0

which, according to the omp manual, implies that "OMP_PROC_BIND" is still "false" after setting the environment variable.

Any suggestions are highly appreciated.

Thanks

Hi all!

I met a problem when I compiled Noah-MP (a model) using intel fortran (ifort) on linux platform. 

module_NoahMP_hrldas_driver.f(852): error #6633: The type of the actual argument differs from the type of the dummy argument.   [NSOIL]
                   NSOIL,  .false.,                                                   &
-------------------^
module_NoahMP_hrldas_driver.f(852): error #6633: The type of the actual argument differs from the type of the dummy argument.
                   NSOIL,  .false.,                                                   &
---------------------------^
module_NoahMP_hrldas_driver.f(853): error #6633: The type of the actual argument differs from the type of the dummy argument.
                  .true.,runoff_option,                                                   &
------------------^
module_NoahMP_hrldas_driver.f(853): error #6633: The type of the actual argument differs from the type of the dummy argument.   [RUNOFF_OPTION]
                  .true.,runoff_option,                                                   &
-------------------------^
module_NoahMP_hrldas_driver.f(854): error #6633: The type of the actual argument differs from the type of the dummy argument.   [IDS]
                  ids,ide+1, jds,jde+1, kds,kde,                &  ! domain
------------------^
module_NoahMP_hrldas_driver.f(857): error #6633: The type of the actual argument differs from the type of the dummy argument.   [SMOISEQ]
                     ,smoiseq  ,smcwtdxy ,rechxy   ,deeprechxy, areaxy ,dx, dy, msftx, msfty,&
----------------------^
module_NoahMP_hrldas_driver.f(857): error #6633: The type of the actual argument differs from the type of the dummy argument.   [SMCWTDXY]
                     ,smoiseq  ,smcwtdxy ,rechxy   ,deeprechxy, areaxy ,dx, dy, msftx, msfty,&
--------------------------------^
module_NoahMP_hrldas_driver.f(858): error #6633: The type of the actual argument differs from the type of the dummy argument.   [STEPWTD]
                     wtddt    ,stepwtd  ,dtbl  ,qrfsxy ,qspringsxy  ,qslatxy,                  &
-------------------------------^
module_NoahMP_hrldas_driver.f(858): error #6633: The type of the actual argument differs from the type of the dummy argument.   [QRFSXY]
                     wtddt    ,stepwtd  ,dtbl  ,qrfsxy ,qspringsxy  ,qslatxy,                  &
------------------------------------------------^
module_NoahMP_hrldas_driver.f(852): error #6638: An actual argument is an expression or constant; this is not valid since the associated dummy argument has the explicit INTENT(OUT) or INTENT(INOUT) attribute.
                   NSOIL,  .false.,                                                   &
---------------------------^
module_NoahMP_hrldas_driver.f(844): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic.   [T2MBXY]
     CALL NOAHMP_INIT(    LLANDUSE,     SNOW,    SNOWH,   CANWAT,   ISLTYP,   IVGTYP,ISURBAN, &   ! call from WRF phys_init
----------^
module_NoahMP_hrldas_driver.f(844): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic.   [CHSTARXY]
     CALL NOAHMP_INIT(    LLANDUSE,     SNOW,    SNOWH,   CANWAT,   ISLTYP,   IVGTYP,ISURBAN, &   ! call from WRF phys_init
----------^
module_NoahMP_hrldas_driver.f(857): error #6634: The shape matching rules of actual arguments and dummy arguments have been violated.   [SMOISEQ]
                     ,smoiseq  ,smcwtdxy ,rechxy   ,deeprechxy, areaxy ,dx, dy, msftx, msfty,&
----------------------^
module_NoahMP_hrldas_driver.f(857): error #6634: The shape matching rules of actual arguments and dummy arguments have been violated.   [SMCWTDXY]
                     ,smoiseq  ,smcwtdxy ,rechxy   ,deeprechxy, areaxy ,dx, dy, msftx, msfty,&
--------------------------------^
module_NoahMP_hrldas_driver.f(844): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic.   [DEEPRECHXY]
     CALL NOAHMP_INIT(    LLANDUSE,     SNOW,    SNOWH,   CANWAT,   ISLTYP,   IVGTYP,ISURBAN, &   ! call from WRF phys_init
----------^
module_NoahMP_hrldas_driver.f(844): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic.   [AREAXY]
     CALL NOAHMP_INIT(    LLANDUSE,     SNOW,    SNOWH,   CANWAT,   ISLTYP,   IVGTYP,ISURBAN, &   ! call from WRF phys_init
----------^
module_NoahMP_hrldas_driver.f(857): error #6634: The shape matching rules of actual arguments and dummy arguments have been violated.   [MSFTX]
                     ,smoiseq  ,smcwtdxy ,rechxy   ,deeprechxy, areaxy ,dx, dy, msftx, msfty,&
--------------------------------------------------------------------------------^
module_NoahMP_hrldas_driver.f(857): error #6634: The shape matching rules of actual arguments and dummy arguments have been violated.   [MSFTY]
                     ,smoiseq  ,smcwtdxy ,rechxy   ,deeprechxy, areaxy ,dx, dy, msftx, msfty,&
---------------------------------------------------------------------------------------^
module_NoahMP_hrldas_driver.f(844): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic.   [MSFTX]
     CALL NOAHMP_INIT(    LLANDUSE,     SNOW,    SNOWH,   CANWAT,   ISLTYP,   IVGTYP,ISURBAN, &   ! call from WRF phys_init
----------^
module_NoahMP_hrldas_driver.f(844): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic.   [MSFTY]
     CALL NOAHMP_INIT(    LLANDUSE,     SNOW,    SNOWH,   CANWAT,   ISLTYP,   IVGTYP,ISURBAN, &   ! call from WRF phys_init
----------^
module_NoahMP_hrldas_driver.f(858): error #6634: The shape matching rules of actual arguments and dummy arguments have been violated.   [QRFSXY]
                     wtddt    ,stepwtd  ,dtbl  ,qrfsxy ,qspringsxy  ,qslatxy,                  &
------------------------------------------------^
module_NoahMP_hrldas_driver.f(858): error #6634: The shape matching rules of actual arguments and dummy arguments have been violated.   [QSPRINGSXY]
                     wtddt    ,stepwtd  ,dtbl  ,qrfsxy ,qspringsxy  ,qslatxy,                  &
--------------------------------------------------------^
module_NoahMP_hrldas_driver.f(1072): error #6633: The type of the actual argument differs from the type of the dummy argument.   [IDS]
                ids,ide, jds,jde, kds,kde,                      &
----------------^
module_NoahMP_hrldas_driver.f(1072): error #6633: The type of the actual argument differs from the type of the dummy argument.   [IDE]
                ids,ide, jds,jde, kds,kde,                      &
--------------------^
module_NoahMP_hrldas_driver.f(1072): error #6633: The type of the actual argument differs from the type of the dummy argument.   [JDS]
                ids,ide, jds,jde, kds,kde,                      &
-------------------------^
module_NoahMP_hrldas_driver.f(1072): error #6633: The type of the actual argument differs from the type of the dummy argument.   [JDE]
                ids,ide, jds,jde, kds,kde,                      &
-----------------------------^
module_NoahMP_hrldas_driver.f(1072): error #6633: The type of the actual argument differs from the type of the dummy argument.   [KDS]
                ids,ide, jds,jde, kds,kde,                      &
----------------------------------^
module_NoahMP_hrldas_driver.f(1043): error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface.   [ITE]
         CALL noahmplsm(ITIMESTEP,       YR, JULIAN_IN,   COSZEN, XLAT_URB2D, &
--------------^
module_NoahMP_hrldas_driver.f(1043): error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface.   [JTS]
         CALL noahmplsm(ITIMESTEP,       YR, JULIAN_IN,   COSZEN, XLAT_URB2D, &
--------------^
module_NoahMP_hrldas_driver.f(1043): error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface.   [JTE]
         CALL noahmplsm(ITIMESTEP,       YR, JULIAN_IN,   COSZEN, XLAT_URB2D, &
--------------^
module_NoahMP_hrldas_driver.f(1265): catastrophic error: Too many errors, exiting
compilation aborted for module_NoahMP_hrldas_driver.f (code 1)
make[1]: *** [module_NoahMP_hrldas_driver.o] Error 1

I searched many times and checked the type of actual argument and dummy arguments. I did not find the difference between them. So can someone help this?

I attached two files including actual argument and dummy one!

Hello,

I have been trying for quite a few hours now both today and yesterday so I need fairly well explained instructions sorry - this  is my first time downloading coding software.

The instructions for the starting guide (file:///opt/intel/documentation_2019/en/compiler_f/ps2019/get_started_mf.htm)

say to put into the terminal something along the lines of:  ifort my_source_file.f90

How do I create this file? What is a text editor.. is this like TextEdit or Notepad on my Mac or is this something on XTools.

Either way do I create it and where do I save it so the terminal can find that file? 

Thank you so much for your help!

We have a site license for the Linux version of Composer.  Or IT was asked mid-last week for the correct license file and has yet been able to supply one.  While we wait for them to [edit] we are hoping to install an older version so that we can get back to work.  License supplied with the application from the Download Center doesn't seem to work either.  Maybe its not paranoia and the world IS out to get me. -Kirk

I recently installed gdb ( and ifort ( Version 19.0 Build 20190416 ) and have been debugging a large  code that has a lot of Fortran modules. In a sample module named "laser_mod", I am able to examine real variables, e.g.,

(gdb) print laser_mod::omg0
$7 = 0.025125017310528065

However, if I attempt to examine an (truly variable) integer or logical variable, I get the following:

(gdb) print laser_mod::iseed
No symbol "laser_mod::iseed" in current context.

(gdb) print laser_mod::l_mult_pol_emit
No symbol "laser_mod::l_mult_pol_emit" in current context.

If i run nm on the executable, I find reals seem to be "data" whereas integers and logicals has type "S" which according to the man page for "nm" is a symbol not contained in other sections such as data or text or absolute, etc.  (i.e., a "beats me" location ...)

macmini-4265[522]>nm xgingerh | grep omg0
000000010055f750 D _laser_mod_mp_omg0_

macmini-4265[523]>nm xgingerh | grep iseed
00000001006fccf0 S _laser_mod_mp_iseed_

macmini-4265[524]>nm xgingerh | grep l_mult_pol_emit
00000001006fcde8 S _laser_mod_mp_l_mult_pol_emit_

So, given the gdb manual does not seem to give any obvious information on what to do, I am hoping wise F95&gdb pundits out there can advise me as to how to get at module integer and logical variables from gdb.  In seaching this and other forums, I did not see any relevant posts on this topic in the last few years.

Thanks in advance.

Hi,

i am trying to write a code for visualization of the data generated from 3D-MHD turbulent flow (pseudo spectral code)simulations. 

the aim of this code is to create a .avsdat file which could be visualized  using VISIT visualization software.

my code works well on  intel13/composer_xe_2013.1.117, other higher versions of parallel studio give many errors.

i am using fftw/2.1.5_intel13  and mpich-1.2.5.2/   (just incase you want this info)

i have a lot of macros in the first part of the code, then the Program starts ( Code file attached).

when i compile this code... i get the following error stating from the the main program avsgen starts (line 153) and the  "error is #6236  A specification statement cannot appear in the executable section" and this continues upto line 192.

then a warning "warning #6717: This name has not been given an explicit type." starts for every variable used in the Macro starting from line 71 and the compilation exits.. informing that there are too many errors.

i have tried all the previous solutions that were specified for this error on this forum.. but could not resolve the problem.

hence this post... to request  a possible solution...

P.S.: this code used to work well on Aix, ifort of 2009 (when i was doing my phd) on IBM power 6 machine.. generating the necessary .avsdat files.. 

i now have a 2 node cluster built with 2 processors of Intel® Xeon® Processor E5-2630 v4 on master node and 16 of the same processors in the servant nodes . 

thanking you in advance,

with best regards,

Shiva Kumar. Malapaka

I have a fortran program that compiles fine with

ifort -r8 -g prog.f90 -mkl

and also executes fine with a.out, but when I do

gdb-ia a.out

followed by

(gdb) start

or

(gdb) starti

it says something like  

Starting program: ...............

[New Thread 0x1703 of process 20050]

end then just hangs without giving a further (gdb) prompt.

Am I doing something wrong?

Thanks, Boris 

Hello forum members,

Anyone using the Fortran compiler on RHEL 8?

I did not find a release note stating it is supported, as I am about to buy a new workstation, I am also about to renew my Fortran license.
So if Intel Fortran is not supported or working on RHEL 8 I will stick with RHEL 7.6 for a while until their is an Intel Fortran compiler that is supported on RHEL 8

Regards,

Jan Gerrit Kootstra

I have an open-source developer licence for Intel ifort/mkl/cluster/icc which expired on July 11th 2019. The moment it expired I could no longer use ifort or other compilers, even though they were downloaded way before the expiration date. I am not sure if this is a feature (Bug) in the Flex licence structure; there is a small chance that it is OS related since we updated everything about three months ago -- but the timing does not work.

N.B., I have twice applied to renew my open-source developer licence and have had no response even though the processing is supposed to only take a couple of days -- it was never this slow before.

Hi,

I just wanted to inform you that I'm experiencing a severe error that produces wrong results when using 'do concurrent' with the '-parallel' option in the compiler. The code that produces this problem:

            !for every diagonal element in local matrix
            do concurrent (k=1:size(md%lmat,2,GST_IK),i=1:size(md%lmat,1,GST_IK),ig(i).eq.kg(k))
                !add diagonal element
                md%lmat(i,k)=md%lmat(i,k)+diag(i)
            end do

With the '-parallel' option 'diag' is inserted into the first column of 'md%lmat', not on the main diagonal as intended. The program does not exit with an error so it took me a good time to find this... (thank you Intel). Omitting '-parallel' solves this issue. I'm using the compiler version 19.0.4.243. The full compiler command reads:

'mpif90 -standard-semantics -O3 -fbuiltin -ipo -xSKYLAKE-AVX512 -fp-model precise -assume byterecl -parallel ...'

I've tried to open a support ticket on this matter, but Intel closed it already as I'm obvoiusly 'not qualified for Priority Support'.

Kind regards,
-zp3

Hi all!

I met a problem when I compiled Noah-MP (a model) using intel fortran (ifort) on linux platform. 

module_NoahMP_hrldas_driver.f(852): error #6633: The type of the actual argument differs from the type of the dummy argument.   [NSOIL]
                   NSOIL,  .false.,                                                   &
-------------------^
module_NoahMP_hrldas_driver.f(852): error #6633: The type of the actual argument differs from the type of the dummy argument.
                   NSOIL,  .false.,                                                   &
---------------------------^
module_NoahMP_hrldas_driver.f(853): error #6633: The type of the actual argument differs from the type of the dummy argument.
                  .true.,runoff_option,                                                   &
------------------^
module_NoahMP_hrldas_driver.f(853): error #6633: The type of the actual argument differs from the type of the dummy argument.   [RUNOFF_OPTION]
                  .true.,runoff_option,                                                   &
-------------------------^
module_NoahMP_hrldas_driver.f(854): error #6633: The type of the actual argument differs from the type of the dummy argument.   [IDS]
                  ids,ide+1, jds,jde+1, kds,kde,                &  ! domain
------------------^
module_NoahMP_hrldas_driver.f(857): error #6633: The type of the actual argument differs from the type of the dummy argument.   [SMOISEQ]
                     ,smoiseq  ,smcwtdxy ,rechxy   ,deeprechxy, areaxy ,dx, dy, msftx, msfty,&
----------------------^
module_NoahMP_hrldas_driver.f(857): error #6633: The type of the actual argument differs from the type of the dummy argument.   [SMCWTDXY]
                     ,smoiseq  ,smcwtdxy ,rechxy   ,deeprechxy, areaxy ,dx, dy, msftx, msfty,&
--------------------------------^
module_NoahMP_hrldas_driver.f(858): error #6633: The type of the actual argument differs from the type of the dummy argument.   [STEPWTD]
                     wtddt    ,stepwtd  ,dtbl  ,qrfsxy ,qspringsxy  ,qslatxy,                  &
-------------------------------^
module_NoahMP_hrldas_driver.f(858): error #6633: The type of the actual argument differs from the type of the dummy argument.   [QRFSXY]
                     wtddt    ,stepwtd  ,dtbl  ,qrfsxy ,qspringsxy  ,qslatxy,                  &
------------------------------------------------^
module_NoahMP_hrldas_driver.f(852): error #6638: An actual argument is an expression or constant; this is not valid since the associated dummy argument has the explicit INTENT(OUT) or INTENT(INOUT) attribute.
                   NSOIL,  .false.,                                                   &
---------------------------^
module_NoahMP_hrldas_driver.f(844): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic.   [T2MBXY]
     CALL NOAHMP_INIT(    LLANDUSE,     SNOW,    SNOWH,   CANWAT,   ISLTYP,   IVGTYP,ISURBAN, &   ! call from WRF phys_init
----------^
module_NoahMP_hrldas_driver.f(844): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic.   [CHSTARXY]
     CALL NOAHMP_INIT(    LLANDUSE,     SNOW,    SNOWH,   CANWAT,   ISLTYP,   IVGTYP,ISURBAN, &   ! call from WRF phys_init
----------^
module_NoahMP_hrldas_driver.f(857): error #6634: The shape matching rules of actual arguments and dummy arguments have been violated.   [SMOISEQ]
                     ,smoiseq  ,smcwtdxy ,rechxy   ,deeprechxy, areaxy ,dx, dy, msftx, msfty,&
----------------------^
module_NoahMP_hrldas_driver.f(857): error #6634: The shape matching rules of actual arguments and dummy arguments have been violated.   [SMCWTDXY]
                     ,smoiseq  ,smcwtdxy ,rechxy   ,deeprechxy, areaxy ,dx, dy, msftx, msfty,&
--------------------------------^
module_NoahMP_hrldas_driver.f(844): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic.   [DEEPRECHXY]
     CALL NOAHMP_INIT(    LLANDUSE,     SNOW,    SNOWH,   CANWAT,   ISLTYP,   IVGTYP,ISURBAN, &   ! call from WRF phys_init
----------^
module_NoahMP_hrldas_driver.f(844): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic.   [AREAXY]
     CALL NOAHMP_INIT(    LLANDUSE,     SNOW,    SNOWH,   CANWAT,   ISLTYP,   IVGTYP,ISURBAN, &   ! call from WRF phys_init
----------^
module_NoahMP_hrldas_driver.f(857): error #6634: The shape matching rules of actual arguments and dummy arguments have been violated.   [MSFTX]
                     ,smoiseq  ,smcwtdxy ,rechxy   ,deeprechxy, areaxy ,dx, dy, msftx, msfty,&
--------------------------------------------------------------------------------^
module_NoahMP_hrldas_driver.f(857): error #6634: The shape matching rules of actual arguments and dummy arguments have been violated.   [MSFTY]
                     ,smoiseq  ,smcwtdxy ,rechxy   ,deeprechxy, areaxy ,dx, dy, msftx, msfty,&
---------------------------------------------------------------------------------------^
module_NoahMP_hrldas_driver.f(844): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic.   [MSFTX]
     CALL NOAHMP_INIT(    LLANDUSE,     SNOW,    SNOWH,   CANWAT,   ISLTYP,   IVGTYP,ISURBAN, &   ! call from WRF phys_init
----------^
module_NoahMP_hrldas_driver.f(844): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic.   [MSFTY]
     CALL NOAHMP_INIT(    LLANDUSE,     SNOW,    SNOWH,   CANWAT,   ISLTYP,   IVGTYP,ISURBAN, &   ! call from WRF phys_init
----------^
module_NoahMP_hrldas_driver.f(858): error #6634: The shape matching rules of actual arguments and dummy arguments have been violated.   [QRFSXY]
                     wtddt    ,stepwtd  ,dtbl  ,qrfsxy ,qspringsxy  ,qslatxy,                  &
------------------------------------------------^
module_NoahMP_hrldas_driver.f(858): error #6634: The shape matching rules of actual arguments and dummy arguments have been violated.   [QSPRINGSXY]
                     wtddt    ,stepwtd  ,dtbl  ,qrfsxy ,qspringsxy  ,qslatxy,                  &
--------------------------------------------------------^
module_NoahMP_hrldas_driver.f(1072): error #6633: The type of the actual argument differs from the type of the dummy argument.   [IDS]
                ids,ide, jds,jde, kds,kde,                      &
----------------^
module_NoahMP_hrldas_driver.f(1072): error #6633: The type of the actual argument differs from the type of the dummy argument.   [IDE]
                ids,ide, jds,jde, kds,kde,                      &
--------------------^
module_NoahMP_hrldas_driver.f(1072): error #6633: The type of the actual argument differs from the type of the dummy argument.   [JDS]
                ids,ide, jds,jde, kds,kde,                      &
-------------------------^
module_NoahMP_hrldas_driver.f(1072): error #6633: The type of the actual argument differs from the type of the dummy argument.   [JDE]
                ids,ide, jds,jde, kds,kde,                      &
-----------------------------^
module_NoahMP_hrldas_driver.f(1072): error #6633: The type of the actual argument differs from the type of the dummy argument.   [KDS]
                ids,ide, jds,jde, kds,kde,                      &
----------------------------------^
module_NoahMP_hrldas_driver.f(1043): error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface.   [ITE]
         CALL noahmplsm(ITIMESTEP,       YR, JULIAN_IN,   COSZEN, XLAT_URB2D, &
--------------^
module_NoahMP_hrldas_driver.f(1043): error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface.   [JTS]
         CALL noahmplsm(ITIMESTEP,       YR, JULIAN_IN,   COSZEN, XLAT_URB2D, &
--------------^
module_NoahMP_hrldas_driver.f(1043): error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface.   [JTE]
         CALL noahmplsm(ITIMESTEP,       YR, JULIAN_IN,   COSZEN, XLAT_URB2D, &
--------------^
module_NoahMP_hrldas_driver.f(1265): catastrophic error: Too many errors, exiting
compilation aborted for module_NoahMP_hrldas_driver.f (code 1)
make[1]: *** [module_NoahMP_hrldas_driver.o] Error 1

I searched many times and checked the type of actual argument and dummy arguments. I did not find the difference between them. So can someone help this?

I attached two files including actual argument and dummy one!

Good morning, good afternoon,

(structure of that message: context and presentation of the code, presentations of my issues, questions)

==================== CONTEXT AND PRESENTATION OF THE CODE ====================

So over the last year I have been implementing a module of particles in a fluid code (MHD  to be precised). The code is parallelized with MPI. Everything is declared accordingly and working well in the current state.

My particles are defined thanks to a FORTRAN derived type, a.k.a a structure, which allows to aggregate data of different type, essentially integers and real in the present.

The justification for that choice is the following:

- The particles' positions are continuous, meaning they are not defined over points of the grid (associated to the fluid description) but can take any value; in the limit of machine precision. So the position of a particle needs to be a real obviously. (3 actually --> 3D space in the model)

- But I also need to localize the particles over the grid and so I save the indices relatively to the grid so it is faster to go and take a fluid quantity in the array and interpolate it at the position of the particle. So I am using integer type value for that.

Here is the declaration of the corresponding type in my module:

-------------------------------------------------------------

    type PIC_particles
    ! sequence
    integer           :: active
    integer           :: wrong_dt
    integer           :: nb_wrong_dt
    integer           :: tag
    integer           :: Idx
    integer           :: Idy
    integer           :: Idz
    real(dp)          :: mass
    real(dp)          :: charge
    real(dp)          :: x
    real(dp)          :: y
    real(dp)          :: z
    real(dp)          :: px
    real(dp)          :: py
    real(dp)          :: pz
    real(dp)          :: half_px
    real(dp)          :: half_py
    real(dp)          :: half_pz

-------------------------------------------------------------

===================================================================

==================== ISSUES ====================
Now, when writing the code I used explicit DO loops almost everywhere.

Let's say I am having N particles for instance, the algorithm is the following.

- DO LOOP over the number of particles N.

- IF condition to check to active feature: equal to 1 --> the particle is still existing in the simulation box

                                                                   equal to 0 --> the particle does not exist and will be removed

- Doing some operations (interpolation of the e.m. field (1st order spline function), evolving the momentum of the particle, evolving the position, checking position relatively to the box boundaries)

- Going to the next particle

=============================================

==================== QUESTIONS ====================

This is what I would like to improve: replace all DO LOOP by global operations.

My questions are:

1) Would the module be faster with global operations? (seems to be good to ask first - it represents quite a work, so if there is no point in the end let's stop it here) Does "global operations" mean improved performances?

2) How does it happens in memory when doing that? Does the machine go and take the data where they are, take them somewhere else to perform a sum or a product, and then go to find the place the result is stored?

Regarding the state of the memory and 2D array operations for example, I know it is faster to write the most inner (innermost?) loop on the column and the outermost on the line because the data in the columns are contiguous and the computer does not go back and forth. (I think it is that way, but it may be the opposite)

Is there the same kind of 'trick' to take into account regarding structures? ==> How are the data stored?!

3) If I have something like some million particles (few * 10^6) in a given processor, is there a risk to overload the memory? How does the computer handle this? (knowing that MHD quantities are also taking some memory space)

4) Is there a risk that data could get mixed from one particle to another in the process? (I am a physicist and learnt computational stuff while working, I still that 'fear' when doing something new)

5) Should I create intermediary 1D arrays?

Justification of that question: when interpolating the x-component of the magnetic field for example, I am doing Bx(Idx, Idy, Idz) currently. Is it possible to do Bx( PIC(:)%Idx, PIC(:)%Idy, PIC(:)%Idz )  (PIC is the name of structure) or should I create 1D arrays Index_x, Index_y, Index_z and then do Bx( Index_x(:), Index_y(:), Index_z(:) )?  (maybe a stupid question)

================================================

These last days, the more I think about it the more I have the feeling my code could be more compact and faster.

But before embarking on this work I thought it was a good idea to ask for some advices.

I am grateful to you if you read so far and I hope you will reply.

Kindly

Julien Capitaine

Hi, I compiled a openmp program with intel fortran successfully, and this is my macros and Makefile:

macros

  1 .IGNORE:
  2 RM              =       rm -f
  3 COMPILER90=     ifort -openmp #-fbounds-check
  4 FREESOURCE=     -free #-ffree-form
  5 F90FLAGS  =     -c -I/home/2015051066/soft/netcdf/include
  6 MODFLAG =
  7 LDFLAGS =       -O3
  8 CPP     =       cpp
  9 CPPFLAGS        =        -P -traditional
 10 #F90FLAGS  =     -c -I/cm/shared/apps/netcdf/gcc/64/4.5.0/include
 11 #F90FLAGS  =     -c -I/cm/shared/uaapps/netcdf/fortran/gcc/4.4.4/include
 12 #F90FLAGS  =     -c -I/home/u4/niug/netcdf-fort-4.4.4/include
 13 RM = rm -f
 14 RM = rm -f
 15 RM = rm -f
 16 RM = rm -f
 17 RM = rm -f

Makefile

  1 # Makefile
  2 #
  3 #INCLUDES=
  4 .SUFFIXES:
  5 .SUFFIXES: .o .f
  6
  7 include ../macros
  8
  9 MAINOBJ1 = ../IO_code/Noah_driver.o
 10
 11 OBJS = \
 12         ../Noah_code/module_Noahlsm.o \
 13         ../Noah_code/module_Noahlsm_param_init.o \
 14         ../Noah_code/module_Noahlsm_utility.o \
 15         ../Noah_code/module_date_utilities.o \
 16         ../IO_code/module_Noah_NC_output.o \
 17         ../IO_code/module_Noahlsm_gridded_input.o
 18
 19 CMD = Noah
 20 all:    $(CMD)
 21
 22 Noah: $(OBJS) $(MAINOBJ1)
 23         @echo ""
 24         $(COMPILER90) -o $(@) $(OBJS) $(MAINOBJ1) -L/home/2015051066/soft/netcdf/lib -lnetcdff -lnetcdf
 25 #       $(COMPILER90) -o $(@) $(OBJS) $(MAINOBJ1) -L/cm/shared/apps/netcdf/gcc/64/4.5.0/lib -lnetcdff -lnetcdf
 26 #       $(COMPILER90) -o $(@) $(OBJS) $(MAINOBJ1) -L/cm/shared/uaapps/netcdf/fortran/gcc/4.4.4/lib -lnetcdff -lnetcdf
 27         @echo ""
 28
 29 # This command cleans up
 30
 31 clean:
 32         rm ../IO_code/*mod ../IO_code/*.o
 33         rm ../Noah_code/*mod ../Noah_code/*.o
 34         rm $(CMD)

When I run the model with the pbs script:

  1 #!/bin/sh -f
  2 #PBS -N test
  3 #PBS -m n
  4 #PBS -l mem=1gb
  5 #PBS -l nodes=1:ppn=28
  6 nprocs=`wc -l < $PBS_NODEFILE`
  7 cd $PBS_O_WORKDIR
  8 #date
  9 #mpirun -genv I_MPI_DEVICE ssm  -np $nprocs -hostfile $PBS_NODEFILE $PBS_O_WORKDIR/test.sh
 10 #cd /home/2014011989/noahmp/Run
 11 /usr/bin/time ./Noah >&out
 12 #date
 13

The error is:

  1  mdt, minute = 01010000
  2  INPUT LANDUSE = USGS
  3  LANDUSE TYPE = USGS FOUND          27  CATEGORIES
  4  INPUT SOIL TEXTURE CLASSIFICAION = STAS
  5  SOIL TEXTURE CLASSIFICATION = STAS FOUND          19  CATEGORIES
  6  successful initialize general model parameters
  7  ------------- successful reading surface data ------------------
  8           30
  9   0.3950000      0.4100000      0.4340000      0.4760000      0.4850000
 10   0.4390000      0.4040000      0.4640000      0.4650000      0.4060000
 11   0.4680000      0.4680000      0.3950000       1.000000      0.2000000
 12   0.4210000      0.4680000      0.2000000      0.3390000      0.0000000E+00
 13   0.0000000E+00  0.0000000E+00  0.0000000E+00  0.0000000E+00  0.0000000E+00
 14   0.0000000E+00  0.0000000E+00  0.0000000E+00  0.0000000E+00  0.0000000E+00
 15  fini=arbitrary initialization
 16  ------------- successful initialization ------------------
 17        1    1980       1       1       1       0       1
 18  -------------------------------------------
 19  READFORC: opening /home/2014011989/noahmp/Noah_data/forcings/1980/1980010100.nc
 20  The model is losing(-)/gaining(+) fake water
 21  ERRWAT =  -5.000397
 22  ix,iy,WA,END_WB,BEG_WB,PRCP*DT,ECAN*DT,EDIR*DT,ETRAN*DT,RUNSRF*DT,RUNSUB*DT
 23  The model is losing(-)/gaining(+) fake water
 24 forrtl: severe (40): recursive I/O operation, unit -1, file unknown
 25 �^H~[^@^@^@^@^@~@Y~W^@^@^@^@^@^@^@^@^@^@^@^@^@^@4.02user 2.11system 0:13.07elapsed 46%CPU (0avgtext+0avgdata 150056maxresiden    t)k
 26 22032inputs+0outputs (0major+51064minor)pagefaults 0swaps
~

Is the problem from my wrong script? How to solve it?

Thank you very much!

I am a new user of Intel Fortran. I have some problems when trying to use openMP in Intel Fortran.

the Official User guide states that to add OpenMP* support to applications, do the following:

1.Add the appropriate OpenMP* directives to your source code.

2.Compile the application with the Qopenmp (Windows) or qopenmp (Linux* and macOS*) option.

I understand the first step. but how should I do the second step? Currently I use  "Debug → start without Debugging” buttons to run my code. do I always have to use a cmd to compile the applications if I want to incorporate OpenMP (which I failed since I dont know the path that I should specify)?

I'm also wondering whether I need to install some external openMp packages before I do the above steps

Any hint or suggestion is highly appreciated. Thanks in advance

Lu