Hi,

The following simple nested OpenMP program(omp parallel do + omp do) can be compiled only with intel compiler.

=====

$ cat test.f90
program test
  implicit none

  integer,parameter :: imax=4, jmax=4
  integer :: i, j
  integer :: n(imax,jmax)

  !$omp parallel do
  do j=1,jmax
     !$omp do
     do i=1,imax
        n(i,j) = 10*i+j
     end do
  end do

  do i=1,imax
     write(6,*) (n(i,j),j=1,jmax)
  end do

  stop
end program test

$ ifort -fopenmp test.f90 && echo ok
ok

=====

Though the compilation finishes successfully, the execution hangs.

=====
$ ./a.out
^Cforrtl: error (69): process interrupted (SIGINT) <-- hang, therefore ctrl+C
Image              PC                Routine            Line        Source
a.out              000000000047F8D1  Unknown               Unknown  Unknown

=====

If I use GNU fortran compiler or PGI compiler, it fails when the compilation time, I think this is the expected behavior.

=====

$ gfortran --version
GNU Fortran (GCC) 5.2.0
Copyright (C) 2015 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
$ gfortran -fopenmp test.f90
test.f90:10:0:

      !$omp do
 ^
Error: work-sharing region may not be closely nested inside of work-sharing, critical, ordered, master or explicit task region

$ pgfortran --version

pgfortran 16.1-0 64-bit target on x86-64 Linux -tp sandybridge
The Portland Group - PGI Compilers and Tools
Copyright (c) 2016, NVIDIA CORPORATION.  All rights reserved.

$ pgfortran -mp test.f90
PGF90-S-0155-Illegal context for DO (test.f90: 10)
  0 inform,   0 warnings,   1 severes, 0 fatal for test

=====

The code works fine with omp parallel do + omp parallel do for any compiler, this is also expected.

=====

$ diff -pu test.f90 test2.f90
--- test.f90    2017-06-23 16:15:39.000000000 +0900
+++ test2.f90   2017-06-23 16:15:34.000000000 +0900
@@ -7,7 +7,7 @@ program test

   !$omp parallel do
   do j=1,jmax
-     !$omp do
+     !$omp parallel do
      do i=1,imax
         n(i,j) = 10*i+j
      end do

[fukuoka@selene71 1]$ ifort -fopenmp test2.f90 -o test2
[fukuoka@selene71 1]$ ./test2
          11          12          13          14
          21          22          23          24
          31          32          33          34
          41          42          43          44
[fukuoka@selene71 1]$ gfortran -fopenmp test2.f90 -o test2.gfortran
[fukuoka@selene71 1]$ ./test2.gfortran
          11          12          13          14
          21          22          23          24
          31          32          33          34
          41          42          43          44
[fukuoka@selene71 1]$ pgfortran -mp test2.f90 -o test2.pgfortran
[fukuoka@selene71 1]$ ./test2.pgfortran
           11           12           13           14
           21           22           23           24
           31           32           33           34
           41           42           43           44
FORTRAN STOP

=====

So, I think intel compiler should return an error when the compilation time if nested omp parallel do + omp do appears in the code, it is better than the hang.

Best regards.

Daichi

When I used the option "-fast" in the mpiifort it got
ld: cannot find -ldl
error, and could not build the executable file.
BTW, the executable file can be built without "-fast" option.
In addition, "-O3 -ipo -no-prec-div -static -xhost" didn't work, too.
Software used is:
compilers_and_libraries_2016.3.223/linux/mpi/intel64/bin/mpiifort
OS is: RedHat 4.4.7-11

Bests regards,
JH CHIANG

Hi,

I'ld like to ask if it's save to point to concurrent variables outside a concurrent construct and use the pointer inside the concurrent construct. E.g.:

...
integer :: m,n
integer, target :: i, k
integer, pointer :: ip, kp
real :: mat(m0,n0)
...
if (something) then
   ip => i
   kp => k
   m=m0;n=n0
else
   ip => k
   kp => i
   m=n0;n=m0
