I am in the process of converting the COMMON block structure to MODULE structure within a F95 program.  There are about 60 COMMON blocks to convert, but I am beginning slowly.  The program consists of 6 separate source (I prefer fixed form) files:

DUALPRS.for,  DRIVE_S.for,  DRIVE_F.for,  DRIVE_O.for,  PROPSET.for,  UTILSET.for

It has been thoroughly tested in the past and works perfectly.  I am starting out by removing two of the COMMON blocks and replacing them with two MODULES (TFLOGIC and NDST_S), both of which are contained in a new source file:

MODULES_D.for

which resides in the same directory as the original 6 files and definitely has been added to the project.

When I rebuild the single-project solution, I get the following output (please ignore the warning messages concerning output format):

1>------ Rebuild All started: Project: DUALPRS_Develop, Configuration: Debug Win32 ------
1>Deleting intermediate files and output files for project 'DUALPRS_Develop', configuration 'Debug|Win32'.
1>Compiling with Intel(R) Visual Fortran Compiler XE 12.1.5.344 [IA-32]...
1>PROPSET.for
1>DRIVE_O.for
1>C:\Users\Jeffrey\Desktop\DUALPRS Develop\DRIVE_O.for(373): remark #7000: Two-digit year return value may cause problems with the year 2000.  Use DATE_AND_TIME instead   [DATE]
1>C:\Users\Jeffrey\Desktop\DUALPRS Develop\DRIVE_O.for(937): remark #8290: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+3'.
1>C:\Users\Jeffrey\Desktop\DUALPRS Develop\DRIVE_O.for(938): remark #8290: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+3'.
1>C:\Users\Jeffrey\Desktop\DUALPRS Develop\DRIVE_O.for(938): remark #8290: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+3'.
1>UTILSET.for
1>DRIVE_F.for
1>C:\Users\Jeffrey\Desktop\DUALPRS Develop\DRIVE_F.for(373): remark #7000: Two-digit year return value may cause problems with the year 2000.  Use DATE_AND_TIME instead   [DATE]
1>C:\Users\Jeffrey\Desktop\DUALPRS Develop\DRIVE_F.for(937): remark #8290: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+3'.
1>C:\Users\Jeffrey\Desktop\DUALPRS Develop\DRIVE_F.for(938): remark #8290: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+3'.
1>C:\Users\Jeffrey\Desktop\DUALPRS Develop\DRIVE_F.for(938): remark #8290: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+3'.
1>MODULES_D.for
1>DUALPRS.for
1>C:\Users\Jeffrey\Desktop\DUALPRS Develop\DUALPRS.for(15): error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   [MODULETFLOGIC]
1>C:\Users\Jeffrey\Desktop\DUALPRS Develop\DUALPRS.for(17): error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   [MODULENDST_S]
1>C:\Users\Jeffrey\Desktop\DUALPRS Develop\DUALPRS.for(160): error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   [MODULETFLOGIC]
1>compilation aborted for C:\Users\Jeffrey\Desktop\DUALPRS Develop\DUALPRS.for (code 1)
1>
1>Build log written to  "file://C:\Users\Jeffrey\Desktop\DUALPRS Develop\DUALPRS_Develop\Debug\BuildLog.htm"
1>DUALPRS_Develop - 4 error(s), 0 warning(s)
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

So the issue seems to be centered upon the IVF compiler being unable to locate the .mod files for the two new modules (TFLOGIC and NDST_S).

When I check the folder C:\Users\Jeffrey\Desktop\DUALPRS Develop\DUALPRS_Develop\Debug, they are there!  However, I did not see any .obj files associated with these modules.

I even tried to explicitly specify the an Additional Include Path (as above) in the IVF Project Settings:

Properties>Configuration Properties>Fortran>General>Additional Include Directories

Furthermore, I even tried to embed the source code directly within the first source file in which procedures USEd the modules, but the same aborted compilation effort results.

My sense is that there is some simple cause which I am overlooking ... I respectfully bow before the IVF masters, waiting for instructions concerning how to resolve this issue.

