Hi,

Does anyone have experience with Windows Processor Groups?  I'm pondering getting a 64-core hyperthreaded (128 threads) machine to speed compute-bound OpenMP program which will happily use all the threads it can get its little hands on.  Are there ways to get more than 64 threads assigned to a process in WIn 7 or 10?  Are there any impediments to just running two instances of the code, one each in each of the processor groups?  Memory contention issues?

thanks,

Bruce

SOLVED. 

Dear Steve:

I was reading a book on Matrix Structural Analysis written in the early 1970s?. The book had some code in Fortran IV. The book even includes a brief section on how to code Fortran.

But the author offered the advice that Basic was preferred as Fortran was not suited to matrix analysis

I kid you not. I immediately thought of you

Got to love the 70s

John

Hello,

I have a large program (with lots of numerical computations on arrays etc.), whose performance is not as fast as expected. I recently realized that the various Optimization options in my compiler do not significantly impact the performance .

One of the aspects of my program is that it includes many large arrays, whose components are to be used multiple times by various subroutines in the program (tens of thousands of times in a run, to be precise). The arrays are defined in modules and can be shared among routines. Instead of following this approach, I create small sub-arrays before calling the subroutines. For example, let us imagine that I have a large vector {A}, defined in a module, and several of its components (not necessarily a contiguous block) are to be used by a subroutine. What I do in my program is define a small subarray {a1}, into which I place the individual components of {A} that are to be used by the subroutine. The subroutine then operates on {a1}, and after it is done, I may update individual components of {A} using updated values of {a1}. 

My question is whether my code could become faster if I directly operated on the large arrays, instead of working with small sub-arrays. In the context of the example that I provided, this would mean that my subroutine uses the module where {A} is defined, and it directly operates on the particular components of the large array {A} instead of the sub-array {a1}. I originally thought that the approach I am employing should be the fastest, but I am not 100% sure anymore (especially if my approach somehow prevents automatic optimization).

Thanks in advance for any help/suggestions,

Yannis

Hello,

I have developed a large program using the 2013 edition of Intel's parallel studio (Professional Edition), with the Visual Fortran Compiler (integrated into Visual Studio 2012).

I recently downloaded the trial of the 2019 Parallel Studio (Cluster edition) with Visual Studio 2017, to see if the new version of the compiler leads to better performance with my CPU model (It is a Xeon E5-2697 v3). 

In my benchmarks, I run the same exact code for the same level of optimization (O2), with all default options, apart from using Heap = 0.

To my surprise, the multi-threaded performance of my code when built with the new version of the compiler is abysmal, compared to the same exact code using the 2013 version of the compiler. I verified that the two compilers give similar performance for a single-thread execution of the code. A multi-threaded execution using 8 threads gives much faster execution when I use the 2013 edition of the compiler. Using 8 threads with the new edition of the compiler gives slower execution than the case with 1 thread! I am convinced that this is an issue of the windows-based version of the compiler, as the Linux-based version gives the expected performance enhancement when I use multiple threads. 

In light of the above, I wanted to ask whether anyone has an idea what may be causing such slow-down when I use the newer version of the compiler. Could there be a default option/setting in the compiler or in Visual Studio 2017 which was not present in the old versions?

Thanks in advance for any suggestions and advice.

My 32Bit-Fortran program breaks due to an unsolved symbol in libmmd.dll.

The entry point pow2o3f seems to be quite new in this dll.

So I updated the redistributable libraries with the msi-package, but the file in SYSWOW64 remains the old one.

Obvoiusly the OS looks first in this directory to find the dll, then the program fails.

When I rename this dll in SYSWOW64 to something temp., it works.

Should I freshen up SYSWOW64 by myself or what to do?

Kind regards

  Matthias

Environment :

Intel® Parallel Studio XE 2018 Update 5 Composer Edition for Fortran Windows* Integration for Microsoft Visual Studio* 2015, Version 18.0.0044.14
Microsoft Visual C++ 2015