end if
...
do concurrent(k=1:n)
   ...
   do i=1,m
      mat(ip,kp)=...
   end do
end do
...

I've read somewhere:

If a pointer is used in an iteration other than in the case of pointer assignment, allocation, or nullification, it must either be previously pointer associated during that iteration or must not have its pointer association changed during any other iteration. A pointer that has its pointer association changed in more than one iteration has an undefined association status when the construct terminates.

If I understood this correctly, then I do not change the association status in any iteration and so the code above should be legit. On the other hand this seems a bit strange to me, because this implicates that the compiler probably has to replicate also the pointer (even if it never changes within a iteration) and to reassign it to its newly created (also replicated), previously defined target. This would further mean, that the compiler has to check all present pointers if they may be assigned to any iteration-local variable and if so, to set them iteration-local too and to reassign them. This looks like a lot of work to me...
A solution to my understanding problem might be if the compiler would treat the pointer more like an alias and substitutes the actual variable back before expanding them into any concurrent context...

Thanks for any help!

Hi, 

I am facing an issue with ifort 17.0 (the same code was working fine with ifort 12.1 and 16.0) on a simple code where I try to deallocate the fptr returned by C_F_POINTER from ISO_C_BINDING (I associate there the pointer to a C allocated array of char). The error on program compiled with ifort 17.0 is:
forrtl: severe (173): A pointer passed to DEALLOCATE points to an object that cannot be deallocated

Here is the snippet of code:

program testalloc
  use ISO_C_BINDING
  implicit none

  interface
     function c_alloc(buf) bind(C,name="alloc_in_c")
       use ISO_C_BINDING
       integer(C_INT) :: c_alloc
       type(C_PTR), intent(out) :: buf
     end function c_alloc
  end interface

  type(C_PTR) :: cptr
  character, dimension(:), pointer :: fptr
  character(128) :: s
  integer :: len, i

  len = c_alloc(cptr)
  call C_F_POINTER(cptr, fptr, (/len/))

  s = ''
  do i=1,len
     s(i:i) = fptr(i)
  end do

  print *,"obtained string = ",TRIM(s)

  if (associated(fptr)) then
     deallocate(fptr)
  end if

end program testalloc

As no error was detected with previous version of the compiler, I was wondering if it could be a bug in this 17.0 version or if my code was simply not valid but that was not detected/enforced previously?

Thanks
Olivier

I am trying to compile a Fortran code including a specific module with the following type declaration and function definition:

integer, parameter, public :: intd = selected_int_kind(17)
...
contains
...
integer (intd) FUNCTION test(name)
implicit none
character (len=*) name
integer(intd),public:: test
...
return
end function test

Then, within file xxx.f the function test is called via:

number=test(input)

While compiling the file xxx.f, the compiler (ifort 16.0.2.XXX) complains, that the type intd didn't get export:

xxx.f(67): error #6404: This name does not have a type, and must have an explicit type. [TEST]
number=test(input)

I'm only able to fix the problem by defining within xxx.f an extra interface block for the function test like the following:

interface
function test(name)
import:: intd
character (len=*), intent(in):: name
integer(int8):: test
end function test
end interface

Is there any limitation within the design of the Fortran module interfaces disallowing the exportation of the declared type intd or is something wrong about the given code?

Greetings

Sebastian

I have a project that I compile with the intel toolchain. All the .f90 files are compiled to corresponding .o files in the bin directory. When I use the codecov utility I get an HTML with the list of covered files. However that list is missing a bunch of files which should be eligible for coverage. Some of the modules contained in those files are even used during the runs.

What could be a reason why these these files are missing from the coverage report?

When compiling with ifort 17 on Linux, I notice very different GLIBC dependencies than when compiling with icc.  In particular, the following code

      program main
      write(*,*) 'Hello world!'
      end program main