Intel Fortran Compiler version 16.0 Update 3 with Visual Studio Shell 2013 has just been installed on a new computer.  When New Project window is opened, there is no option to choose Console Application nor other expected Fortran options, contrary to all previous experience with same compiler on other computers.  Unable to execute Fortran code.  What are possible explanations?

I am trying to use the Poisson Solver with the  sample "d_Laplace_2D.f90". I include the MKL_DFTI.90, which is referenced. The error I received was as follows:

Severity    Code    Description    Project    File    Line    Suppression State
Error        error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   [MKL_DFT_TYPE]        C:\PROGRA~2\INTELS~1\COMPIL~1.207\windows\mkl\include\MKL_DFTI.F90    228    

 MKL_DFT_TYPE is a module inside the file MLK_DFTI.90 , so why would I receive an error and have to check INCLUDE paths.. 

Regards

Jason

I am in the process of converting the COMMON block structure to MODULE structure within a F95 program.  There are about 60 COMMON blocks to convert, but I am beginning slowly.  I had a previous issue over the weekend, but (thankfully) it was resolved with assistance via this forum.

My latest issue is as follows:  In the original version of the program, I have a BLOCK DATA unit that initializes a number of large arrays (which hold thermophysical property data for various fluids; these arrays are never changed during program execution).  Some of the arrays are 1-D; most are 2-D.  These arrays are selectively shared with other program units via COMMON blocks.  The arrays are initialized within the BLOCK DATA unit via DATA statements.

My approach to conversion has been to transform the BLOCK DATA unit into a 'parent' MODULE and leave the data statements that initialize the arrays unchanged.  I then created other MODULEs that replace the COMMON blocks; these modules are USEd inside the 'parent' MODULE to selectively share the arrays with other program units (which also USE these data-sharing modules).

However, when I compile the program, I get the error message indicated in the subject header above.

1.  Why cannot arrays (or variables) initialized via DATA statements be made accessible to other program units via use association?

2.  Could someone please suggest (if possible) a *rudimentary* approach to accomplish my objectives as described above, which would involve as few changes as possible?

I already have some ideas about how to eliminate the DATA statements via array constructors, but the problem with this approach is that some of the arrays are currently initialized in sections (via implied DO loops), and the data was entered in row major order instead of column major order.

When debugging a subroutine contained within a module, the variables that are within the scope of that subroutine but not declared within the module subroutine are not visible with the debugger. This makes debugging very inconvenient if not impossible when using modules. Is there a setting that can make them visible or any other solution to this problem?

My Intel Parallel Studio vision is 2016 update 3.But why I dont't have the OpenMP Diagnostics,Auto-Parallelizer Diagnostics Level and vactorizer Diagnostics Level under my Project properties/Fortran/Diagnostics

Due to unusual circumstances it was necessary to install Fortran on a number of machines, including some virtual machines. Now that things are normal again it is not possible to register Fortran on a new machine because the maximum number of installations has been reached.

Where/How can some of these now unused licenses be “un-installed” ?

Thanks

I have Fortran code which works fine when I compile it for 32bit computer Windous 10, but it does not work when I compile it for 64-bit Windous 10 computer.  In a 64-bit compute it just stops at:   !$OMP DO SCHEDULE(STATIC,chunk)        

These are the switches I use:

ifort a.f90 libiomp5md.lib /heap-arrays /assume:byterecl /assume:buffered_io /Qip- /Ob0 /Qopenmp /auto-scalar /exe:a.exe 

subroutine colsol(a,v,ColTop,ColDONE,maxa,nn,kkk,na,nn1,ierr)
!   **************************************************************
!   *   Cholesky  Factorisation
!   ***************************************************************    
      implicit none

      real*8 a(na),v(nn),b,c
      integer*4 maxa(nn1),nn,l,n,kk,ic,nd,ki,j,k,nn1,na,kh,kl,kn,i_cnt,i_cnt_old, klt,ku,kkk,ierr
      real*8 sum1, amaxak
      integer *4  ColTop(nn),ColDONE(nn)     !...Cholesky
      integer *4  i,TOPij, chunk
      integer *4  iperct,iperct1, maxai, maxaj