I have FORTRAN DLL which have to compile to 64bit and this will be used in 32bit c++ project.

I attached sample of FORTRAN DLL as ForanDLLTest.zip and c++ project as cppFortran.zip.

When FORTRAN DLL is compiled to 32bit, there are no problem to use DLL in cpp project.

But when FORTRAN library is compiled to 64bit, LNK2019 error occurs in cpp project.

How can I resolve this..?

I noticed there are several methods for setting up asynchronous file writing.

The first is opening the file with asynchronous='YES', then having any read or write with asynchronous='YES', but I also saw the attribute asynchronous.

Do I need to have all three specified in order to ensure that the asynchronous writing occurs? Or can I get away with just using the attribute.

For example the following:

USE, INTRINSIC:: ISO_FORTRAN_ENV, ONLY: REAL32, REAL64

REAL(REAL64), DIMENSION(NCOL,NROW,NLAY):: BUF

OPEN(55, ACTION='WRITE', FORM='UNFORMATTED', ACCESS='STREAM', STATUS='REPLACE', POSITION='REWIND',  BUFFERED='yes', BLOCKSIZE=1048576,BUFFERCOUNT=1)

DO K=1,NLAY;  DO I=1,NROW;  DO J=1,NCOL
                                      WRITE(55) REAL(BUF(J,I,K), REAL32)
END DO; END DO; END DO

would make use of asycn if:

USE, INTRINSIC:: ISO_FORTRAN_ENV, ONLY: REAL32, REAL64

REAL(REAL64), DIMENSION(NCOL,NROW,NLAY):: BUF

OPEN(55, ACTION='WRITE', FORM='UNFORMATTED', ACCESS='STREAM', STATUS='REPLACE', POSITION='REWIND',  BUFFERED='yes', BLOCKSIZE=1048576,BUFFERCOUNT=1)

DO K=1,NLAY;  DO I=1,NROW;  DO J=1,NCOL
                                       WRITE(55,ASYNCHRONOUS='YES') REAL(BUF(J,I,K), REAL32)
END DO; END DO; END DO

or

USE, INTRINSIC:: ISO_FORTRAN_ENV, ONLY: REAL32, REAL64

REAL(REAL64), DIMENSION(NCOL,NROW,NLAY):: BUF

OPEN(55, ACTION='WRITE', FORM='UNFORMATTED', ACCESS='STREAM', STATUS='REPLACE', POSITION='REWIND',  BUFFERED='yes', BLOCKSIZE=1048576,BUFFERCOUNT=1,ASYNCHRONOUS='YES')

DO K=1,NLAY;  DO I=1,NROW;  DO J=1,NCOL
                                       WRITE(55,ASYNCHRONOUS='YES') REAL(BUF(J,I,K), REAL32)
END DO; END DO; END DO

or

USE, INTRINSIC:: ISO_FORTRAN_ENV, ONLY: REAL32, REAL64

REAL(REAL64), DIMENSION(NCOL,NROW,NLAY),ASYNCHRONOUS='YES':: BUF

OPEN(55, ACTION='WRITE', FORM='UNFORMATTED', ACCESS='STREAM', STATUS='REPLACE', POSITION='REWIND',  BUFFERED='yes', BLOCKSIZE=1048576,BUFFERCOUNT=1,ASYNCHRONOUS='YES')

DO K=1,NLAY;  DO I=1,NROW;  DO J=1,NCOL
                                       WRITE(55,ASYNCHRONOUS='YES') REAL(BUF(J,I,K), REAL32)
END DO; END DO; END DO

So in summary, what combination of ASYNCHRONOUS words do I need to have ASYNCHRONOUS to be in effect.

Also is there any penalty for opening a file with ASYNCHRONOUS='YES', but never writing a file with it (so there never is a write statement with ASYNCHRONOUS='YES')

One last point, is there any danger to using ASYNCHRONOUS='YES' along with BUFFERED='YES'