when compiled on my RHEL 6 system (GLIBC2.11) produces an executable that when examined with objdump -x shows dependencies on 

    0x0d696914 0x00 10 GLIBC_2.4
    0x0d696913 0x00 08 GLIBC_2.3
    0x0d696917 0x00 07 GLIBC_2.7
    0x06969191 0x00 06 GLIBC_2.11
    0x09691974 0x00 05 GLIBC_2.3.4
    0x09691a75 0x00 02 GLIBC_2.2.5

On the other hand, an equivalent C program:

#include <stdio.h>

int main() {
  // call a function in another file
  printf("Hello world!\n");

  return(0);
}

shows dependencies only on

    0x0d696914 0x00 04 GLIBC_2.4
    0x09691a75 0x00 03 GLIBC_2.2.5
    0x09691974 0x00 02 GLIBC_2.3.4

Is there a way to eliminate the GLIBC2.11 dependency of the executable generated by ifort?  Compiling with ifort -D_XOPEN_SOURCE=500 results in no complains but identical GLIBC dependencies.

I tried unsuccessfully to use a polymorphic pointer in a Fortran calling program to represent a specific user defined type in a library that users of the library don't necessarily have access to the module files.

I wrote a Fortran library to handle some empirical data. In the original project, the calling program was written in C. I used modules and then had some specific subroutines that acted as the interface to a C calling program. In essence, C would pass a void pointer to the Fortran library routine that used the iso_c_binding intrinsic module to allocate a pointer of the correct type and then associate the pointer with that pointer. It works really well. However, there is now interest in calling some of the routines through Fortran, and the company distribution program does not handle module files. So, I set out to write a Fortran subroutine wrapper. My original idea was to use a polymorphic pointer, such that a Fortran calling program would not have to know anything about the module in library, something like:

program test
  class(*), pointer :: fp
  call finit(fp)
  call fprint(fp)
end program test

where inside of the library subroutine "finit", the pointer is being allocated to the proper type, something like:

subroutine finit(fp)
  use Point
  implicit none
  class(*), pointer :: fp
  type(TPoint), pointer :: p
  allocate(p)
  call init(p)
  fp => p
  nullify(p)
end subroutine finit

This results in a segmentation fault at the line "fp => p". Inspection with gdb says that the address of fp (0x0) cannot be accessed.

I attached the necessary files to build a simple example, including how I compiled them (see compile.sh). There are three "tests", (1) using the module as if you had access to the mod files - works fine; (2) using the C interface that I talked about above - works fine; and (3) using a subroutine "Fortran" interface to the module - which does not work. The result looks like this:

$./compile.sh
 test with using module directly
 x, y:   10.00000       10.00000

 test with CInt wrapper
 x, y:   10.00000       10.00000

 test with F wrapper
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source
a.out              000000000047CC51  Unknown               Unknown  Unknown
a.out              000000000047AD8B  Unknown               Unknown  Unknown
a.out              0000000000447FA4  Unknown               Unknown  Unknown
a.out              0000000000447DB6  Unknown               Unknown  Unknown
a.out              00000000004278A7  Unknown               Unknown  Unknown
a.out              0000000000403370  Unknown               Unknown  Unknown
libpthread-2.23.s  00007EFEFBD5B390  Unknown               Unknown  Unknown
a.out              0000000000402C20  finit_                     24  misc.f90
a.out              0000000000402FA5  test_with_f_wrapp          48  misc.f90
a.out              0000000000403199  MAIN__                     10  main.f90
a.out              00000000004029EE  Unknown               Unknown  Unknown
libc-2.23.so       00007EFEFB9A0830  __libc_start_main     Unknown  Unknown
a.out              00000000004028E9  Unknown               Unknown  Unknown

I have several questions, and am hoping someone might at least be able to point me in the right direction (pun intended). Any thoughts are appreciated.

1. Why does this not work; it seems like this is a good use case for polymorphic pointers.

2. Is there a better way to get around having to send module files.

3. I went so far as to look through the iso_c_binding module and mimicked the code there. Instead of using a polymorphic pointer, this requires using an integer pointer "integer(kind=int_ptr_kind()) :: ptr" and then using compiler directive no_arg_check, which I suspect is suppressing the compiler checker from preventing a compile because it can't find a matching "specific subroutine for this generic subroutine call". This method works but I have never used compiler directives in a production code and am a bit leery of the roubustness of the result -- although I use the iso_c_binding module quite frequently which is doing the same thing. Is this the right way around this problem?