!-----------------------------------------------------------
      ierr=0
      iperct=0
      iperct1=0
      
      chunk=1

       !...prepare 'ColTop'   
       do i = 1, nn
           ColTop(i) = i - (maxa(i + 1) - maxa(i)) + 1
       end do  

       !...Columns Done
       do i = 1, nn
           ColDONE(i) = 0   !... mark all columns as not done '0'
       end do  
       
!---------------------------------------------------------------------------------       
       !...factorisation  (Skyline)
        a(1) = dSqrt(a(1))
        ColDONE(1) = 1   !...colum 1 is done
        
!$OMP PARALLEL PRIVATE (i,j,k,maxaj,maxai,sum1,amaxak,TOPij) 
!$OMP DO SCHEDULE(STATIC,chunk)        
        do j = 2, nn                   !...loop for COL from 2 to nn
           maxaj=maxa(j) + j 
           do i = ColTop(j), j - 1     !...loop for ROW from top going down to diagonal

                !...wait intill Colum 'i' is done    
                do while(ColDONE(i) .ne. 1)
                end do
                
                sum1 = 0.0d0
                TOPij = Max(ColTop(i), ColTop(j))     !...find min column height for dot product

                maxai=maxa(i) + i 
                do k = TOPij, i - 1
                    sum1 = sum1 + a(maxai- k) * a(maxaj - k)
                end do
                a(maxaj - i) = (a(maxaj - i) - sum1) / a(maxai - i)
                
            end do

            !...do diagonal term J separatelly
            sum1 = 0.0d0
            do k = ColTop(j), j-1
                amaxak=a(maxaj - k)
                sum1 = sum1 + amaxak * amaxak
            end do
            
            a(maxa(j)) = dSqrt(a(maxa(j)) - sum1)
            ColDONE(j) = 1    !...colum 'j' is done
                       
        end do
!$OMP END DO
!$OMP END PARALLEL       
      
      return
      end    
    
    
  

I have run accross random results using a BLOCK, END BLOCK contstruct. My application was multi-threaded. When I move the local declarations into the parent procedure and remove the BLOCK construct the results become repeatable.

I am using implied AUTOMATIC for the project via /Qopenmp.

The help file does not mention this limitation of your implementation. Is it a bug or intentional ?

Using Visual Fortran Compiler XE 15.0.5.280.

Hi,

I am really hoping someone can help me with this (hopes Lionel's ears feel warm). We have this VBA code and cannot change it:

Private Declare Sub Func1 "Dll1.dll" _
 ByVal TEXT1 As String, _
 ByVal intTEXT1 As Long)

Dim TEXT1 As String * 49152

TEXT1 gets set to "string1    string2    string3    and so on" before calling:

Call FUNC1(TEXT1, Len(TEXT1))

The Fortran code being called (originally Compaq) is:

!DEC$ ATTRIBUTES STDCALL,REFERENCE :: FUNC1
SUBROUTINE FUNC1(TEXT1)
!DEC$ ATTRIBUTES DLLEXPORT :: FUNC1
!DEC$ ATTRIBUTES ALIAS: 'FUNC1' :: FUNC1
CHARACTER*(32) TEXT1(128, 12)

The problem is that even though we are compiling with the mixed string length argument option, Intel Fortran does not expect the string length and the VBA code crashes. The code half works if I do not pass the length from VBA (but keep in mind we cant change the VBA code permanently). Presumably Intel Fortran feels that the size of TEXT1 is fixed so it is not expecting a length argument (even though Compaq did).

So one idea is to to change the Fortran code as follows:

!DEC$ ATTRIBUTES STDCALL,REFERENCE :: FUNC1
SUBROUTINE FUNC1 (TEXT1B)

