I'm trying to get linedraw characters. The documentation states

"Using QWIN$EXTENDFONT_OEM_CHARSET with the font name 'MS LineDraw'C will get the old DOS-style character set with symbols that can be used to draw lines and boxes."

But it gives no instruction or example on how to use it. What I am trying is

USE IFQWIN
TYPE (Windowconfig) wc
LOGICAL status
wc%fontsize = QWIN$EXTENDFONT
wc%extendfontname = 'MS Linedraw'C
wc%extendfontattributes = QWIN$EXTENDFONT_OEM_CHARSET
status = SETWINDOWCONFIG (wc)
IF (.NOT. status) status = WINDOWCONFIG (wc)

But this does not work. I am suspicious of the assignment of QWIN$EXTENDFONT_OEM_CHARSET to wc%extendfontattributes. Just guessing on this due to lack of documentation.

Hi Intel, Anyone,

I've been running an application in extended precision (REAL*16) for more years than I like to count and, finally, the time has come when I need it to execute faster. My impression is that all I can do is reduce, as far as possible, the number of extended precision multiply and divide operations. (This is what VTune tells me is what is taking the most time.) I can certainly do this, but is there more I should know?

Extended precision and its needs seems to be a neglected area of development. Two things caused me to write this post. (1) I received an email flyer for an Intel HPC Code Modernisation Workshop that offered, among other things to "Learn how to modernize your legacy code or develop brand-new code in order to maximize software performance on current and future Intel Xeon and Xeon Phi processors". I asked if there was anything in the workshop relevant to extended precision programs. Answer: "No". (2) I found that mutiplying two REAL*16 variables that are both equal to zero seemed to take a long time - perhaps as much as non-zero values. That isn't what I would have guessed (not being a computer scientist), and it makes me wonder if I should test whether values are equal to zero *before* multiplying them (to avoid the cost of that operation in terms of time). This is just one possible question of many.

If there is a good guide to optimisation of programs running in extended precision, please point me to it. It would be nice if someone at Intel would write that guide if it doesn't exist. Dr Fortran, perhaps? 

Thanks,

Simon C.

I perform system administration duties on a classified windows workgroup.  I need to purchase a named user license for the Intel® Parallel Studio XE 2013 Composer.  However, I will only be the installer/administrator of the software and only one specific user will actually use the software.  The specific user does not and will never have any kind of admin rights on the computer.  I have been told by third party providers that we would need to purchase a 2 user floating license to accomplish this approach. Is there a way to buy one named user license to accomplish this task?

Fortran gurus:

I'm looking for the fastest, safest, and most portable way to read the entire contents of a text file into a Fortran allocatable string.  Here's what I've come up with:

    subroutine read_file(filename, str)

    implicit none

    character(len=*),intent(in)  :: filename
    character(len=:),allocatable,intent(out) :: str

    !parameters:
    integer,parameter  :: n_chunk = 256      !chunk size for reading file [arbitrary]
    character(len=*),parameter :: nfmt = '(A256)'    !corresponding format statement
    character(len=1),parameter :: newline = new_line('')

    integer :: iunit, istat, isize
    character(len=n_chunk) :: chunk
    integer :: filesize,ipos
    character(len=:),allocatable :: tmp

    !how many characters are in the file:
    inquire(file=filename, size=filesize)  !is this portable?

    !initialize:
    ipos = 1    !where to put the next chunk

    !preallocate the str array to speed up the process for large files:
    !str = ''
    allocate( character(len=filesize) :: str )

    !open the file:
    open(newunit=iunit, file=trim(filename), status='OLD', iostat=istat)

    if (istat==0) then

        !read all the characters from the file:
        do

            read(iunit,fmt=nfmt,advance='NO',size=isize,iostat=istat) chunk

            if (istat==0) then

                !str = str//chunk
                str(ipos:ipos+isize-1) = chunk
                ipos = ipos+isize

            elseif (IS_IOSTAT_EOR(istat)) then

                if (isize>0) then
                    !str = str//chunk(1:isize)//newline
                    str(ipos:ipos+isize) = chunk(1:isize)//newline
                    ipos = ipos+isize+1
                else
                    !str = str//newline
                    str(ipos:ipos) = newline
                    ipos = ipos + 1
                end if

            elseif (IS_IOSTAT_END(istat)) then

                if (isize>0) then
                    !str = str//chunk(1:isize)
                    str(ipos:ipos+isize) = chunk(1:isize)//newline
                    ipos = ipos+isize+1
                end if

                exit

            else
                stop 'Error'
            end if

        end do

        !resize the string
        if (ipos<filesize+1) str = str(1:ipos-1)

        close(iunit, iostat=istat)

    else
        write(*,*) 'Error opening file: '//trim(filename)
    end if

    end subroutine read_file

