Dear all,

I have an issue with a Fortran code that I am trying to parallelize using OpenMP. This is a code for Monte Carlo particle transport and it has several COMMON blocks that I marked as private using the THREADPRIVATE directive. A (very very very small) example of this code could be:

PROGRAM TUTOR2

IMPLICIT NONE

[ VARIABLES DEFINITIONS, COMMON BLOCKS, ETC]

C$OMP PARALLEL DO

     DO I=1,NCASE

           CALL SHOWER([ARGS])

     END DO

C$OMP END PARALLEL DO



END PROGRAM TUTOR2



SUBROUTINE SHOWER

IMPLICIT NONE

[ VARIABLES DEFINITIONS, COMMON BLOCKS, ETC ]

C$OMP THREADPRIVATE(/RANDOMM/)

[ A LOT OF CODE ]

RETURN

END

 

Well, as you can see the COMMON block /RANDOMM/ is first declared inside a SUBROUTINE (in this case SHOWER) and not the main program. This happens with a lot of COMMON blocks with this code. The variables inside RANDOMM block are initialized inside another subroutine before the PARALLEL DO directive. Therefore, I need to copy the values of RANDOMM block from the master thread to the slave threads, but as this block is first declared inside a subroutine I cannot use the COPYIN clause.

Is there a better approach to this problem than declaring all the COMMON blocks needed as private in the main program?. Thanks for your help!. 

Hi,

With Linux OS we could use the linker option -cxxlib in order to link C libraries. I am trying to migrate my fortran project from Linux to Windows, and I cannot find an equivalent option. Is there an other solution?

Regards,

Emilie Hardy.

I would like to parallelise certain parts of my fortran project and to start with changed the enable coarrays parameter to For Shared Memory (/Qcoarray:shared).  The program recompiled and linked successfully but when I run it it fails dramatically at a read from disc file.  It seems that the file is trying to be write to the file in parallel although I have not requested this as I get a number of severe(47) write to read only errors.

I suppose I am being naive but I hoped that without adding any coarray commands the program would simply run as before?

Thanks,  ACAR.

Hi,

is there any extension available to use the PDEP/PEXT bit operations in Fortran? Is there any plan to add bit manipulations like that to the Fortran standard?

greetings,

Steven

The following code generates an internal compiler error with 14.0.3.202:

MODULE rng_state
  TYPE StateType
    INTEGER, ALLOCATABLE :: s(:)
  END TYPE StateType
  TYPE (StateType) :: state
CONTAINS
  SUBROUTINE get()
    INTEGER :: i
    CALL RANDOM_SEED(size=i)
    IF (.NOT. ALLOCATED(state%s)) ALLOCATE( state%s(i) )
    CALL random_seed(get=state%s)
  END SUBROUTINE get
END MODULE rng_state

Hi

I am implementing offload of an existing Fortran openMP region to Xeon Phi and have run into a few issues ...

I run the latest version of parallel studio 2013 with visual studio 2012 on Windows server 2008 R2.

1: Specifically, I call mkl_set_num_threads, mkl_set_dynamic, ZGETRS and ZGETRF inside my offload region and all of them return a runtime error:

On the sink, dlopen() returned NULL. The result of dlerror() is "/var/volatile/tmp/coi_procs/1/52855/load_lib/AarhusInv64IdebugMIC.out: undefined symbol: mkl_set_dynamic_"