CHARACTER*(*) TEXT1B
CHARACTER*(32) TEXT1(128, 12)
TEXT1 = TEXT1B

And that works, Intel Fortran now expects a string length to be passed and the VBA code is happy and not crashing. Except that TEXT1 ends up being an array containing "string1", "string1", "string1" etc. instead of "string1", "string2", "string3" etc.

Any ideas on how to best fix this? We can change the Fortran code any way we like, but we cant change the VBA code.

Please and thank you.

Hi All,

I'm trying to save a write a derived type that contains a pointer to an unformatted file for later reading.  Below is a test version.  The derived type sol in module dType is separate because I'm patching together various Fortran codes (F95 and F77, etc).  The current version of the code "saves" sol1, but it seems to only save the pointer references, not their values, so when sol1 is deallocated, sol2 also becomes unreferenced.  I'm sure my hack on the UDTIO is not correct.

Any help would be appreciated (I'm still trying to figure out UDTIO).  Thanks

-joe

   module dType
      implicit none
      type, public :: sol
         integer:: n
         real(8), pointer:: vec(:)
      end type sol
   end module dType

   module dType_io
      use dType
      implicit none
   contains

   subroutine write_sol(dtv, unit, iostat, iomsg)
      class(sol), intent(in) :: dtv
      integer, intent(in)             :: unit
      integer, intent(out)            :: iostat
      character(*), intent(inout)     :: iomsg

      write(unit, iostat=iostat, iomsg=iomsg) dtv%n
      write(unit, iostat=iostat, iomsg=iomsg) size(dtv%vec)
      write(unit, iostat=iostat, iomsg=iomsg) dtv%vec
   end subroutine write_sol

   subroutine read_sol(dtv, unit, iostat, iomsg)
      class(sol), intent(inout)  :: dtv
      integer, intent(in)                 :: unit
      integer, intent(out)                :: iostat
      character(*), intent(inout)         :: iomsg

      integer allocSize

      ! read is sol type, but allocate pointer space as needed.
      read(unit, iostat=iostat, iomsg=iomsg) dtv%n
      read(unit, iostat=iostat, iomsg=iomsg) allocSize
      allocate( dtv%vec(allocSize) )
      read(unit, iostat=iostat, iomsg=iomsg) dtv%vec
   end subroutine read_sol
   end module dType_io

   program directAccess
      use dType
      implicit none
      integer, parameter :: dp = kind(0d0)
      type(sol):: sol1, sol2
      integer solUnit, n, sze
      integer i

      sol1%n = 10
      allocate( sol1%vec(sol1%n) )
      sol1%vec = [ (real(i),i=1,sol1%n) ]

      open(newunit=solUnit, file='test.sol', form='unformatted', status='replace', action='write')
      write(solUnit) sol1
      close(solUnit)

      open(newunit=solUnit, file='test.sol', form='unformatted', status='old', action='read')
      read(solUnit) sol2

      deallocate( sol1%vec ); nullify(sol1%vec) ! this will cause sol2 to lose reference

      close(solUnit)
      stop
   end program directAccess

hello everybody

i have received a fortran code, i don't know that which version of fortran is it??

prat of this code is here:

<< PROGRAM CSTGRD
PARAMETER(IP=51,JP=100,NX=35,NY=61,LX=500,LY=500,IPW=25,IPE=25,
1 JPS=25,JPN=25,JPT=(JPS+JP+JPN),IPT=(IPW+IP+IPE)
2 ,NPR=(10*(NX+NY-2)+1),NSEC=10)
COMMON XV(IP),YV(JP),XS(NPR),YS(NPR),IS(NPR),JS(NPR),
1 ISC(NPR),JSC(NPR),XV1(LX),YV1(LY),SMX(LX),SMY(LY),
2 SX1(10),SY1(10),NL(20),XINT(20),XSD(NPR),YSD(NPR),
3 SMD(LX),XVE(IPE),XVW(IPW),YVS(JPS),YVN(JPN),XVT(IPT),
4 YVT(JPT),SX2(10),SY2(10)
COMMON DSMX(LX),DSMY(LY),XSN(NPR),YSN(NPR),XSS(NPR),
1 YSS(NPR),ISCN(NPR),JSCN(NPR),ISCS(NPR),JSCS(NPR)
2 ,KT(LX),DSMD(LX),T(IP,JP),DSM0(LX),LSTPS(NSEC),LSTPN(NSEC)
COMMON XCN(NX),YCN(NX),XCS(NX),YCS(NX),XCE(NY),YCE(NY),
1 XCW(NY),YCW(NY),XC(NX,NY),YC(NX,NY),XCL(NX,3*JP),
2 YCL(NX,3*JP),XCLD(3*JP),YCLD(3*JP),LSTPE(NSEC),LSTPW(NSEC),
3 LSTP(NSEC),ISHP(NSEC),X1(NSEC),Y1(NSEC),X2(NSEC),Y2(NSEC),
4 THT(NSEC),IARC(NSEC),IFLG(IP,JP),NPIS(NX)
COMMON ELN(NX,NY),ELS(NX,NY),COSNX(NX,NY),COSNY(NX,NY),
1 COSNZ(NX,NY),COSSX(NX,NY),COSSY(NX,NY),COSSZ(NX,NY)
COMMON NS,NI,NIM1,NJ,NJM1,NP,MI,MJ,NMD,NST,NRT,ISE,ISW,JSN,JSS
1 ,NIW,NIE,NIT,NJS,NJN,NJT,ISMX,NSCS,NSCN,LSCS,LSCN >>

when i debug it with "intel visual fortran composer XE 2011" i receive many errors like:

Error 1 error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: <IDENTIFIER> C:\Users\mohammad\Desktop\fortran\mesh\mesh\mesh.f90 2

Error 2 error #5082: Syntax error, found ',' when expecting one of: <END-OF-STATEMENT> ; C:\Users\mohammad\Desktop\fortran\mesh\mesh\mesh.f90 3

Error 3 error #5276: Unbalanced parentheses C:\Users\mohammad\Desktop\fortran\mesh\mesh\mesh.f90 4

Error 4 error #5082: Syntax error, found ',' when expecting one of: BLOCK BLOCKDATA PROGRAM MODULE TYPE BYTE CHARACTER CLASS DOUBLE DOUBLECOMPLEX ... C:\Users\mohammad\Desktop\fortran\mesh\mesh\mesh.f90 4

Error 5 error #5082: Syntax error, found ')' when expecting one of: , <END-OF-STATEMENT> ; C:\Users\mohammad\Desktop\fortran\mesh\mesh\mesh.f90 4

and many other. now i have one questions:

Is this code in another version if fortran like 77...? i mean that i should change my compiler??? if yes how i can download and access it??

I’ve been working with the EFDC model (Environmental Fluid Dynamics Code, an EPA-endorsed model https://www.epa.gov/exposure-assessment-models/environment-fluid-dynamics-code-efdc-download-page) on Linux, but have recently been tasked with making the code compatible with Windows 10. I compiled the code with the Intel Fortran v16 compiler, went through some minor compatibility changes, and then successfully compiled the code in both Debug and Release modes. However, when I try to open the executable on Windows 10, I am met with an error message that says that “This app can’t run on your PC.” 

I read several posts here related to 32 vs. 64 bits compatibility and I recompiled the code with x86 and x64 options and tried with no luck in XP and different flavors of w7 and 10 (32 and 64 bits installations). So that does not seem to be the problem. I also tried compiling with both static and dynamic libraries and with an older version of Visual Studio 2010 with Intel Fortran 2015 that I have on the XP machine and all versions of the compilation are met with the same error. 

For a sanity check, I recompiled the exact same code in Linux with Intel Fortran 2016. It compiled flawlessly and the executable runs without issue. In addition, I compiled in both XP and w10 other programs different than EFDC that I have to check if there might be a problem with the compiler or VS installations, but they compiled and run as expected.

We are suspecting that perhaps the problem might be that EFDC modified for our application is large and requires a bit of memory. This generates a large executable when compiled (the .exe is 43 MB). Could this be an issue with Windows and not Linux versions? 

I search the forums and documentation but cannot find any reference to this strange behavior. I’m really not sure what to do next. Any suggestions as to what the problem might be or what additional diagnostics I could run to get to the bottom of this? I really appreciate your help!

I have a problem that probably has a simple answer. When I install the sample NQueens Fortran program, it works as I would expect. However, when I try to create a simple program that prints "Hello world," I get no output. Specifically, I fire up Intel Parallel Studio XE 2016 for Windows, choose File->New->Project and select Console Application and pick Main Program Code. The code template that automatically shows up just prints "hello world." I then pick Build, open PowerShell, go to the Debug folder, and run the program Console1.exe. Nothing happens. If instead I use the Command window, then instead I get the error message "The program can't start because libifcoremdd.dll is missing from your computer."

I have looked through the configuration and compared it to the NQueens configuration, and I don't see any obvious difference.

Thanks for any help.

Hello, 

I am trying to install the Intel(R) Parallel Studio XE 2016 Update 3 Composer Edition for Fortran and C++ Windows and I keep getting the following error message:

Intel(R) Parallel Studio XE 2016 Update 3 Composer Edition for Fortran and C++ Windows* Setup Wizard ended prematurely because of an error(s).
  Execution of installation process failed.
    Module name: vs_isoshell.exe
    Application returned error code: -2147205120

My goal is to add on the Intel(R) Visual Fortran Composer XE 2013 SP1 Update 6 for Windows* to be able to use the 2013 Fortran composer. 

Your assistance is greatly appreciated. 

J. Song

I have updated my compiler to the latest released fortran and compiled my code.  Immediately I started getting crashes when reading unformatted sequential binary files; the complaint is that a record has too little data.  My binary data files have not changed for a decade.  Neither did the source code.

If I change the compilation of a source file that does the reading from /O3 to /Od the code runs fine.  Reading the generated assembler I can see that the code is quite different between these, but without documentation for for_read_seq and for_read_seq_xmit I cannot find the bug myself.

I am using Fortran 16.0 Update 3, x64 code.

I can simplify this to a single file that demonstrates the problem.  Please let me know what to do with it.  (How/where to post, etc.)

Has anyone else seen such a thing?  

I would like to get back to work without waiting for a new release to fix the problem.  Turning off optimization is an obvious workaround, but I cannot afford to turn it off globally, and it would not be nice to have to change compile options on the dozens of individual source files that read binary data.  I am wondering how far I should roll back the compiler...

I would like to read read values with scientific notation from a text file. Values are delimited by tab and they can have different width, e.g. (tab is replaced by space in the example below).

 -1.15e+02 -2.156e+01 -3.1e+00 1.4256e+01

Is there a simple way of specifying such a format that would allow reading the text file in the following way?

OPEN ( UNIT=unitFile, FILE=filePathName, ACTION='READ', ACCESS='SEQUENTIAL', FORM='FORMATTED' )

do i=iMin,iMax
  READ ( unitFile, '(a1)', ADVANCE='NO' ) charTab
  READ ( unitFile, '(???)', ADVANCE='NO' ) valueDouble
enddo

I would like to avoid having to parse each line in the text file. If parsing cannot be avoided in this case, how could I obtain a value represented by a substring of a line?

Hi all,

here a simple example of interdependent derived types:

MODULE m_common

   USE, intrinsic :: iso_fortran_env

   implicit none

   integer, parameter :: ip = INT32
   integer, parameter :: rp = REAL64

   integer(ip), parameter :: n = 80400 , maxit = 1000

   integer(8) :: count , count_scale , count_max

   integer(ip) :: i , j , k

   real(rp) :: time , rate

   TYPE vec2d

      real(rp) :: x = 0._rp
      real(rp) :: y = 0._rp

   CONTAINS

      procedure, pass(self) :: equal_vec2d

      generic :: assignment(=) => equal_vec2d

   END TYPE vec2d

CONTAINS

   PURE ELEMENTAL SUBROUTINE equal_vec2d( self , from )

      class(vec2d), intent(inout) :: self
      class(vec2d), intent(in   ) :: from

      self%x = from%x
      self%y = from%y

   END SUBROUTINE equal_vec2d

END MODULE m_common

MODULE m_data

   USE m_common

   implicit none

   TYPE subdata

      type(vec2d) :: vector

   END TYPE subdata

   TYPE somedata

      type(subdata), allocatable :: sub_array(:)

   END TYPE somedata

END MODULE m_data

PROGRAM test

   USE m_common
   USE m_data

   type(somedata) :: totest

   type(vec2d) :: vector

   call system_clock( count , count_scale , count_max )

   rate = real( count_scale , 8 )

   allocate( totest%sub_array( n ) )

   time = real( count , 8 )

   do i = 1,maxit

      do k = 1,n

         vector = totest%sub_array( k )%vector

      end do

   end do

   call system_clock( count , count_scale , count_max )

   write(6,'(ES10.2)') ( real( count , 8 ) - time ) / rate

END PROGRAM test

If I compile this program with ifort and gfortran, I obtain these time computation results:

ifort -O3 test_all.f90 -o exe ; ./exe
6.95E-04

gfortran -O3 test_all.f90 -o exe ; ./exe
6.76E-04

At this time, no problem. Now, if I split in 3 programs test1.f90 test2.f90 and test3.f90, I obtain these results:

ifort -O3 test1.f90 test2.f90 test3.f90 -o exe ; ./exe
1.04E+00

ifort -O3 -ipo test1.f90 test2.f90 test3.f90 -o exe ; ./exe
7.45E-04

gfortran -O3 test1.f90 test2.f90 test3.f90 -o exe ; ./exe
3.17E-01

gfortran -O3 -flto test1.f90 test2.f90 test3.f90 -o exe ; ./exe
1.01E-01

So, time computation differences are very very big, and I do not understand what can really explain such differences, just accessing in memory to the main derived type array values with a very short stride

If interprocedural optimization with ifort gives me back the same performance than with only one file program, it is not the case with gfortran even if an effect is found

There is a way to compile separately my modules in order to use them efficiently in a very large program calling them a lot without ipo flag ??? maybe compiling a static or shared library with my modules and then link it to my main program ???

Fred

Hi,

This is my first post, so apologies if this is in the wrong place.

I am trying to perform an analysis with a user subroutine in Abaqus. The analysis is being called from MATLAB using the dos command, rather than being launched from the Abaqus command window.

When I try to run the analysis, I receive an error of "LINK: fatal error LNK1181: cannot open input file 'msmpi.lib'"

I have been troubleshooting the the setup on my machine with information from forums for a few days now, and I am stuck.
I am running:
win7
Abaqus 6.14-2
Visual Studio 2008 (with C++ and SDK)
Composer XE 2011

I'm guessing that msmpi.lib isn't properly located by my environment variables, but I have no idea where it is. Any help is appreciated, as this is not my area of expertise.
Before I call abaqus from the dos command, I call ifortvars.bat, as well as vcvars64.bat.

Thank you for any help.

I know this seems to be a common issue from what I've seen on this forum, but I can't seem to get around it.

I've installed Microsoft Visual Studio 2015 on a Windows 10, 64-bit computer along with Intel Parallel Studio XE 2016.

I've been trying to compile some fortran code using the Intel Compiler, but I keep getting the same error saying that 'ifort' is not recognized as an internal or external command, operable program or batch file.'

When I looked at my program files folder, I've found 3 different ifort.exe files in different folders (intel64_mic, intel64_ia32,intel64,ia32) as well as compilervars.bat in the main bin folder. I am relatively new to all this, and I do not know how to set an argument in this file, when it asks me in the command line (I saw this solution on another thread here).

Please help me solve this problem.

Thank you,

Aditya Khuller

Arizona State University