Some notes/questions about this:

1. This routine will read the 100 MB file at https://github.com/seductiveapps/largeJSON in about 1 sec on my PC.
2. Is it really portable to use the SIZE argument of INQUIRE to get the number of characters? I notice that the string I end up with is somewhat smaller than this value, but that could be due to #3.  What is the portable way to get the file size in number of characters (I'd like it to also work on other non-ifort compilers, as well as on other platforms).
3. I don't think this way preserves the Windows line breaks (if present), since it essentially reads it line by line and then inserts the newline character. The string I end up with is smaller (which is why I'm trimming it at the end).  Is there a way to read it in a way that includes the line breaks as is?
4. The original (naive) version of the routine (see the commented-out bits, e.g., str = str//chunk) is extremely slow and also causes stack overflows for very large strings.  The slowness makes sense to me due to all the reallocations, but I didn't expect it to cause stack overflows.  Is that to be expected?
5. Any other improvements that anyone can see? 

Is it possible to initialize a character array using hex values for the bytes?

using character(10) :: ch = 

ie. it may contain non printable bytes such as 0x0D, etc

Hi,

I am an user of  

Intel® Parallel Studio XE Composer Edition for Fortran with Rogue Wave IMSL 7.0 for Windows*. 

I am able to compile and generate an executable but when I try to run the executable, I get the error message,"The program can't start because mkl_intel_thread.dll" is missing from your computer. Try reinstalling the program to fix this problem".  I realize that this very dll file is in fact found in "C:\Program Files (x86)\Intel\Composer XE 2015\redist\intel64\mkl" and I see this file.  Where and how do I set the path in VS2015 so that this file is accessed?

Thank you, 

Byung

Hi, 

I have followed the IMSL installation instruction per 

https://software.intel.com/en-us/articles/installing-and-using-the-imsl-...

but I get the following error message when I tried to compile, 

"fatal error LNK1104: cannot open file 'imslmkl_dll.lib'"

I can see this file in the folder

"C:\Program Files (x86)\VNI\imsl\fnl701\Intel64\lib"

I would appreciate your help.

Thanks,

Byung

In the following code, there is a difference in the qualifiers of the dummy argument:

MODULE mod1
  IMPLICIT NONE
CONTAINS

  SUBROUTINE sub1(arg1)
    REAL(KIND=8), ALLOCATABLE, OPTIONAL :: arg1(:)
    CALL sub2(arg1) ! <--- this is where the segfault happens
  END SUBROUTINE

  SUBROUTINE sub2(arg2)
    REAL(KIND=8), OPTIONAL :: arg2(:)  ! Here arg2 is not declared ALLOCATABLE
    IF(PRESENT(arg2)) THEN
      print *, "arg2 present"
    ELSE
      print *, "arg2 not present"
    END IF
  END SUBROUTINE
END MODULE

PROGRAM segfault1
  USE mod1
  CALL sub1()
END PROGRAM

For me, this program crashes with a segfault when compiled with ifort 15.0.2.179 on Windows, and 15.0.1.133 on Linux. However, when compiled with ifort 13.1.3.198 on Windows or gfortran 4.8.3 on Linux, it runs without error. The segfault can be avoided either by removing the ALLOCATABLE qualifier from arg1, or by adding it to the declaration of arg2.

Am I right that this code is supposed to work?

Øyvind

Dear all,

I am trying to create NetCDF files in Fortran using VS2008 and Intel Composer XE 2013 as compiler.

I tried with different pre-built libraries that I found on the web, and I managed to link the libraries to the program, so now I can compile the program without errors. The problem is that the program doesn't recognizes the commands of the library, so it doesn't work at all...

Any idea about how to fix it?

Thanks,

Jose

I tried changing the mouse cursor to an hour glass shape (IDC_WAIT) as per the example in the documentation (User and Reference Guide for the Intel® Fortran Compiler 15.0) except it is for a full Qwin and not Standard Graphics but it does not change unless I have a read statement following the SetMouseCursor statement. How do I get it to change without the read statement?

I realize you can have a forever loop as follows:

DO

Code etc.

ENDDO

But is there a way to do that with an index counter?

For example, I might want to loop with an index K thru

all positive possible values of K, if its an integer(4).

The only way I am using it now, is to put a very high number on the upper limit as follows:

KHIGH=2**31-1

Do K=1,KHIGH

code, etc.

enddo

The upper limit here is the high value for a 32 bit integer.

any ideas?

This might be a stupid question but I just found a bug in something I wrote earlier today and I was surprised the complier didn't have a little moan at me.

      character(12), parameter :: gudef(5)=(/'@@USER-DEF-1@@','@@USER-DEF-2@@','@@USER-DEF-3@@','@@USER-DEF-4@@','@@USER-DEF-5@@'/)

Those 14 character long strings don't fit that well in the 12 character spaces... 

It would whinge at me if they weren't all this same length but all the wrong length is OK?

Hi guys

I'm trying to optimize some matrix multiplication and in order to do that I need to do openmp reduction on a matrix (array), however once the array dimension gets even slightly large I get stack overflow problems, which I am not sure why I get.

    call KMP_SET_STACKSIZE_S(8000000)
    blocksize=800
    NUMA=8
    dim=blocksize*NUMA
    allocate(bA(dim,dim))
    allocate(bB(dim,dim))
    allocate(bC(dim,dim))
    print*, 'initiating first touch'
    call omp_set_num_threads(NUMA)
    !$OMP PARALLEL DEFAULT(SHARED) PRIVATE(i,first,last)
    !$OMP DO SCHEDULE(STATIC)
    do i=1,NUMA
        first=(i-1)*NUMA+1
        last=i*NUMA
        bA(:,first:last)=0.d0
        bB(first:last,:)=0.d0
        bC(:,first:last)=0.d0
    end do
    !$OMP END DO
    !$OMP END PARALLEL
    print*, 'first touch done'

    print*, 'Threads',omp_get_max_threads()
    Runtimebegin=omp_get_wtime()
    !$OMP PARALLEL DEFAULT(SHARED) PRIVATE(i,first,last) REDUCTION(+:bC)
    !$OMP DO SCHEDULE(STATIC)
    do i=1,NUMA
      first=(i-1)*blocksize+1
      call dgemm('N','N',dim,dim,blocksize,1.d0,bA(1,first),dim,bB(first,1),dim,0.d0,bC,dim)
    end do
    !$OMP END DO
    !$OMP END PARALLEL
    Runtimeend=omp_get_wtime()

When blocksize is 800 I get the stackoverflow problem, but when I put it down to 80 everything is okay.

I realize that by setting the array as reduction I implicitly make  a private copy of the array on each thread, but even so my memory should be plenty big to handle this.

Can anyone tell me how to get around this? Or at least what exactly I'm doing wrong, because so far I haven't found anything in Openmp documentation which can help me.

Cheers

Tue

Back in my day this was legal:

        write(52,'(a,<nc>e20.10)') '  Recombined_Comp  :', (Recombined_Comp(i), i=1,nc)

It still works but I get:

warning #6923: Fortran 2008 does not allow an expression to be used as part of the format list.   [NC]

How is this done these days?

in the old version like fortran 11.1.046, after the compilers are installed, it is necessary to source the ifortvars.sh or ifortvars.csh file to properly set the user environment to use the Intel compilers.

but now I install a new version (Intel® Parallel Studio XE 2015 Professional Edition for Linux) I fail to find out when the ifortvars.sh is,

can anybody give me the path of it? the compliers is installed under /opt/intel

How should ifdlg100.dll be deployed in an installer? On a machine without ifdlg100.dll  there isn't a problem but what should be done if there is an older or newer version of ifdlg100.dll already registered? It might be assumed that the most recent version would work with older IVF code. Is that the case? If so, should the older version be unregistered before the new version is registered or can there be multiple versions registered?

Hi,

I am receiving an error at compiling the "test" code below,"error #6303: The assignment operation or the binary expression operation is invalid for the data types of the two operands." The test code is a stripped down version of some bigger algorithm. The error occurs at IMSL BINOM routine. I believe I fulfilled the requirements on the input in BINOM, both inputs are integers, the output is real. I also have tried to compute integers b1=d-1 and b2=d+q-k, and use BINOM(b1,b2) instead, but it does not remove the problem. I would appreciate your help.

Best regards,

Natalia

PROGRAM test
INCLUDE 'link_fnl_shared.h'

    USE IMSL_LIBRARIES, ONLY: BINOM
    IMPLICIT NONE
    INTEGER(4)                :: d,k,q,minq,maxq      
    REAL(8)                    :: bq 
    
WRITE(*,*) 'Type 10'
READ(*,*) d
WRITE(*,*) 'Type 2'
READ(*,*) k

 minq = max(0,k-d)
 maxq = k-1
  DO q = minq,maxq
    bq = BINOM(d-1,d+q-k)
    bq=bq*(-1d0**(maxq-q))
  END DO
  
END PROGRAM test

I put together this little test program, to see better when we get problems.

Apparently , having the upper limit near HUGE() does not seem related to this.

Especially when the compiler pre-computes the number of iterations using this formula:

KCALC = (K8HI - K8LO)/DK8 + 1

Consider the trivial case where KCALC = 3

Then the values of K8 should be:

K8HI - 2*DK8,   K*HI-DK8, and  K8HI

So it does not have a chance to overflow the integer(8) high value,

even when K*HI8 = HUGE(K8)

This little test program steps thru values of K8LO starting with zero.

You start off getting wrong numbers  of number of iterations thru the loop,

then when it reaches the value of KI8, the problem goes away.

So I have to conclude that the compiler has an error in the way it computes the number of iterations.

Why would it ever give you ZERO passes? Unless the result was negative.....

Some call this the "integer overflow curse."

Actually, if it DID overflow the integer(8), you would get an infinite number of iterations, since the NEXT

value would be NEGATIVE. You sure would NOT get zero passes thru the loop, unless KLO8 > KHI8

and they are both <= HUGE(k8)

Even if KLO8 = KHI8, you still get ONE pass.

This littlle DO LOOP does work:

DO K = huge(k)-10, huge(k), 2

ENDDO

You get 6 passes, as you should.

module m

   implicit none

   private

   type, public :: t(n)
      private
      integer, len :: n = 1
      integer :: m_a(n)
   end type t

   public :: init

contains

   subroutine init(this)

      type(t(*)), intent(inout) :: this

      asc: associate ( a => this%m_a )

         a = 1

      end associate asc

      print *, " with associate: t%a = ", this%m_a

      return

   end subroutine init

end module m

program p

   use m, only : t, init

   type(t(n=2)) :: foo

   call init(foo)

   stop

end program p

Upon execution with either IA-32 or Intel(R) 64 compiler version:

  with associate: t%a =  0 0
Press any key to continue . . .

I believe the following code is ok and it compiles with no errors or warnings.  But it encounters a run-time error; it appears the automatic variable in the "contained" type that depends on the length parameter is not allocated.

module m

   implicit none

   private

   type :: t(n)
      private
      integer, len :: n = 1
      integer :: m_a(n)
   end type t

   type, public :: q(l)
      private
      integer, len :: l = 1
      type(t(n=l)) :: m_t
   end type q

   public :: init_q

contains

   subroutine init_t(this)

      type(t(*)), intent(inout) :: this

      this%m_a = 1

      print *, " t%a = ", this%m_a

      return

   end subroutine init_t

   subroutine init_q(this)

      type(q(*)), intent(inout) :: this

      call init_t(this%m_t)

      return

   end subroutine init_q

end module m

program p

   use m, only : q, init_q

   type(q(l=:)), allocatable :: foo

   allocate( q(l=2) :: foo)
   call init_q(foo)

   stop

end program p

Upon execution,

forrtl: severe (157): Program Exception - access violation
Image              PC                Routine            Line        Source

p64.exe            000000013F8610F7  M_mp_INIT_T                27  m.f90
p64.exe            000000013F86125B  M_mp_INIT_Q                39  m.f90
p64.exe            000000013F861585  MAIN__                      8  p.f90
p64.exe            000000013F8F319E  Unknown               Unknown  Unknown
p64.exe            000000013F8F392C  Unknown               Unknown  Unknown
p64.exe            000000013F8F3A6E  Unknown               Unknown  Unknown
kernel32.dll       00000000772359ED  Unknown               Unknown  Unknown
ntdll.dll          000000007736BA01  Unknown               Unknown  Unknown
Press any key to continue . . .