2: Will offload of Fortran derived types including allocatable variables and type bound procedures be supported in the up-coming compiler version 15? This limitation really puts restrictions on the types of offload scenarios feasible ... :-(

Thanks!

C

I have written a fortran windows application,  wherein the main window uses the right and bottom scroll bars as well as being able to scroll via the mouse in the middle of the screen. The problem is when I put in quite a lot of information on the window the window gets corrupted and information is lost - is it that i am overloading the window  and would I need to do something like clear of flush buffer so that when I run with large amounts of data the application works OK

regards Steve Konasrki

Hello Steve Lionel,

This is a SOS.  I have old FORTRAN files (F77 version) in a folder on my desktop.  What I need to do is to compile and run these files.  I am using Windows and have Intel Visual FORTRAN with IMSL libraries.  The steps I used are as below:

1.  Open the Fname.for file using Microsoft Visual Studio 2008.

2.  Now from the "File" menu (top left hand corner of the pane), I am choosing the "Add to Existing Project" or "Add to New Project".

3.  Then I am going to the "Build" menu (top of the pane) and using the option "Build Solution"

On the solution pane I am getting the message: 0 errors 0 warnings (means that compilation is done).

4. Now when I am trying to run the program by choosing "Start without Debugging" -the problem crops up and the message says: "Unable to Start Program 'C\Users\chatd\Desktop....\Special Function\Debug\Special Function.exe'  "

The System cannot find the file specified.  

I do not know how to resolve this problem as I cannot locate the *.exe file either.  Need URGENT help on this.  Any pointers?  

- thanks,

Deb Chatterjee 

Additional Intel® Advanced Vector Extensions 512 (Intel® AVX-512)

The Intel® Architecture Instruction Set Extensions Programming Reference includes the definition of additional Intel® Advanced Vector Extensions 512 (Intel® AVX-512) instructions.

As I discussed in my first blog about Intel® AVX-512 last year, Intel AVX-512 will be first implemented in the future Intel® Xeon Phi™ processor and coprocessor known by the code name Knights Landing.

We had committed that Intel® AVX-512 would also be supported by some future Intel® Xeon® processors scheduled to be introduced after Knights Landing. These additional instructions we have documented now will appear in such processors together with most Intel® AVX-512 instructions published previously.

These new instructions enrich the operations available as part of Intel® AVX-512. These are provided in two groups. A group of byte and word (8 and 16-bit) operations known as Byte and Word Instructions, indicated by the AVX512BW CPUID flag, enhance integer operations. It is notable that these do make use of all 64 bits in the mask registers. A group of doubleword and quadword (32 and 64-bit) operations known as Doubleword and Quadword Instructions,  indicated by the AVX512DQ CPUID flag, enhance integer and floating-point operations.

An additional orthogonal capability known as Vector Length Extensions provide for most AVX-512 instructions to operate on 128 or 256 bits, instead of only 512. Vector Length Extensions can currently be applied to most Foundation Instructions, the Conflict Detection Instructions as well as the new Byte, Word, Doubleword and Quadword instructions. These AVX-512 Vector Length Extensions are indicated by the AVX512VL CPUID flag. The use of Vector Length Extensions extends most AVX-512 operations to also operate on XMM (128-bit, SSE) registers and YMM (256-bit, AVX) registers. The use of Vector Length Extensions allows the capabilities of EVEX encodings, including the use of mask registers and access to registers 16..31, to be applied to XMM and YMM registers instead of only to ZMM registers.

Emulation for Testing, Prior to Product

In order to help with testing of support, the Intel® Software Development Emulator has been extended to include these new Intel AVX-512 instructions and will be available very soon at http://www.intel.com/software/sde.

Intel AVX-512 Family of instructions

Intel AVX-512 Foundation Instructions will be included in all implementations of Intel AVX-512. While the Intel AVX-512 Conflict Detection Instructions are documented as optional extensions, the value for compiler vectorization has proven strong enough that they will be included in Intel Xeon processors that support Intel AVX-512. This makes Foundation Instructions and Conflict Detection Instructions both part of all Intel® AVX-512 support for both future Intel Xeon Phi coprocessor and processors and future Intel Xeon processors.

Knights Landing will support Intel AVX-512 Exponential & Reciprocal Instructions and Intel AVX-512 Prefetch Instructions, while the first Intel Xeon processors with Intel AVX-512 will support Intel AVX-512 Doubleword and Quadword Instructions, Intel AVX-512 Byte and Word Instructions and Intel AVX-512 Vector Length Extensions. Future Intel® Xeon Phi™ Coprocessors and processors, after Knights Landing, may offer additional Intel AVX-512 instructions but should maintain a level of support at least that of Knight Landing (Foundation Instructions, Conflict Detection Instructions, Exponential & Reciprocal Instructions, and Prefetch Instructions). Likewise, the level of Intel AVX-512 support in the Intel Xeon processor family should include at least Foundation Instructions, Conflict Detection Instructions, Byte and Word Instructions, Doubleword and Quadword Instructions and Vector Length Extensions whenever Intel AVX-512 instructions are supported. Assuming these baselines in each family simplifies compiler designs and should be done.

Intel AVX-512 support

Release of detailed information on these additional Intel AVX-512 instructions helps enable support in tools, applications and operating systems by the time products appear. We are working with open source projects, application providers and tool vendors to help incorporate support. The Intel compilers, libraries, and analysis tools have strong support for Intel AVX-512 today and updates, planned for November 2014, will provide support for these additional instructions as well.

Intel AVX-512 documentation

The Intel AVX-512 instructions are documented in the Intel® Architecture Instruction Set Extensions Programming Reference. Intel AVX-512 is detailed in Chapters 2-7.

Hello everybody,

In the module i'm writing, I'm using a module called FluidProp that uses DWINTY. I have seen on a help page that there are conflicts with the null statement, and that it could be resolved by writing 'USE DFWINTY, NULL0=>NULL' so that NULL and NULL0 can be used throughout the program. 

I am still getting the aforementioned error (This is not a valid initialization expression) when I write the suggested correction.

Here is what I'm typing to get the error:

TYPE :: steam_perfor_type
    CHARACTER(8):: name
    DOUBLE PRECISION    ::  TC, HRSG, BC, CC, Pdiff, error, Q, P_TC, P_CC
END TYPE steam_perfor_type
TYPE(steam_perfor_type),TARGET :: steam_perform
TYPE(steam_perfor_type),POINTER :: perf=>NULL( )

Any help would be greatly appreciated.

Hi all,

I'm investigating a problem that I could boild down to basically the array initialization - which does not really seem to give me any speedup on Windows OS.

Consider the following piece of code:

integer, dimension(:), allocatable :: a
integer :: dim=8000000
integer i

allocate(a(1:dim))

!$OMP PARALLEL DO
do i=1,dim
   a(i)=0
enddo
!$OMP END PARALLEL DO

Then I do virtually get no speedup out of the parallel region.

Is this intended to be, or am I doing something stupid wrong ?



I was thinking that there are different NUMA-issues on Windows making the First-touch policy from Linux OS being "less valid" on Windows. However, I do observe the problem also when limiting myself to a single socket.

I've noticed that the CORE-AVX2 or xHost option sometimes produces AVX-128 code (about equivalent to SSE) where the AVX option produces AVX-256.  I've submitted a premier report in case this may be accepted as a bug.

It seems I was over-confident in assuming that AVX2 should perform at least as well as AVX. Such expectation seems to work out more often with F77 source code in conjunction with testing the various directives (much ifdefing of directives by architecture).  !dir$ simd or vector aligned may work with array assignment, but of course !$omp simd does not.

In some of these cases, /QaxAVX2 removes vectorization entirely even though /QaxAVX produces both AVX and SSE2 vector code.  The vector speedup estimate shows that SSE vectorization would kill performance (on some long-disappeared CPU?) and the vec-report advises use of directives.  Unfortunately, directives ruin performance sometimes when there is good vectorization without them.  Where I have to tinker with directives, the estimated vector speedup may be OK for one of the alternatives but wrong for others.

Vector speedup estimate is done through the vec-report7 option and python script with compilers 13.1 and 14.0.  It moves to opt-report4 with 15.0.  I'm guessing the numbers quoted there may relate to the "seems inefficient" diagnostic issued when the compiler decides not to vectorize.

I have a Visual Studio 2010 C dll that has a Intel Visual Fortran Composer XE 2011 static library that is linked to the C dll.  This dll is loaded from a third party tool that uses Ctrl + C to interupt its iterpreter to lauch its debugger.  However, the Ctrl + C is intercepted by the FORTRAN runtime and gives a forrtl: error (200): program aborting due to control-C event.  According to the documentation, a dll should not have the default fortran runtime signal handling.  Does anyone know if there are some compiler settings that can be set on the static library to prevent it from causing the runtime signal handling to intercept the control-C.

I have a Fortran test driver which calls a function in a DLL.  The DLL is built as a C++ project.  The C++ project links an Intel Fortran built LIB of various Fortran subroutines, together with C++ code which contains C++ interfaces to the Fortran functions.  These are for our various C++ / C# GUIs to call.  However I do my testing on these LIB functions with my Fortran driver.  The problem is I am getting invalid debug information for the arrays.  All projects have Debug:Full set.  Here is what the Watch window looks like:

        Fmid_ds    #101B2108    PROCEDURE 
        BlackOilData    #0044C34C    PROCEDURE 
        Weight_fact_data_     Invalid Debug Information    
        Expt_data_     Invalid Debug Information    
+        Ierr    {...}    REAL(8) 

All the above top 4 variables are arrays, and in fact the last, Ierr, is a scalar integer.

The code seems to work fine, but the debug information is not there.  In the Output window I see:

'ViscCorrelations.exe': Loaded 'D:\Tech\Tests\Drivers\DLLHTest\Debug\ViscCorrelations.exe', Symbols loaded.

'ViscCorrelations.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll', Cannot find or open the PDB file

'ViscCorrelations.exe': Loaded 'C:\Windows\SysWOW64\kernel32.dll', Cannot find or open the PDB file

'ViscCorrelations.exe': Loaded 'C:\Windows\SysWOW64\KernelBase.dll', Cannot find or open the PDB file

'ViscCorrelations.exe': Loaded 'D:\Tech\Dev\TechRefactoring\bin\Debug\ViscTune.dll', Symbols loaded.

'ViscCorrelations.exe': Loaded 'C:\Windows\SysWOW64\imagehlp.dll', Cannot find or open the PDB file

'ViscCorrelations.exe': Loaded 'C:\Windows\SysWOW64\msvcrt.dll', Cannot find or open the PDB file

'ViscCorrelations.exe': Loaded 'C:\Windows\SysWOW64\advapi32.dll', Cannot find or open the PDB file

'ViscCorrelations.exe': Loaded 'C:\Windows\SysWOW64\sechost.dll', Cannot find or open the PDB file

'ViscCorrelations.exe': Loaded 'C:\Windows\SysWOW64\rpcrt4.dll', Cannot find or open the PDB file

'ViscCorrelations.exe': Loaded 'C:\Windows\SysWOW64\sspicli.dll', Cannot find or open the PDB file

'ViscCorrelations.exe': Loaded 'C:\Windows\SysWOW64\cryptbase.dll', Cannot find or open the PDB file

'ViscCorrelations.exe': Loaded 'C:\Program Files (x86)\Intel\Composer XE 2013 SP1\redist\ia32\compiler\libifcoremdd.dll', Binary was not built with debug information.

'ViscCorrelations.exe': Loaded 'C:\Program Files (x86)\Intel\Composer XE 2013 SP1\redist\ia32\compiler\libmmd.dll', Symbols loaded (source information stripped).

'ViscCorrelations.exe': Loaded 'C:\Windows\SysWOW64\msvcr100d.dll', Symbols loaded.

So it finds the PDB OK.

I get the same problem if I call the C++ interface function or the Fortran function directly.

Any idea?

Adrian

I am unable to get the "classic" list example in Modern Fortran Explained - Michael Metcalf, John Reid and Malcolm Cohen, Oxford University Press, 2011, ISBN 978-0199601417 to work with Intel Fortran; both compiler version 14 or 2015 Beta are able to compile the code ok, but encounter run-time errors as follows:

 The initial list has 0 items.
 The list now has 1 items.
 The list now has 2 items.
 The list now has 3 items.
 The list now has 4 items.
 The first element is:  character = "hello"
 The last element is:  real =  2.250000
 After deleting the last element, the list contents are:
 Item 1: character = "hello"
 Item 2: integer =  17
 Item 3: character = "world"
forrtl: severe (157): Program Exception - access violation
Image              PC        Routine            Line        Source
TestFor32.exe      00EF5958  _ANYLIST_M_mp_REM         261  TestMod.f90
TestFor32.exe      00EF39A5  _ANYLIST_M_mp_DEL         180  TestMod.f90
TestFor32.exe      00EF2309  _ANYLIST_M_mp_DEL          94  TestMod.f90
TestFor32.exe      00EF7F13  _MAIN__                    33  TestFor.f90
TestFor32.exe      00F68782  Unknown               Unknown  Unknown
TestFor32.exe      00F691DA  Unknown               Unknown  Unknown
TestFor32.exe      00F6932D  Unknown               Unknown  Unknown
kernel32.dll       7576338A  Unknown               Unknown  Unknown
ntdll.dll          76F5BF32  Unknown               Unknown  Unknown
ntdll.dll          76F5BF05  Unknown               Unknown  Unknown

Note I'm using the latest edit to the code made available kindly by Metcalf et al. at  ftp://ftp.numerical.rl.ac.uk/pub/MRandC/oo.f90.  

It appears this was a known issue back on March 19, 2012 based on comments by Tim Price and Steve Lionel at this comp.lang.fortran forum topic: however, I don't know if a tracking incident was issued on the Intel side and if there is any way to check the status.

Can someone from Intel please provide some feedback on this example:

• Per Metcalf et al. (and who the Fortran world would regard among the leading authorities, if not the ultimate authority, on Fortran 2003 standard) consider this example to be worthy of a test case for Fortran 2003 - see here.  Does Intel agree with Metcalf et al.?  Note Metcalf indicates they have successfully tested the code with other compilers (possibly NAg compiler?).
• If yes, is this code really part of Intel's test suite?  And if so, what is the plan to get this working?
• If not, why not - is there something wrong with the code?!  Can Intel provide an alternate object-oriented list example based on Fortran 2003 that works?
• It appears with 2015 compiler version, Intel hopes to claim full Fortran 2003 compliance with phrases such as "Fortran now has complete Fortran 2003 support" in their What's New document.  If Intel feels strongly about this, it will be nice if Intel can first strive to get the compiler working with this textbook example, or offer an adequate explanation and guidance so its users are not left confused with the very basic books on Fortran.

Thanks,

dear all,

this is my problem:

when I try to run the mpirun I get the following error:

/opt/intel/composer_xe_2013.5.192/mpirt/bin/intel64/mpirun: 96: .: Can't open /opt/intel/composer_xe_2013.5.192/mpirt/bin/intel64/mpivars.sh

I do not have intel MPI, this means that is not a problem between the MPI and openMPI.

Thanks a lot to everyone

Consider the following trivially simple program :

PROGRAM p

   IMPLICIT NONE

   !.. Local variables
   CHARACTER(LEN=2) :: StrBuffer
   INTEGER :: I

   I = 1
   WRITE(StrBuffer, FMT='(I2)') I

   !..
   STOP

END PROGRAM p

When the code is compiled with Intel Fortran (version 14 or 2015 Beta) and the program is executed, Dr Memory utility indicates there is a memory leak associated with the WRITE statement.  The output generated by the utility is as follows:

         Dr. Memory version 1.7.0
         Running "Debug\TestFor32.exe"

         Error #1: LEAK 12 bytes
         replace_malloc
             d:\drmemory_package\common\alloc_replace.c(2320):
         for__get_vm
             ??:0
         for__acquire_lun
             ??:0
         for_write_int_fmt
             ??:0
         P
             TestFor.f90(10):
         main
             ??:0

         ERRORS FOUND:
               0 unique,     0 total unaddressable access(es)
               0 unique,     0 total uninitialized access(es)
               0 unique,     0 total invalid heap argument(s)
               0 unique,     0 total GDI usage error(s)
               0 unique,     0 total handle leak(s)
               0 unique,     0 total warning(s)
               1 unique,     1 total,     12 byte(s) of leak(s)
               0 unique,     0 total,      0 byte(s) of possible leak(s)
         Details: C:\..\DrMemory-TestFor32.exe.4680.000\results.txt

Can someone at Intel please investigate and provide feedback on this memory leak?  In one of my codes, such a WRITE operation on an internal file can occur many times and there are some performance issues with this code, hence I appreciate any clarification any one can provide.

Thanks,

The following code generates an internal compiler error with compiler version 2015 Beta:

MODULE m

   !..
   IMPLICIT NONE

   !..
   PRIVATE

   TYPE :: s

      !..
      CHARACTER(LEN=:), ALLOCATABLE :: q
      PROCEDURE(fabs), NOPASS, POINTER :: p

   END TYPE s

   TYPE :: t

      INTEGER :: i1
      TYPE(s) :: bar

   CONTAINS

      PRIVATE
      PROCEDURE, PASS(This) :: f

      PROCEDURE, PASS(This), PUBLIC :: s2

   END TYPE t

   INTERFACE

      PURE FUNCTION fabs(This) RESULT(RetVal)
         IMPORT :: t
         !.. Argument list
         CLASS(t), INTENT(IN) :: This
         !.. Function result
         INTEGER :: RetVal
      END FUNCTION fabs

   END INTERFACE

CONTAINS

   PURE FUNCTION f(This) RESULT(RetVal)

      !.. Argument list
      CLASS(t), INTENT(IN) :: This
      !.. Function result
      INTEGER :: RetVal

      RetVal = This%i1

      RETURN

   END FUNCTION f

   SUBROUTINE s2(This)

      CLASS(t), INTENT(INOUT) :: This

      This%bar = s("s1", f)

      RETURN

   END SUBROUTINE s2

END MODULE m

The output is as follows:

------ Build started: Project: TestFor, Configuration: Release|Win32 ------

Compiling with Intel(R) Visual Fortran Compiler XE 15.0.0.070 [IA-32]...
m.f90
C:\..\sor\m.f90(62): catastrophic error: **Internal compiler error: internal abort** 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 C:\..\sor\m.f90 (code 1)

Build log written to  "file://C:\..\Release\Win32\TestForBuildLog.htm"
TestFor - 1 error(s), 0 warning(s)

Hello,

When I compile my project, I obtain "relocation truncated to fit" errors. However, these errors disappear if I add the -openmp flag to my compiler options, even though I am not actually using any open mp directives in my code. When I use -openmp, what memory options are being set that avoid these relocation truncated to fit errors? I feel I should be using these, rather than just setting the openmp flag.

Thanks

Hello everybody. I posted an issue a few days back, and unfortunately another one made its appearance.

My project built smoothly (with warnings on the FluidProp module, my supervisor used the module before and told me that I should expect them) under the Win32 platform but as I ran it, it wouldn't go past one a basic instruction of opening and reading a file as you can see on this extract of my program.

Program gas1sv3

use FluidProp

character(18) :: namefile1="Input.DAT"
INTEGER :: iop

open(unit=20,iostat=iop,file=namefile1,action="read")
      if (iop/=0) then
      write(*,'(a)') "ERROR: unable to open file ",namefile1
      pause
      stop
      end if

	READ(20,*) GT !PLANT LAYOUT (GT/CC)
	READ(20,*) CONFIGURATION ! CYCLE (BASELINE/ADVANCED)
	READ(20,*) WFFIDP !WORKING FLUID SELECTOR
	READ(20,*) FFDP !FUEL SELECTOR (DP)
	READ(20,*) NDP  !SHAFT SPEED IN RPM
	READ(20,*) W1DP !COMPRESSOR INLET MASS FLOW
	READ(20,*) P1DP !AMBIENT PRESSURE
	READ(20,*) T1DP !AMBIENT TEMPERATURE
      READ(20,*) INTPLOSSDP  !TOTAL PRESSURE LOSS IN INTAKE
	READ(20,*) M2DP !MACH NUMBER AT COMPRESSOR 1 ENTRY
	READ(20,*) CPOLYDP  !COMPRESSOR EFFICIENCY
	READ(20,*) CPRDP  !COMPRESSOR PRESSURE RATIO
	READ(20,*) CMapNb  !COMPRESSOR MAP NUMBER
close(20)

end program gas1sv3

My initial reaction was that the issue was that I ran the build under the Win32 platform on a 64bits proc, so naturally, I tried to build the project on the x64 platform. The build showed errors on the files of the FluidProp module.

FluidProp is a thermodynamic library that's free to use (http://www.asimptote.nl/software/fluidprop/fluidprop-details) and they provide files (see attached)  for you to call fluid properties in your program. When you install FluidProp they install both x64 and x86 versions. At that point I was even more conforted in the fact that the issue was the build under Win32 and not x64.

But as I ran the sample client for FluidProp (see attached) under the x64 platform, I get 10 errors (see buildLog) all of them being "the type of the actual argument differs from the type of the dummy argument" and the client cannot be ran. BUT when the sample client is ran under the Win32 platform it runs just fine.

So, I am kind of confused right now... Why won't my program open and read my file ? Is it because I should run all of the program in x64 -which I can't do for now as FluidProp shows errors- ? Or is it because I messed up in my initial program because FluidProp runs fine when compiled under Win32 ?