Hello all, 

My apologies if I missed this issue in searching through the forums.  I've rolled over to XE 2018 Update 2 Composer Edition (w_comp_lib_2018.2.185) and VS2017 15.6.6 (win 10 machine).  From VS2017 itself,  I ran the hello world console example program and it appears to be integrated and to compile just fine, however the command line version of ifort does not seem to work for me.  

Post-install of both programs, I followed the Intel getting started guide: C:\Program Files (x86)\IntelSWTools\documentation_2018\en\ps2018\getstart_comp_wf.htm , 

When I run .\psxevars.bat from the powershell or attempt to use the command line tools ("Compiler 18.0 Update 2 for Intel 64 Visual Studio 2017 environment") from the start menu , I get the following message:

Via Powershell:

PS C:\Program Files (x86)\IntelSWTools\parallel_studio_xe_2018.2.046\bin> .\psxevars.bat intel64 vs2017

Output below:

Intel(R) Parallel Studio XE 2018 Update 2
Copyright (C) 2018 Intel Corporation. All rights reserved.

ERROR: Visual Studio 2017 is not found in the system.

Is there something I've done wrong such that VS2017 cannot be located?  Thank you for any help and/or pointing me in the right direction to work on fixing.  

Hello,

i got a problem with object members of arrays beeing passed to a subroutine. In the following example everything works fine a long as the dummy argument arr_arg of foo is defined as type. But as soon as it is defined as class it breaks. Dependent on compiler options (/Od) access violations are detected or (/O2) unpredictable behavior occours. This can cause difficult to find errors later on.

The code-example gives 4 cases: Type/Class and Variant 1/2

Surprisingly variant 2 works for the type definition ( and for the class with /O2), where i thought it should not as the brackets produce a copy of the objects(?)

Greetings

Wolf

program MAIN
  implicit none

  ! Inner Type
  type T_B
    integer, allocatable :: arr_real(:,:)
    integer              :: dummy_1b
  end type

  ! Outer Type
  type T_A
    type(T_B)         :: arr_T_B
    integer           :: dummy_1a
    real, allocatable :: dummy_3a(:)
  end type


  type(T_A)        :: bar(1:2)
  integer, pointer :: ptr_outer(:)


  allocate(bar(1)%arr_T_B%arr_real(10,2))
  allocate(bar(2)%arr_T_B%arr_real(10,2))
  bar(1)%arr_T_B%arr_real(:,1) = [10:19]+1000
  bar(1)%arr_T_B%arr_real(:,2) = [10:19]+2000
  bar(2)%arr_T_B%arr_real(:,1) = [20:29]+1000
  bar(2)%arr_T_B%arr_real(:,2) = [20:29]+2000

  write(*,'("0x",Z8.8)')LOC(bar(1)%arr_T_B)
  write(*,'("0x",Z8.8)')LOC(bar(2)%arr_T_B)
  write(*,*)LOC(bar(2)%arr_T_B) - LOC(bar(1)%arr_T_B) !< Always 92
  write(*,*)

  ! Variant 1
  call foo(bar(1:2)%arr_T_B, ptr_outer)

  ! Variant 2
!  call foo([bar(1)%arr_T_B,bar(2)%arr_T_B], ptr_outer)

    write(*,*)"Extern"
    write(*,'(*(I6))')ptr_outer


    bar(2)%arr_T_B%arr_real(:,2) = [1:10]
    write(*,*)
    write(*,*)"Pointer modified"
    write(*,'(*(I6))')ptr_outer ! Surprisingly Variant 2 with "Type" works

  contains


  subroutine foo(arr_arg, ptr_inner)