I'm using 17.0.0 20160721 on a Linux system; I have also tested this with 12.1.6 20120928 with same results.

Hello, i have a doubt.

In a program i have 2 differents names for the same COMMON.

They have the same name however some variables have different name.

My question is R and R1 have the same value or not ?

Thank you very much for your attention.

Hello

My application is generating the following error:

forrtl: severe(111): position number is outside of the valid range, unit 11, file (...)

I cannot find any documentation on what this specifically means, and since this is happening in a deployed environment, stack traces e.t.c. are not an option (since symbols have been stripped). 

Are any of you aware as to what this error specifically means? I am assuming that it has to do with the POS= input to write and read commands, but since those are 64-bit integers, I am having trouble with understanding how this could be out of range.

Thank you in advance.

0down votefavorite

Hello, I am trying to debug an MPI fortran program using the advice from this post: (Using GDB to debug an MPI program in Fortran). The idea is to place an MPI_BARRIER inside a DO WHILE loop and then attach gdb to the right process with something like 

gdb -pid 12345

However, I keep getting the following message:

warning: unhandled dyld version (15)

0x00007fffb6f2ef46 in ?? ()

 When I try:

(gdb) info locals

I get "No symbol table info available". As a result, I can not attach gdb to the running process. I am working with MacOS 10.12 (Sierra), gdb 8.0, and compiling with mpif90 configured for ifort (version: 17.0.4). Any ideas about what could be the cause for this problem?

Dear folks,

I am about to build an MPI executable with ifort/mpif90, linking it to the MKL and the OpenMPI libs. I came to the point where a serious problem wrt. to linking with the correct version of the mkl_blacs library occurs. I. e., I try to link with the library libmkl_blacs_ilp64.so (one of the MKL libraries), but the ifort/mpif90 inserts an incorrect library symbol into the ELF object file of the executable:

    libmkl_blacs_ilp64.so => not found

How should I tell the ifort/mpif90 compiler to link with libmkl_blacs_openmpi_ilp64.so and not wirh libmkl_blacs_ilp64.so?

Thanks for your help

Sebastian

Hi,

I received the following error:

ifort    -qopenmp -c mod_transition.f90

mod_transition.f90: 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 mod_transition.f90 (code 1)
Makefile:64: recipe for target 'mod_transition.o' failed
make: *** [mod_transition.o] Error 1

Using ifort/2017.1.132-GCC-6.3.0-2.27

I received the error after making some changes to the mod_transition.f90 file. But have since reverted to a previous commit which compiled fine, and the error still persists. I've found that compiling with the -g debug flag the error does not occur.

The problem also occurs if instead I use ifort/2017.1.132-GCC-5.4.0-2.26

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px 'Andale Mono'; color: #28fe14; background-color: #000000; background-color: rgba(0, 0, 0, 0.9)}
span.s1 {font-variant-ligatures: no-common-ligatures}

Dear Community,

Could you please help me out with the following issue:

1. I have installed Intel Package and source compilers (i.e. icc compiler) in my system:   /opt/intel/compilers_and_libraries_2017.4.196/linux/bin/intel64/icc

2. I try to run ./configure with flags:   $ ./configure --prefix=/usr/local CC=icc CXX=icpc F77=ifort FC=ifort

3. Finally the system says that there is no icc existed, but it is recognizable from which icc command.

Please tell me what I do wrong...

I paste small part of the output log from OpenMPI configuration and also send the whole file in the attachment.

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by Open MPI configure 1.10.7, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure --prefix=/usr/local CC=icc CXX=icpc F77=ifort FC=ifort

## --------- ##
## Platform. ##
## --------- ##

hostname = d25
uname -m = x86_64
uname -r = 4.4.0-83-generic
uname -s = Linux
uname -v = #106-Ubuntu SMP Mon Jun 26 17:54:43 UTC 2017

