Hello:
How do I fix this error? The file (used in conjuction with Abaqus) is attached!
ifort: command line remark #10148: option '-i-dynamic' not supported
Please help! Thanks!
Mousumi
Hello:
How do I fix this error? The file (used in conjuction with Abaqus) is attached!
ifort: command line remark #10148: option '-i-dynamic' not supported
Please help! Thanks!
Mousumi
Attachment | Size |
---|---|
Download![]() | 2.25 KB |
For many years, the "web home" of ISO/IEC JTC1/SC22/WG5 (the international Fortran standards committee, or WG5 for short) has been graciously hosted by NAG. I am pleased to announce that WG5 now has its own web site: https://wg5-fortran.org/ The site is served over https and is "mobile friendly".
The WG5 web site is where you'll find news about what's happening with the Fortran standard, and links to all WG5 documents. Information on current and past standards is also available there.
On the home page you will see a link to a survey, requesting opinions on and suggestions for features that you would like to see in the next Fortran standard, tentatively titled Fortran 2020. If you want to help shape the future of Fortran, please take a few minutes and fill out the survey. While the survey will remain open through January 2018, we will start analyzing responses at the October J3 meeting. Also, the list of features the survey asks you to rank may be amended based on suggestions received.
I welcome all comments on the web site, and especially if you discover any problems. Not yet done are the email list indexes and news older than 2016.
Hi there,
in the course of modernizing some of my code I have moved to putting many "call by refernce" routines which were previously "stand-alone" behind types. In addition arrays are now passed using type bound pointers, usually with the "contiguous" attribute. This has the big advantage of avoiding to pass array boundaries explicitly (because many of my arrays start at index value zero). However, I have noticed a speed difference to an extent that the type bound routines need up to twice as much time for processing large arrays than the direct routines.
The below program mimics the above structure. It implements the frist part of an implicit multiplication of a 4.5 Mio x 100 matrix with an 4.8 Mio x 4.8 Mio structured sparse co-variance matrix (the latter matrix can be stored in form of four vectors and is held by the type). This routine needs about 4.8 seconds when called directly, and about 6.6 seconds when called through the type. This is n ot a big difference in absolute numbers, but sums up when performed several thousand times. Given that the type transports the array into the routine via a pointer with attribute "contiguous" this difference in speed should not appear. however, may be I haven't understood the standard incorrectly. The speed was measured on a Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz with 56 processors. The compiler was ifort 17.4. The data set can be supplied on request.
Any Ideas?
Thanks a lot
Module Mod_Direct contains Subroutine SubDrop(ISUBound1,ISUBound2,RMInOut,ivi,ivs&&,ivd,rvp,ISNThreads) !$ use omp_lib Implicit None Integer*8, Intent(In) :: ISUbound1, ISUBound2 Real*8, Intent(InOut) :: RMInOut(0:ISUbound1,1:ISUBound2) Integer*8, Intent(In) :: ivs(:), ivd(:), ivi(:) Real*8, Intent(In) :: RVp(:) Integer*4, intent(in), optional :: ISNThreads Integer*8 :: c1, c2, ss, dd, ii outer:block RMInOut(0,:)=0.0D00 !$ if(present(ISNThreads)) Then !$ if(ISNThreads>size(RMInOUt,2)) Then !$ call omp_set_num_threads(size(RMInOut,2)) !$ else !$ call omp_set_num_threads(ISNThreads) !$ End if !$ else !$ c1=omp_get_max_threads() !$ if(c1>size(RMInout,2)) Then !$ call omp_set_num_threads(size(RMInout,2)) !$ else !$ call omp_set_num_threads(int(c1,4)) !$ End if !$ end if !$OMP PARALLEL DO PRIVATE(ss,dd,c2,c1) Do c1=1,size(RMInOut,2) Do c2=1,size(IVI,1) ss=ivs(c2) dd=ivd(c2) ii=ivi(c2) RMInOut(ii,c1)=RMInOut(ii,c1)+rvp(c2)*(RMInOut(ss,c1)&&+RMInOut(dd,c1)) End Do End Do !$OMP END PARALLEL DO End block outer End Subroutine SubDrop end Module Mod_Direct Module Mod_Type Type :: Testtype Integer*8, Allocatable :: ivi(:), ivs(:), ivd(:) Integer*8 :: isn Integer*4 :: ISSubStat Real*8, Allocatable :: rvp(:) Real*8, Pointer, contiguous :: RMInout(:,:) Character(:), allocatable :: csmsg contains procedure, pass, public :: drop=>subdrop End type Testtype Interface Module Subroutine SubDrop(this,ISNThreads) Class(TestType) :: this Integer*4, optional :: ISNThreads end Subroutine End Interface Private :: SubDrop end Module Mod_Type SubModule(Mod_Type) Drop contains Module Procedure SubDrop !$ use omp_lib Implicit None Integer*8 :: c1, c2, ss, dd, ii outer:block if(.not.associated(this%RMInOut)) Then this%CSMSG="ERROR" this%ISSubStat=1;exit outer end if if(lbound(this%RMInOut,1)/=0) Then this%CSMSG="ERROR" this%ISSubStat=1;exit outer End if if(ubound(this%RMInOut,1)/=this%isn) Then this%CSMSG="ERROR" this%ISSubStat=1;exit outer End if this%RMInOut(0,:)=0.0D0 !$ if(present(ISNThreads)) Then !$ if(ISNThreads>size(this%RMInOUt,2)) Then !$ call omp_set_num_threads(size(this%RMInOut,2)) !$ else !$ call omp_set_num_threads(ISNThreads) !$ End if !$ else !$ c1=omp_get_max_threads() !$ if(c1>size(this%RMInout,2)) Then !$ call omp_set_num_threads(size(this%RMInout,2)) !$ else !$ call omp_set_num_threads(int(c1,4)) !$ End if !$ end if !$OMP PARALLEL DO PRIVATE(ss,dd,c2,c1) Do c1=1,size(this%RMInOut,2) Do c2=1,size(this%ivi,1) ss=this%ivs(c2) dd=this%ivd(c2) ii=this%Ivi(c2) this%RMInOut(ii,c1)=this%RMInOut(ii,c1)+this%RVP(c2)&&*(this%RMInOut(ss,c1)+this%RMInOut(dd,c1)) End Do End Do !$OMP END PARALLEL DO End block outer end Procedure End SubModule Drop Program Test use Mod_Type use Mod_Direct Implicit none Type(TestType) :: TST integer :: dim=4876565, dim3=100, c1 real*8, target, allocatable :: rmtmp(:,:) real*8 :: t0, t1 !$ call omp_set_nested(.TRUE.) Allocate(TST%ivi(dim),TST%ivs(dim),TST%ivd(dim),TST&&%rvp(dim)) open(55,file="input.txt",action="read") Do c1=1,dim read(55,*) TST%ivi(c1),tst%ivs(c1),tst%ivd(c1),tst%rvp(c1) end Do tst%isn=maxval(tst%ivi) Allocate(rmtmp(0:tst%isn,dim3),source=0.0D0) !!@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ TST%RMInOut=>rmtmp call TST%drop() !!@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ !!call SubDrop(ISUBound1=Int(tst%isn,8),ISUBound2=Int(dim3,8),RMInout& !! &=rmtmp,ivi=tst%ivi,ivs=tst%ivs,ivd=tst%ivd,rvp=tst%rvp) End Program Test
I've been chasing my tail for an hour trying to understand why some variables were not initialised and finally twigged that I had a missing comma in a do loop.
I had;
DO J=NCHAN, 1 -1
DO STUFF
END DO
I had missed the comma between the end of iteration control and the step. I have IMPLICIT NONE and I'm compiling with -c -m64 -g -check all -debug full -traceback -warn all -heap-arrays
Shouldn't this get flagged at compile time? I'm using XE 2017 Update 4.
Cheers
Kim
Hi ifort develiper and users,
I have written a fortran code(where four loops are present) in openMP. Here i share the openMP code, where the second loop is parallelized.
first: do i=1,NMAX,1
xmsd_1(i) = 0.0
!$omp parallel default(none) &
!$omp shared (NTMAX,nmol,i,com_xu,P_1,xmsd_1) &
!$omp private(k,m,dx,xmsd,pr_1)
!$omp do reduction(+:xmsd_1)
second: do j=1,NTMAX,1
third : do k =1,nmol,1
pr_1 = 1
fourth : do m=jframe,jframe+iframe,1
pr_1 = pr_1 * P_1(m,k)
end do fourth
if(pr_1 .eq. 1) then
dx = com_xu(k,j+i) - com_xu(k,j)
xmsd = dx*dx
xmsd_1(i) = xmsd_1(i) + xmsd * pr_1
end if
end do third
end do second
!$omp end do
!$omp end parallel
print*, i,xmsd(i)
end do first
My openMP code(where second loop was parallelized) results do not match the serial code results. could you please suggest a solution to this problem?
Hello,
I have compiled Quantum Espresso (QE) in a Linux cluster using intel2016.4.258 and openmpi-2.1.1. I get a runtime error for IOSTAT=121. The DIRECT_IO_FACTOR ( block length byte) in the QE code is set to 8.
My understanding is that DIRECT_IO_FACTOR is system dependent. Is there a way to find out what DIRECT_IO_FACTOR value is on any Linux system?
Thank you,
Vahid
I see MS is developing Visual Studio Code for all three platforms (https://code.visualstudio.com/download). Has anyone used VSC as an IDE for Intel Fortran, or is VSC just a text editor?
Thanks!
Hello,
A search indicates that this question was asked (in the Fortran for Windows Forum) before, but that was three years ago, and I can't find any update.
I'm using Intel Fortran version16.1 and I'd like to initialize allocatable arrays to NaN to aid in debugging. I am familiar with the -ftrapuv and -init=snan,array options but it is my understanding they do not work for allocatable arrays. The answer in the three year old question I found was "it is something we are working on for the future". It is now the "future", and since that topic is closed, I've opened a new question to ask again. Has that capability been added? Or is it still part of future plans?
Chris Harrop
Dear All,
I'm using Systemstamp probes (vm.pagefault) to avoid page faults in my code by forcing to read/write in all memory. The probe says that __intel_avx_rep_memcpy has page fault:
fault address: 0x424000, symbol: __intel_avx_rep_memcpy+0x80/0x17c0, access: r, type: minor, delay: 36
according to asm it is:
(gdb) info symbol __intel_avx_rep_memcpy+0x80 __intel_avx_rep_memcpy + 128 in section .text 0x0000000000423fb9 <+121>: shr $0x2,%r9 0x0000000000423fbd <+125>: sub %r9,%r11 0x0000000000423fc0 <+128>: cmp %r11,%rcx 0x0000000000423fc3 <+131>: jae 0x424060 <__intel_avx_rep_memcpy+288> 0x0000000000423fc9 <+137>: nopl 0x0(%rax)
So could you help me to understand what memory should be forced there?
Regards,
Roman
Recently I found a compilation difference between the compiler for Linux and the one for windows. The Windows one can report some errors, like miss matching of dummy arguments and actual ones, which the Linux one can't. I'd like to know if there is any option which can force the compiler to do that. Thanks!
Hi, the following code produces an ICE.
Module MyModule implicit none private Type ,public :: MyType integer :: N = 2 contains procedure :: DoSomething End Type Interface Pure Module Function DoSomething( This, Inp ) result(Out) class(MyType) ,intent(in) :: This integer ,dimension(This%N) ,intent(in) :: Inp integer ,dimension(This%N) :: Out End Function End Interface End Module Submodule(MyModule) MySubModule implicit none contains ! ! WORKS ! Pure Module Function DoSomething( This, Inp ) result(Out) ! class(MyType) ,intent(in) :: This ! integer ,dimension(This%N) ,intent(in) :: Inp ! integer ,dimension(This%N) :: Out ! Out = Inp * This%N ! End Function ! DO NOT WORKS Module Procedure DoSomething Out = Inp * This%N End Procedure End Submodule Program Main use MyModule ,only: MyType type(MyType) :: Obj write(*,* ) Obj%DoSomething([1,2]) End Program
using ifort version 17.0.4.
The error comes from the "Module Procedure" ... "End Procedure" form for declaring submodule procedures.
If The procedure interface is repeated, then the error goes away.
I thought initially that this error was related to issue DPD200413234.
See https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/707181.
In the IVF documentation, Intrinsic subroutine, MM_PREFETCH
In descriptions
hint = 0 ... Use this for integer data
hint = 1 ... Use this for REAL data
The compiler directive PREFETCH does not have this description. Examples seem to indicate fetching REALs to L1 may be effective.
Does this mean that MM_PREFETCH-ing of REALs to L1 is not (generally) effective? .OR. implies that the VPU does not fetch from L1?
Please explain.
Jim Dempsey
Version: intel-compilers-17/17.0.2.174
File: connolly.f from the Tinker application https://dasher.wustl.edu/tinker/
Hi, I would like to know if there is or will be a way to integrate the intel compiler in the Eclipse IDE (Photran) for MacOS. I tried to integrate the two following the instructions for Linux that I found here: https://software.intel.com/en-us/get-started-with-cpp-compiler-17.0-for-linux-parallel-studio-xe-2017
but in the ide_support_2017 folder the only option I have is xcode.
Thanks
Hi there,
in the course of modernizing some of my code I have moved to putting many "call by refernce" routines which were previously "stand-alone" behind types. In addition arrays are now passed using type bound pointers, usually with the "contiguous" attribute. This has the big advantage of avoiding to pass array boundaries explicitly (because many of my arrays start at index value zero). However, I have noticed a speed difference to an extent that the type bound routines need up to twice as much time for processing large arrays than the direct routines.
The below program mimics the above structure. It implements the frist part of an implicit multiplication of a 4.5 Mio x 100 matrix with an 4.8 Mio x 4.8 Mio structured sparse co-variance matrix (the latter matrix can be stored in form of four vectors and is held by the type). This routine needs about 4.8 seconds when called directly, and about 6.6 seconds when called through the type. This is n ot a big difference in absolute numbers, but sums up when performed several thousand times. Given that the type transports the array into the routine via a pointer with attribute "contiguous" this difference in speed should not appear. however, may be I haven't understood the standard incorrectly. The speed was measured on a Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz with 56 processors. The compiler was ifort 17.4. The data set can be supplied on request.
Any Ideas?
Thanks a lot
Module Mod_Direct contains Subroutine SubDrop(ISUBound1,ISUBound2,RMInOut,ivi,ivs&&,ivd,rvp,ISNThreads) !$ use omp_lib Implicit None Integer*8, Intent(In) :: ISUbound1, ISUBound2 Real*8, Intent(InOut) :: RMInOut(0:ISUbound1,1:ISUBound2) Integer*8, Intent(In) :: ivs(:), ivd(:), ivi(:) Real*8, Intent(In) :: RVp(:) Integer*4, intent(in), optional :: ISNThreads Integer*8 :: c1, c2, ss, dd, ii outer:block RMInOut(0,:)=0.0D00 !$ if(present(ISNThreads)) Then !$ if(ISNThreads>size(RMInOUt,2)) Then !$ call omp_set_num_threads(size(RMInOut,2)) !$ else !$ call omp_set_num_threads(ISNThreads) !$ End if !$ else !$ c1=omp_get_max_threads() !$ if(c1>size(RMInout,2)) Then !$ call omp_set_num_threads(size(RMInout,2)) !$ else !$ call omp_set_num_threads(int(c1,4)) !$ End if !$ end if !$OMP PARALLEL DO PRIVATE(ss,dd,c2,c1) Do c1=1,size(RMInOut,2) Do c2=1,size(IVI,1) ss=ivs(c2) dd=ivd(c2) ii=ivi(c2) RMInOut(ii,c1)=RMInOut(ii,c1)+rvp(c2)*(RMInOut(ss,c1)&&+RMInOut(dd,c1)) End Do End Do !$OMP END PARALLEL DO End block outer End Subroutine SubDrop end Module Mod_Direct Module Mod_Type Type :: Testtype Integer*8, Allocatable :: ivi(:), ivs(:), ivd(:) Integer*8 :: isn Integer*4 :: ISSubStat Real*8, Allocatable :: rvp(:) Real*8, Pointer, contiguous :: RMInout(:,:) Character(:), allocatable :: csmsg contains procedure, pass, public :: drop=>subdrop End type Testtype Interface Module Subroutine SubDrop(this,ISNThreads) Class(TestType) :: this Integer*4, optional :: ISNThreads end Subroutine End Interface Private :: SubDrop end Module Mod_Type SubModule(Mod_Type) Drop contains Module Procedure SubDrop !$ use omp_lib Implicit None Integer*8 :: c1, c2, ss, dd, ii outer:block if(.not.associated(this%RMInOut)) Then this%CSMSG="ERROR" this%ISSubStat=1;exit outer end if if(lbound(this%RMInOut,1)/=0) Then this%CSMSG="ERROR" this%ISSubStat=1;exit outer End if if(ubound(this%RMInOut,1)/=this%isn) Then this%CSMSG="ERROR" this%ISSubStat=1;exit outer End if this%RMInOut(0,:)=0.0D0 !$ if(present(ISNThreads)) Then !$ if(ISNThreads>size(this%RMInOUt,2)) Then !$ call omp_set_num_threads(size(this%RMInOut,2)) !$ else !$ call omp_set_num_threads(ISNThreads) !$ End if !$ else !$ c1=omp_get_max_threads() !$ if(c1>size(this%RMInout,2)) Then !$ call omp_set_num_threads(size(this%RMInout,2)) !$ else !$ call omp_set_num_threads(int(c1,4)) !$ End if !$ end if !$OMP PARALLEL DO PRIVATE(ss,dd,c2,c1) Do c1=1,size(this%RMInOut,2) Do c2=1,size(this%ivi,1) ss=this%ivs(c2) dd=this%ivd(c2) ii=this%Ivi(c2) this%RMInOut(ii,c1)=this%RMInOut(ii,c1)+this%RVP(c2)&&*(this%RMInOut(ss,c1)+this%RMInOut(dd,c1)) End Do End Do !$OMP END PARALLEL DO End block outer end Procedure End SubModule Drop Program Test use Mod_Type use Mod_Direct Implicit none Type(TestType) :: TST integer :: dim=4876565, dim3=100, c1 real*8, target, allocatable :: rmtmp(:,:) real*8 :: t0, t1 !$ call omp_set_nested(.TRUE.) Allocate(TST%ivi(dim),TST%ivs(dim),TST%ivd(dim),TST&&%rvp(dim)) open(55,file="input.txt",action="read") Do c1=1,dim read(55,*) TST%ivi(c1),tst%ivs(c1),tst%ivd(c1),tst%rvp(c1) end Do tst%isn=maxval(tst%ivi) Allocate(rmtmp(0:tst%isn,dim3),source=0.0D0) !!@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ TST%RMInOut=>rmtmp call TST%drop() !!@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ !!call SubDrop(ISUBound1=Int(tst%isn,8),ISUBound2=Int(dim3,8),RMInout& !! &=rmtmp,ivi=tst%ivi,ivs=tst%ivs,ivd=tst%ivd,rvp=tst%rvp) End Program Test
I've been chasing my tail for an hour trying to understand why some variables were not initialised and finally twigged that I had a missing comma in a do loop.
I had;
DO J=NCHAN, 1 -1
DO STUFF
END DO
I had missed the comma between the end of iteration control and the step. I have IMPLICIT NONE and I'm compiling with -c -m64 -g -check all -debug full -traceback -warn all -heap-arrays
Shouldn't this get flagged at compile time? I'm using XE 2017 Update 4.
Cheers
Kim
ifort will fail when xcode is updated. however, the undate is so frequent.
Is there any way to lift the 7200 characters per line restriction in ifort?
The reason is that I'm using some macros to avoid code duplication and they can be pretty long (whole functions sometimes).
So I have an abstract type with allocatable length strings
type, abstract:: firstType character(len=:), allocatable:: one, two contains end type
I want to be able to include a final subroutine:
type, abstract:: firstType character(len=:), allocatable:: one contains final:: destroyFirst end type contains subroutine destroyFirst(typeIn) end subroutine
Is it possible? When I try to use type(firstType) then I get
error #8313: The TYPE(derived-type-spec) shall not specify an abstract type.
but when I try to use class(firstType) I get the error
error #8339: The dummy argument of a final subroutine must be a variable of the derived type being defined and cannot be optional, pointer, allocatable, or polymorphic.
Is it possible to finalise an abstract type?
Hello, I'm discovering the pleasures of the OOP and I'm faced with a problem depending on the compiler (ifort vs gfortran). Consider this first simple module:
module typedefs implicit none type base_t integer :: i = 0 end type base_t type, extends(base_t) :: ext1_t integer :: j = 0 contains procedure :: ext1EqCl generic :: assignment(=) => ext1EqCl end type ext1_t interface assignment(=) module procedure generic_assign end interface contains subroutine generic_assign (lhs, rhs) class(base_t), intent(in ) :: rhs class(base_t), intent(out), allocatable :: lhs print*,'--> generic_assign' allocate (lhs, source=rhs) end subroutine generic_assign subroutine ext1EqCl (lhs, rhs) class(base_t), intent(in ) :: rhs class(ext1_t), intent(out) :: lhs print*,'--> ext1EqCl' select type(rhs) type is (ext1_t) lhs%i = rhs%i ; lhs%j = rhs%j end select end subroutine ext1EqCl end module typedefs program test use typedefs implicit none class(base_t), allocatable :: p type(ext1_t) :: a1 print '(/,a)','*** do : a1 = ext1_t (1,2) ***' a1 = ext1_t (1,2) print '(/,a)','*** do : p = a1 ***' p = a1 print '(/,a)','*** do : a1 = p ***' a1 = p ; print*,'a1 =',a1 end program test
It compiles and works well with ifort, producing the obvious outputs:
*** do : a1 = ext1_t (1,2) ***
--> ext1EqCl
*** do : p = a1 ***
--> generic_assign
*** do : a1 = p ***
--> ext1EqCl
a1 = 1 2
But it doesn't compile with gfortran, producing the error: Ambiguous interfaces in intrinsic assignment operator for « generic_assign » at (1) and « ext1eqcl » at (2).
If I remove the generic assignment from ext1 and I add the procedure ext1EqCl in the assignment interface as in the following version of typedefs module:
module typedefs implicit none type base_t integer :: i = 0 end type base_t type, extends(base_t) :: ext1_t integer :: j = 0 end type ext1_t interface assignment(=) module procedure generic_assign module procedure ext1EqCl end interface contains subroutine generic_assign (lhs, rhs) class(base_t), intent(in ) :: rhs class(base_t), intent(out), allocatable :: lhs print*,'--> generic_assign' allocate (lhs, source=rhs) end subroutine generic_assign subroutine ext1EqCl (lhs, rhs) class(base_t), intent(in ) :: rhs type (ext1_t), intent(out) :: lhs print*,'--> ext1EqCl' select type(rhs) type is (ext1_t) lhs%i = rhs%i ; lhs%j = rhs%j end select end subroutine ext1EqCl end module typedefs
it compiles and works well with gfortran but not with ifort ( error #6745: The type/rank signature for the arguments of this specific subroutine matches another specific subroutine that shares the same defined ASSIGNMENT. [EXT1EQCL]).
Thank you very much for your time.
ps: ifort --version: ifort (IFORT) 15.0.3 20150408 gfortran --version: GNU Fortran (GCC) 6.3.0