!    type(T_B), target, intent(in   ) :: arr_arg(1:2)  !< Works
    class(T_B), target, intent(in   ) :: arr_arg(1:2)  !< Does not work

    integer,   pointer, intent(  out) :: ptr_inner(:)

    ! New(V1&V2) address for type      -> Old(V1) | New(V2) address for class
    write(*,'("0x",Z8.8)')LOC(arr_arg(1))

    ! New(V1&V2) address for type(+92) -> Old(V1) | New(V2) address for class(+52)
    write(*,'("0x",Z8.8)')LOC(arr_arg(2))

    write(*,*)LOC(arr_arg(2)) - LOC(arr_arg(1)) !< Always 52;

    write(*,*)"is_contiguous?", is_contiguous(arr_arg) ! Seems to be correct
    write(*,*)"Intern"

    ptr_inner => arr_arg(2)%arr_real(:,2)
    write(*,'(*(I6))')ptr_inner !< Printed results are wrong

    write(*,'(*(I6))')arr_arg(2)%arr_real(:,2) !< Error is thrown here

  end subroutine

end program

Hello,

Can someone please help me understand what are allocatable arrays while writing a code in Fortran? When do we allocate/deallocate arrays? What is the role of the module? 

Thanks

Intel folks:

Many thanks for bringing back F1 access to the Fortran documentation with the latest update 18.03. It was certainly helpful to have it available in release 19.0 beta, but essential for our production work which is using release 18.0

https://software.intel.com/en-us/articles/download-documentation-intel-c...

I note, however, that my version of WinZip (19.5) will not extract the documentation ZIP file that the link in the above Intel page contains -- WinZIP reports a error. But I believe that to be bogus, since if open the file with WinZIP and copy the entire contents to the specified folder the F1 access works as advertised. Not a big deal, but it is strange. 

From this afternoon I am getting email change notifications for any thread I started on here going way back. I am guessing some forum admin is going on and the threads are thus marked as changed and as a result so I get notification emails. Is is happening to others as well? Quite irritating.

Today I have been receiving several e-mails telling me that there has been activity on forum topics that I started over the past few months. When I checked nothing has been added. Is there a problem with the automatic e-mail notification process?

I am having some problems with execute_command_line

My program launches in a folder in  which I don't specify. I need to move around this root folder creating new sub-folders and moving between them and the root folder.

The variable 'root_folder' has the full path name for the root folder.If I am in a sub-folder of the root folder and use the Fortran code: 

 integer status
 status = changedirqq(trim(root_folder))

It works and I move back to the root folder. However, if I use

  command = 'chdir ..'
  call execute_command_line(trim(command), exitstat=estat, cmdstat=cstat)

then estat and cmdstat are returned as zero but I do not move back to the root folder.

If I use the Command Prompt window, I can move around the the folders with standard Windows commands without any problems.

I am using the latest beta compiler.

I have VS 2017 15.7.1

I've tried all the things I can find but I cannot open a vfproj file that I created in February 2018 now in May 2018. I was running the 30-day trial in February and then it expired. Afterward I uninstalled all intel products. Then later on I acquired a license for this software and reinstalled it, Update 2. I see in the Help menu of Visual Studio "Intel Compilers and Libraries" and "Intel Software Manager", but in the list of installed products, Fortran does not appear, or anything Intel. When I create a new project, Fortran does not appear (it did before, with the 30 day trial). I uninstalled and reinstalled VF compiler and even installed the most recent update 3. No avail. This was an expensive license and I need it ASAP. What gives?

Hi all,

I recently started working on a project that was build roughly 15 years ago. It uses a Visual C++, and visual fortran compiled in CVF. Currently, there are two projects in one solution. The C++ code is the main project that is dependent on the fortran code in a static library. I am on Windows 10, using Visual studio 2013 professional, and using Intel Visual Fortran 2017. 

The issue is that there are references to DFOR.lib in the project properties for the C++ project in the linker command line (/defaultlib:"dfor.lib"), but it gives the error dfor.lib cannot be opened and when removed, there are a series of unresolved external symbols. 