/usr/bin/uname -p = unknown
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /snap/bin

## ----------- ##
## Core tests. ##
## ----------- ##

configure:5535: checking build system type
configure:5549: result: x86_64-pc-linux-gnu
configure:5569: checking host system type
configure:5582: result: x86_64-pc-linux-gnu
configure:5602: checking target system type
configure:5615: result: x86_64-pc-linux-gnu
configure:5744: checking for gcc
configure:5771: result: icc
configure:6000: checking for C compiler version
configure:6009: icc --version >&5
./configure: line 6011: icc: command not found
configure:6020: $? = 127
configure:6009: icc -v >&5
./configure: line 6011: icc: command not found
configure:6020: $? = 127
configure:6009: icc -V >&5
./configure: line 6011: icc: command not found
configure:6020: $? = 127
configure:6009: icc -qversion >&5
./configure: line 6011: icc: command not found
configure:6020: $? = 127
configure:6040: checking whether the C compiler works
configure:6062: icc    conftest.c  >&5
./configure: line 6064: icc: command not found
configure:6066: $? = 127
configure:6104: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "Open MPI"
| #define PACKAGE_TARNAME "openmpi"
| #define PACKAGE_VERSION "1.10.7"
| #define PACKAGE_STRING "Open MPI 1.10.7"
| #define PACKAGE_BUGREPORT "http://www.open-mpi.org/community/help/"
| #define PACKAGE_URL ""
| #define OPAL_ARCH "x86_64-pc-linux-gnu"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:6109: error: in `/tmp/openmpi-1.10.7':
configure:6111: error: C compiler cannot create executables
See `config.log' for more details

I am programming in Julia and for Parallel computing i am using ParallelAccelerator.jl package. I was able to setup OpenBLAS with g++. Kindly help me out to set up Intel MKL with g++. I have installed Julia using macOS dmg package hence I am unable find Make.inc file. This is article from Intel which explains setting up Julia with Intel MKL I am unable to setup Julia to use MKL instead its currently using OpenBLAS as you can see from the below output. 

julia> versioninfo()
Julia Version 0.5.2
Commit f4c6c9d4bb (2017-05-06 16:34 UTC)
Platform Info:
  OS: macOS (x86_64-apple-darwin13.4.0)
  CPU: Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.7.1 (ORCJIT, haswell)

julia> Pkg.build("ParallelAccelerator")
INFO: Building ParallelAccelerator
ParallelAccelerator: build.jl begin.
ParallelAccelerator: Building j2c-array shared library
System installed BLAS found
Checking for OpenMP support...
OpenMP support found in g++-7
Max OpenMP threads: 8
Using g++-7 to build ParallelAccelerator array runtime.
ParallelAccelerator: build.jl done.

This is how i setup openblas 

export CPLUS_INCLUDE_PATH=$CPLUS_INCLUDE_PATH:/usr/local/opt/openblas/include/
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/opt/openblas/lib/

Kindly let me know if there any other way to Setup MKL.

Thank You
Regards
Saran

I am using ifort 18 beta update 1 on Linux Ubuntu and did observe a severe bug with the SYNC IMAGES statement yet. Can someone confirm that the following program does work with ifort 17 but does not execute if compiled with ifort 18 beta yet?

ifort -coarray -coarray-num-images=2 Main.f90 -o a.out

program Main
  !
  if (this_image() == 1) then
    sync images(*)
  else
    sync images(1)
  end if
  !
end program Main

With ifort 18 beta I am getting the following runtime error:

forrtl: severe (778): One of the images to be synchronized with has terminated.
In coarray image 2
Image              PC                Routine            Line        Source
libicaf.so         00007EFD79C4D607  for_rtl_ICAF_BARR     Unknown  Unknown
a.out              0000000000403CD4  Unknown               Unknown  Unknown
a.out              0000000000403C62  Unknown               Unknown  Unknown
libc-2.19.so       00007EFD7937BF45  __libc_start_main     Unknown  Unknown
a.out              0000000000403B69  Unknown               Unknown  Unknown

forrtl: severe (778): One of the images to be synchronized with has terminated.
In coarray image 1
Image              PC                Routine            Line        Source
libicaf.so         00007FAED9063607  for_rtl_ICAF_BARR     Unknown  Unknown
libicaf.so         00007FAED906333E  for_rtl_ICAF_BARR     Unknown  Unknown
a.out              0000000000403CE7  Unknown               Unknown  Unknown
a.out              0000000000403C62  Unknown               Unknown  Unknown
libc-2.19.so       00007FAED8791F45  __libc_start_main     Unknown  Unknown
a.out              0000000000403B69  Unknown               Unknown  Unknown

application called MPI_Abort(comm=0x84000004, 3) - process 0

(As an aside: It took some time to identify the source of this error, because I do not use SYNC IMAGES regularly and only together with customized synchronization procedures (using sync memory and atomic subroutines) within the same program.)

Best Regards

I am a student working in atmospheric sciences. I am trying to compile a source code of RegESM-1.0.0. while running the configure command it completes successfully but make and make install program issues the following warning: 

............................

-ldl -lpnetcdf /home/ROMS/ROMS_LIB/lib/libxerces-c.so -lnsl /home/ROMS/REGCM-ROMS/src/esm/RegESM-1.0.0/libatm.a /home/ROMS/REGCM-ROMS/src/esm/RegESM-1.0.0/libocn.a -rpath /home/ROMS/ROMS_LIB/lib -rpath /home/ROMS/ROMS_LIB/lib

ifort: command line warning #10006: ignoring unknown option '-rpath'

ifort: command line warning #10006: ignoring unknown option '-rpath'

........

Though, the make and make install command did not abort, it did not produce any executable after compilation. I seek help from the community to overcome this error. I looked upon the makefile and libtool files but could not infer much of it.

Any lead will in solving this is appreciated.

Thanks in anticipation.

Regards

Dhirendra

I have a project that I compile with the intel toolchain. All the .f90 files are compiled to corresponding .o files in the bin directory. When I use the codecov utility I get an HTML with the list of covered files. However that list is missing a bunch of files which should be eligible for coverage. Some of the modules contained in those files are even used during the runs.

What could be a reason why these these files are missing from the coverage report?

When compiling with ifort 17 on Linux, I notice very different GLIBC dependencies than when compiling with icc.  In particular, the following code

      program main
      write(*,*) 'Hello world!'
      end program main

when compiled on my RHEL 6 system (GLIBC2.11) produces an executable that when examined with objdump -x shows dependencies on 

    0x0d696914 0x00 10 GLIBC_2.4
    0x0d696913 0x00 08 GLIBC_2.3
    0x0d696917 0x00 07 GLIBC_2.7
    0x06969191 0x00 06 GLIBC_2.11
    0x09691974 0x00 05 GLIBC_2.3.4
    0x09691a75 0x00 02 GLIBC_2.2.5

On the other hand, an equivalent C program:

#include <stdio.h>

int main() {
  // call a function in another file
  printf("Hello world!\n");

  return(0);
}

shows dependencies only on

    0x0d696914 0x00 04 GLIBC_2.4
    0x09691a75 0x00 03 GLIBC_2.2.5
    0x09691974 0x00 02 GLIBC_2.3.4

Is there a way to eliminate the GLIBC2.11 dependency of the executable generated by ifort?  Compiling with ifort -D_XOPEN_SOURCE=500 results in no complains but identical GLIBC dependencies.

Hello:

I am writing a user subroutine, UMAT, for Abaqus where I need the UMAT subroutine to update and use my own specified stiffness matrix and solution dependent state variables.

I am attaching the fortran file. This is the error message I am getting!

umat_sdvini4.f(41): error #6236: A specification statement cannot appear in the executable section.
      integer i, j
------^
 Intel(R) Fortran 15.0-1684
compilation aborted for umat_sdvini4.f (code 1)

If any of you can help, that would be great!

Thank you very much,

Mousumi Ghosh