Error   6   error LNK2001: unresolved external symbol "public: class ATL::CStringT<char,class StrTraitMFC<char,class ATL::ChTraitsCRT<char> > > __thiscall petMove::toString(void)" (?toString@petMove@@QAE?AV?$CStringT@DV?$StrTraitMFC@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@XZ) C:\Users\Gavin\Desktop\College stuff\1st year (Fresher)\Pet_Gavin\pet_neda\Power Network CaptureView.obj    Power Network Capture
Error   23  error LNK2019: unresolved external symbol "protected: __thiscall CZoomView::CZoomView(void)" (??0CZoomView@@IAE@XZ) referenced in function "protected: __thiscall CPowerNetworkCaptureView::CPowerNetworkCaptureView(void)" (??0CPowerNetworkCaptureView@@IAE@XZ)   C:\Users\Gavin\Desktop\College stuff\1st year (Fresher)\Pet_Gavin\pet_neda\Power Network CaptureView.obj    Power Network Capture
Error   24  error LNK2019: unresolved external symbol "protected: virtual __thiscall CZoomView::~CZoomView(void)" (??1CZoomView@@MAE@XZ) referenced in function "public: virtual __thiscall CPowerNetworkCaptureView::~CPowerNetworkCaptureView(void)" (??1CPowerNetworkCaptureView@@UAE@XZ)    C:\Users\Gavin\Desktop\College stuff\1st year (Fresher)\Pet_Gavin\pet_neda\Power Network CaptureView.obj    Power Network Capture
Error   7   error LNK2019: unresolved external symbol "public: __thiscall CDialogCurrentPhasor::CDialogCurrentPhasor(class CWnd *)" (??0CDialogCurrentPhasor@@QAE@PAVCWnd@@@Z) referenced in function "public: void __thiscall CCurrentPhasor::SEDialogHandler(void)" (?SEDialogHandler@CCurrentPhasor@@QAEXXZ) C:\Users\Gavin\Desktop\College stuff\1st year (Fresher)\Pet_Gavin\pet_neda\Power Network CaptureDoc.obj Power Network Capture
Error   5   error LNK2019: unresolved external symbol "public: class ATL::CStringT<char,class StrTraitMFC<char,class ATL::ChTraitsCRT<char> > > __thiscall petMove::toString(void)" (?toString@petMove@@QAE?AV?$CStringT@DV?$StrTraitMFC@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@XZ) referenced in function "public: int __thiscall CPowerNetworkCaptureDoc::PushMove(class petMove *)" (?PushMove@CPowerNetworkCaptureDoc@@QAEHPAVpetMove@@@Z)  C:\Users\Gavin\Desktop\College stuff\1st year (Fresher)\Pet_Gavin\pet_neda\Power Network CaptureDoc.obj Power Network Capture
Error   22  error LNK2019: unresolved external symbol "public: unsigned int __thiscall petMove::getPartType(void)" (?getPartType@petMove@@QAEIXZ) referenced in function "protected: void __thiscall CPowerNetworkCaptureView::OnChar(unsigned int,unsigned int,unsigned int)" (?OnChar@CPowerNetworkCaptureView@@IAEXIII@Z)    C:\Users\Gavin\Desktop\College stuff\1st year (Fresher)\Pet_Gavin\pet_neda\Power Network CaptureView.obj    Power Network Capture
Error   14  error LNK2019: unresolved external symbol "public: virtual __thiscall CDialogRunAnalysisFromFilePF::~CDialogRunAnalysisFromFilePF(void)" (??1CDialogRunAnalysisFromFilePF@@UAE@XZ) referenced in function "protected: void __thiscall CPowerNetworkCaptureDoc::OnAnalysisRunFromFilePF(void)" (?OnAnalysisRunFromFilePF@CPowerNetworkCaptureDoc@@IAEXXZ)    C:\Users\Gavin\Desktop\College stuff\1st year (Fresher)\Pet_Gavin\pet_neda\Power Network CaptureDoc.obj Power Network Capture
Error   3   error LNK2019: unresolved external symbol _HtmlHelpW@16 referenced in function "protected: void __thiscall CMainFrame::OnHtmlHelp(void)" (?OnHtmlHelp@CMainFrame@@IAEXXZ)   C:\Users\Gavin\Desktop\College stuff\1st year (Fresher)\Pet_Gavin\pet_neda\MainFrm.obj  Power Network Capture

I have tried to rebuild the solution. The fortran library compiles without any errors but the C++ project does not. I am new to working with Visual Studio and linking libraries so I do not know if this is an issue with a missing library that has replaced DFOR.lib or if the C++ project should generate the links automatically. I also noticed that for my fortran static library Configuration Properties< Fortran < External Procedures < Calling Convention was set to CVF (/iface:cvf). I tried setting this to default but I saw no immediate results. 

Also I have tried to rebuild the solution from the source code but I am inexperienced with that and the solution is quite large. One issue I am having is that the fortran files are now compiling with errors when they did not previously. 

Error	2	 error #6633: The type of the actual argument differs from the type of the dummy argument.   [WS]	C:\Users\Gavin\Desktop\College stuff\1st year (Fresher)\Ali Abur Code\pet_neda\fortranfiles\optimpl\IPENUM.f	295	

How can I replace all of the references and ties to Compaq Visual Fortran? Or how can I solve these unresolved external symbol errors? Are there any similar libraries I can use to resolve some of the externals?

Thank you for the help in advance,

Gavin 

I just received a strange email related to this forum, purporting to be from Intel.  Supposedly it comes from idz.admin@intel.com, and it begins:

Greetings Gib B.,

Update for Forum topic: OpenMP problem
My Fortran program is built as a DLL, and it calls a C function that is also built as a DLL. ...

It quotes a forum post from 2014, with a link to that thread:

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-fo...

I do not use the ID 'Gib B.', and I don't remember this exchange, but my memory being what it is, it's possible that it was me (the compiler version info matches).  I wonder if anybody else has seen one of these.

Gib

Dear All

I am using Visual Studio Enterprise 2017 v15.5.4 with Intel(R) Visual Fortran Compiler 17.0.7.272 [Intel(R) 64]

And debugging is not working - not stopping at break points, and when the first fatal error is encountered I am not getting a line number.

I currently compile with the following, as copied from the VS project|properties|command line

/nologo /debug:full /Od /fpp /recursive /standard-semantics /Qdiag-error-limit:50 /stand:f15 /warn:declarations /warn:unused /warn:ignore_loc /warn:truncated_source /warn:interfaces /module:"x64\Debug\\" /object:"x64\Debug\\" /Fd"x64\Debug\vc150.pdb" /traceback /check:bounds /check:stack /libs:dll /threads /dbglibs /c

I checked each of these against the documentation and noticed:

1) The documentation says /Fd[:filename] but there is no : between the /Fd and the filename on the command line shown above.

2) There is no file x64\Debug\vc150.pdb (so I guess this is why I get no line numbers?), and,

3) I am not sure which option or options in VS generate this option on the command line but when I try to add the "correct" version in the additional options box, I get shouted at along the lines of:

ifort: command line warning #10122: overriding '/Fdx64\Debug\vc150.pdb' with '/Fdx64\Debug\vc150.pdb'

So what do I do next? Is the /Fd thing a bug or irrelevant? How do I get the debugger back working?

Thanks

Norman

I have a quickwin application, in which there is a list box. I've added to the list box a horizontal scroll bar in the following way. I've included in the DoCallBackInit subroutine sending the following message to the list box                    

        retint=SendDlgItemMessage(dlg%hwnd, IDC_LIST_Who, LB_SETHORIZONTALEXTENT, ilenSTR, 0)

ilenSTR is maximal text length in pixels.

When the dialog is updated using dialog controls, the text length is changed. It is possible that in some cases the horizontal scroll bar isn't necessary. But it doesn't disappear.
How to hide the horizontal scroll bar in these cases?