Quantcast
Channel: Intel® Fortran Composer XE
Viewing all 1424 articles
Browse latest View live

Slowness when writing many records to a direct access file

$
0
0

When writing records to a direct access file I am finding that the Intel Fortran compiler is much slower than my 17 year old Watcom Fortran compiler running exactly the same code. In fact the Intel compiler is around 10 times slower!! This doesn't seem right to me. Can anyone see what I am doing wrong in the code segment below? Note that if CASES=1970 and BMS=5167, it is writing over 10 million records and this is taking around 8 minutes on my I7 laptop, whereas the ancient Watcom compiler does it in less than a minute.



You can see that I have a PeekMessage statement in the loop so that it can process Windows messages, however I am finding that the speed is the same with or without it.



Help!

      INTEGER*4  RCD,CASES,BMS,CNUM,NMP,MEM,IO

      STRUCTURE /MACTIONS/

         INTEGER*2  NTCN,BKL

         REAL*8     FM(12),Extra(6),Diff(6)

      END STRUCTURE

      RECORD /MACTIONS/ MACT(BMS,CASES)

      TYPE(T_MSG)    Msg

      OPEN (MALUN,FILE='FRED.DAT'

     c        ,STATUS='NEW'

     c        ,ACCESS='DIRECT'

     c          ,FORM='UNFORMATTED'

     c        ,ACTION='READWRITE'

     c          ,RECL=200

     c        ,IOSTAT=IO)

      RCD=0

      DO CNUM=1,CASES

         PeekMessage (Msg,0,0,0,PM_REMOVE)

         DO NMP=1,BMS

            RCD=RCD+1

            WRITE (MALUN,REC=RCD,IOSTAT=IO) NMP

     c      ,(MACT(NMP,CNUM).FM(I),I=1,12)

     c      ,MACT(NMP,CNUM).NTCN,MACT(NMP,CNUM).BKL

     c      ,(MACT(NMP,CNUM).Extra(I),I=1,6)

     c      ,(MACT(NMP,CNUM).Diff(I),I=1,6)

         ENDDO

      ENDDO

      CLOSE (MALUN)


IVF Composer XE 2013 & Win Azure

$
0
0

Does a DLL compiled with IVF Composer XE 2013 work on Win Azure cloud platform?

Underscore prefix

$
0
0

 

    Hello

           I am trying to build a fortran project with a 'c' library named PETSc. During compilation some functions are missing, and they appear as    unresolved externals after linking. It seems that the problem is the underscore prefix inside the 'c' funtions. How can I turn off that option to avoid these errors?

 

   thanks

 

Debugging a console program

$
0
0

Hi,

I have a console program that uses command line arguments like

app.exe  inp1.txt inp2.txt  out1.txt  out2.bmp

and I use 

call GETARG(3,fln1)  

call GETARG(4,fln2) 

to supply the filenames for the out1.txt and out2.bmp

For reading these input files I have 

 OPEN(UNIT = 101, FILE = '', STATUS = 'OLD', IOSTAT = IERR)

and the File =  '' takes in inp1.txt and a separate one for inp2.txt

  The issue is during debugging (using command arguments) it returns error in opening input file and I have to physically replace it with the filename

   OPEN(UNIT = 101, FILE = 'inp1.txt', STATUS = 'OLD', IOSTAT = IERR)

Why is this so. The compiled executable runs fine but during debugging I have to hardcode it in. The reason for the input file name to be different each time is this is run on a webinterface with multiple users possibly running the same application simultaneously and hence each user has a separate input and output filename

 

Thanks for any help

 

Sumit

Link error

$
0
0

 

   Hello

    I am trying to build PETSc inside a fortran project. And after hard work I got this:

Deleting intermediate files and output files for project 'PETScFORTRAN', configuration 'Debug|x64'.
Compiling with Intel(R) Visual Fortran Compiler XE 14.0.2.176 [Intel(R) 64]...
ifort /nologo /debug:full /Od /fpp /I"C:\Program Files\PETSc for Windows\PETSc\include" /I"C:\Program Files\PETSc for Windows\PETSc\include\finclude" /I"C:\Program Files\PETSc for Windows\PETSc\include\finclude\ftn-auto" /I"C:\Program Files\PETSc for Windows\PETSc\include\finclude\ftn-custom" /I"C:\Program Files\PETSc for Windows\PETSc\c-debug_icl_mkl\include" /I"C:\Program Files\PETSc for Windows\PETSc\include\mpiuni" /DWINDOWS /warn:interfaces /module:"x64\Debug\\" /object:"x64\Debug\\" /Fd"x64\Debug\vc110.pdb" /traceback /check:bounds /check:stack /libs:static /threads /dbglibs /winapp /c /extfor:F /Qvc11 /Qlocation,link,"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\\bin\amd64""C:\Users\Pedro\Desktop\fortran_test\PETScFORTRAN\ex14f.F"
Linking...
Link /OUT:"x64\Debug\PETScFORTRAN.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:\Program Files\PETSc for Windows\PETSc\c-opt_icl_mkl\lib" /LIBPATH:"C:\Program Files\Microsoft HPC Pack 2008 R2\Lib\amd64\\" /LIBPATH:"C:\Program Files\Microsoft MPI\Lib\amd64" /LIBPATH:"C:\Program Files\PETSc for Windows\lib\intel64" /LIBPATH:"c:\Program Files\PETSc for Windows\PETSc\externalpackages\libs\\" /NODEFAULTLIB:"LIBCMT.lib" /MANIFEST /MANIFESTFILE:"C:\Users\Pedro\Desktop\fortran_test\PETScFORTRAN\x64\Debug\PETScFORTRAN.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\Users\Pedro\Desktop\fortran_test\PETScFORTRAN\x64\Debug\PETScFORTRAN.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"C:\Users\Pedro\Desktop\fortran_test\PETScFORTRAN\x64\Debug\PETScFORTRAN.lib" advapi32.lib libpetsc.lib mkl_intel_lp64_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib libiomp5md.lib msmpi.lib msmpifmc.lib  "x64\Debug\ex14f.obj"
Link: executing 'link'
libifcoremt.lib(for_main.obj) : error LNK2019: unresolved external symbol __intel_new_feature_proc_init referenced in function main
x64\Debug\PETScFORTRAN.exe : fatal error LNK1120: 1 unresolved externals


PETScFORTRAN - 2 error(s), 0 warning(s)

How can this be fixed?

 

    Help

CALL for attention and discussion: recent paper comparing an equation solver implementation in Fortran vs C++ vs Python

$
0
0

NOTE: this is a copy of the thread at the Linux forum.  My apologies to those who have seen it there - I'm posting it here with the hope of getting more comments and feedback and generating some discussion amongst the Windows users.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Fortran enthusiasts may have seen and/or be interested in the findings and observations in a recent open literature publication by Arabas, et al. at the Institute of Geophysics at the University of Warsaw. Here’s the link to this paper: http://arxiv.org/abs/1301.1334

It is very interesting to read Arabas et al. find “that C++11/Blitz++, Python/NumPy and Fortran 2008 provide comparable functionalities in terms of matching the blackboard abstractions within the program code. Taking into account solely the part of code representing particular formulæ (e.g. listings C.21, P.17, F.20 and equation 4) all three languages allow to match (or surpass) LATEX in its brevity of formula translation syntax. All three languages were shown to be capable of providing mechanisms to compactly represent such abstractions as: • loop-free array arithmetics; • definitions of functions returning array-valued expressions; • permutations of array indices allowing dimensionindependent definitions of unctions (see e.g. listings C.12 and C.13, P.10 and P.11, F.11 and F.12); • fractional indexing of arrays corresponding to employment of a staggered grid.”

The authors make pointed comments about some of the limitations they faced with Fortran, “Three issues specific to Fortran that resulted in employment of a more repetitive or cumbersome syntax than in C++ or Python were observed: • Fortran does not feature a mechanism allowing to reuse a single piece of code (algorithm) with different data types (compare e.g. listings C.6, P.5 and F.4) such as templates in C++ and the so-called duck typing in Python; • Fortran does not allow function calls to appear on the left hand side of assignment (see e.g. how the ptr pointers were used as a workaround in the cyclic_fill_halos method in listing F.8); • Fortran lacks support for arrays of arrays (cf. Sect. 2.2).”

In addition, Fortran users won’t be surprised to read the following, but would do well to make a note of it: “Fortran is a domain-specific language while Python and C++ are general-purpose languages with disproportionately larger users’ communities. The OOP features of Fortran have not gained wide popularity among users. Fortran is no longer routinely taught at the universities [28], in contrast to C++ and Python. An example of decreasing popularity of Fortran in academia is the discontinuation of Fortran printed editions of the ”Numerical Recipes” series of Press et al.”

The paper points out a few other shortcomings in working with Fortran: " The built-in standard libraries of Python and C++ are richer than those of Fortran and offer versatile data types, collections of algorithms and facilities for interaction with host operating system. In the authors’ experience, the small popularity of OOP techniques among Fortran users is reflected in the library designs (including the Fortran’s built-in library routines). What makes correct use of external libraries more difficult with Fortran is the lack of standard exception handling mechanism, a feature long and much requested by the numerical community"

But the least surprising finding for die-hard Fortran coders will be, “The performance evaluation revealed that: • the Fortran set-up offered shortest execution times,”

What are your take-aways from this study? I request you all to post your comments.

Heap corruption from VB callback

$
0
0

The attached project is a distillation of an error that I am having when calling a Fortran DLL from a VB.Net executable.

We are trying to use a callback from the Fortran to display output in a VB rich text box. The included project is from Visual Studio 2012 and Intel Visual Fortran Composer XE 2013 SP1 Update 1.

This is the routine causing the error:

      SUBROUTINE WRWIN(OUTSTR)
C*
      USE IFCOM               ! defines CONVERTTOBSTR and FREESYSSTRING routines
      USE VB_WRWIN_MOD        ! defines VB_WRITEWINDOW VB routine

      INTEGER           IRC           ! <i> - screen unit to write to
      CHARACTER*(*)     OUTSTR        ! <i> - string to print

      POINTER      ( P2, MY_STR_OUT )
      INTEGER*2      MY_STR_OUT(128)

      P2 = CONVERTSTRINGTOBSTR( TRIM(OUTSTR) )
      CALL VBWRITEWINDOW1( P2, IRC )

      RETURN
      END

After the call to VBWRITEWINDOW1, execution stops in Visual Studio with "Windows has triggered a breakpoint in HelloWorld_Basic.exe. This may be due to a corruption of the heap, which indicates a bug in HelloWorld_Basic.exe or any of the DLLs it has loaded.

Added complications:

If I choose the Target Framework for the VB project as ".NET Framework 2.0", the program compiles and runs fine. This error only occurs when I change the framework to .NET Framework 4.5.

SLN file is in the HelloWorld_Basic folder. Both VB and Fortran projects are included in the same solution.

Any help would be greatly appreciated.

dave

AllegatoDimensione
ScaricaHelloWorld.zip2.01 MB

Can I compile a program here that will run on a tablet?

$
0
0

I guess its a different operating system entirely, but is there a way to generate executable code here

that I can migrate over to a tablet? Or does that require a separate compiler I would have to install on the

tablet?

I am not even sure I can compile any Fortran programs on a tablet.


Format label and Contains block

$
0
0

Hi all,

i'm working on a main routine with many other subroutine in a contains block. In the main one, I defined some format labels but I can't use them in the contains block : they are no more defined. At the moment, I avoid this problem by redefined format labels in each subroutine in the contains block ; but this solution isn't really suitable. Is there a way to define these labels only once ?

Thanks,

Sebastien.

Migration of CVF Project with Custom Build Steps

$
0
0

I am currently migrating a project from VS6/CVF6.6 into VS2012/IVF2013.  The way the FORTRAN libraries were set up in my project, I had a folder consisting of .f files and a folder of .for files generated from the .f files using a custom build tool.


Under VS6/CVF6.6, I was able to run the custom build tool for each .f file without compiling them. I have not found a way to accomplish excluding the .f files from the build while still running the custom build tool on them under the new VS2012/IVF2013. Am I correct in assuming that this is no longer supported by VS2012/IVF2013?


If the above will not work, I know that I could change the .f extensions to something else (.src or similar) and exclude those files from the build while still running the custom build tool on them. Is there a way, then, for me to use the FORTRAN editor for these .src files without adding them as FORTRAN files in the IVF options (because that would cause me to have the same issue I had when they were .f files)?


 

VALUE Attribute Vs INTENT(IN)

$
0
0

This is just a general question for peoples opinions on the VALUE attribute used in subroutines. I know it The VALUE attributie is sometimes necessary for interoperability with C, but my interest is what would be the benefit beyond that compared to INTENT(IN). I am assuming  that it makes no sense to have both at the same time.

 

Below is a simple example of what I am talking about

SUBROUTINE DOUBLER(X,Y) 
  REAL,      VALUE::X
  REAL,INTENT(OUT)::Y
  Y=2.*X
END SUBROUTINE

or

SUBROUTINE DOUBLER(X,Y) 
  REAL, INTENT(IN)::X
  REAL,INTENT(OUT)::Y
  Y=2.*X
END SUBROUTINE

 

Or another example would be:

FUNCTION DOUBLER(X) RESULT(Y) 
  REAL, VALUE::X
  REAL::Y
  Y=2.*X
END FUNCTION

or

FUNCTION DOUBLER(X)   RESULT(Y) 
  REAL::X                             !FUNCTION IMPLICITLY USES IN
  REAL::Y
  Y=2.*X
END FUNCTION

Fail to link 64-bit Code

$
0
0

I have a working 32-bit software library written in Fortran with low-level stuff in C/C++ It has worked for years.

It is fine.

When I re-build the library in 64-bit mode, none of the C functions are linked in. I've checked the linker options, and they all seem to be right. The project appears to be referencing the 64-bit libraries.

Would someone mind just looking some sample  INTERFACE code and tell me whether there is anything at all that would cause a problem 

      SUBROUTINE PBZQS(MODE, IXORIG, IYORIG, NX, NY)

      INTEGER MODE

      INTEGER IXORIG, IYORIG

      INTEGER NX, NY

      INTERFACE

        SUBROUTINE JB_ZBSpecInquireImageSize(MODE, IXORIG, IYORIG, NX,

     1      NY)

          INTEGER MODE

          INTEGER IXORIG, IYORIG

          INTEGER NX, NY

          !DEC$ ATTRIBUTES C, ALIAS: '_JB_ZBSpecInquireImageSize' ::

     1      JB_ZBSpecInquireImageSize

          !DEC$ ATTRIBUTES VALUE :: MODE

          !DEC$ ATTRIBUTES REFERENCE ::  IXORIG, IYORIG, NX, NY

        END

      END INTERFACE

      CALL JB_ZBSpecInquireImageSize(MODE, IXORIG, IYORIG, NX, NY)

      END

The linker comes up with:unresolved external symbol'_JB_ZBSpecInquireImageSize

Reassurance from someone "that should work" is all I need.

 

I observe that the project includes the library comdlg32.lib. Is that going to be right for a 64-bit application?

Is there an easy way to look at the contents of the .lib file that is being linked in?

Оптимизировали, оптимизировали, да не выоптимизировали!

$
0
0

Оптимизация? Конечно, каждый сталкивался с данной задачей при разработке своих, сколь-нибудь значительных, требующих определённых вычислений, приложений. При этом способов оптимизировать код существует огромное множество, и, как следствие, различных путей сделать это в автоматическом режиме с помощью опций компилятора. Вот здесь и возникает проблема – как выбрать то, что нужно нам и не запутаться?

Начнём с того, что оптимизации в современном компиляторе компании Intel® делятся на feature-specific (функциональные) и processor-specific (процессорные). К первым относят, например, оптимизации, подключаемые с помощью наиболее часто используемых ключиков O1, O2, O3. 

Другая история – оптимизация с помощью опций компилятора под конкретное «железо» и набор инструкций, который оно поддерживает. Хотелось бы раскрыть именно этот вопрос более детально.

Итак, ключей для генерации «специфичного» под какое-либо семейство процессоров несколько. Что же «специфичного» мы получаем? В первую очередь, использование SIMD инструкций поддерживаемой архитектуры. Рассмотрим возможные ключи:

1)-x<feature> (Linux), /Qx<feature> (Windows)

Если мы хотим, чтобы компилятор оптимизировал наш код под конкретный, заранее известный тип интеловского процессора, и, соответственно, поддерживаемый им набор инструкций и функциональностей, то можно использовать данный ключ. При этом мы не собираемся запускать приложение на системах, которые не поддерживают данный набор инструкций.

Скажем, есть у нас система с процессором архитектуры SandyBridge, на которой мы собираемся запускать приложение. Данный процессор поддерживает набор инструкций AVX, и именно это значение мы можем указать с помощью ключика –xAVX (Linux) или –QxAVX (Windows). Таким образом, мы получим оптимизированный бинарник, который при запуске будет проверять, поддерживает ли наш процессор AVX инструкции. Если да, то наше приложение успешно запуститься и раскроет все преимущества использования процессорной оптимизации. Если же нет, то вылетит ошибка о том, что наш процессор не поддерживает данную функциональность. Приложение выполняться не будет!

Список значений, которые можно прописать с помощью данного ключика следующий:

SSE2, SSE3, SSSE3, SSSE3_ATOM, SSE3_ATOM, SSE4.1, SSE4.2, AVX, CORE-AVX-I, CORE-AVX2

Важно, что наиболее «свежие» версии поддерживают предыдущие, поэтому, возвращаясь к нашему примеру, очевидно, что код, скомпилированный с опцией –xSSE4.1, будет успешно выполнен и на системах, поддерживающих SSE4.2, AVX и выше. Но не наоборот. Специфичные AVX инструкции не смогут выполняться на более старых системах их  не поддерживающих, что логично.

2)-m<feature> (Linux), /arch: <feature> (Windows)

Данный ключ позволит получить приложение, которое будет содержать оптимизацию для  всех типов процессоров (не только интеловских), поддерживающих заданный набор инструкций. При этом никакой проверки в main функцию на тип процессора добавляться не будет, а это значит, что если мы станем запускать приложение на системе с процессором, не поддерживающим заданный набор инструкций, произойдёт неприятность… в отличие от проверки в случае с флагом –x, где просто выдаётся сообщение о несовместимости, в данном случае программа «упадёт», пытаясь выполнить конкретную инструкцию.

3)-ax<feature> (Linux), /Qax<feature> (Windows)

Ещё одна опция компилятора, позволяющая создать несколько версий (code paths), оптимизированных под разные архитектуры. Мы можем указать сразу несколько архитектур через запятую, например –axSSE4.2,AVX. Понятно, что в данном случае увеличится размер выходного файла (он так и будет один). При этом создаются как минимум два варианта – базовый (baseline) и оптимизированный под заданную архитектуру код. Есть одно но… компилятор сам проверяет, будет ли выигрыш в производительности от создания дополнительной, оптимизированной ветки. Если выигрыш есть, сгенерирует несколько версий, и во время выполнения программы, в зависимости от используемого процессора, будет выбрана нужная. С использованием этого ключика мы получим возможность создавать приложения, извлекающие максимум возможностей на наиболее свежих процессорах, при этом так же вполне валидно работающих на более старых и не интеловских процессорах (будет выполняться базовая ветка).

Интересны дополнительные комбинации перечисленных ключиков. Скажем, использование опций –ax и –x одновременно приводит к тому, что последней будет задана базовая версия, которая по умолчанию выставляется как SSE2. Поэтому, если есть необходимость её изменить с SSE2 на что-то другое, используем сочетание этих опций. Равно как и сочетание –ax и –m приведёт к тому, что в базовой версии будет оптимизированный код, который выполняется не только на интеловских процессорах.

Есть ещё один интересный флажок -mia32. Только он сможет создать приложение, способное выполняться на процессорах, более древних, чем Pentium 4 (не поддерживающих SSE2). Скажем, комбинация опций -mia32 -axSSE2 (Linux) или /arch:IA32 /QaxSSE2 (Windows) создаст приложение, которое будет выполняться на любых процессорах с архитектурой IA-32, плюс ещё и оптимизированная под SSE2 ветка.

И напоследок… если мы не знаем, какой набор инструкций поддерживает наша текущая система, но хотим оптимизировать именно под неё, нам поможет флаг –xHost(Linux) и /QxHost (Windows). Она скажет компилятору генерировать код, оптимизированный под поддерживаемую нашим процессором архитектуру. На другой машине наше приложение может и не заработает, но есть вероятность, что этого нам и не нужно.

А теперь немного практики. Будем компилировать программку перемножения матриц с разными ключиками на Windows. Тесты я провожу на системе с процессором архитектуры SandyBridge, поэтому собрав программку с флагом -QxCORE-AVX2, при запуске получаю следующую ошибку:

Fatal Error: This program was not built to run in your system.

Please verify that both the operating system and the processor support Intel(R) AVX2, BMI, LZCNT, HLE, RTM and FMA instructions.

Меняю ключик на –QaxAVX,CORE-AVX2, и программа запускается успешно, при этом выполняются специфичныe AVX инструкции. Можно было бы написать и просто –QaxCORE-AVX2 – как мы помним, в дефолтной baseline версии будет код, оптимизированный с использованием SSE2 инструкций.

Кстати, интересно глянуть и на ASM листинг. Добавив опцию –S (к опциям –QaxAVX,CORE-AVX2), получаем соответствующий файл с расширением *.asm на выходе. В нём видно, что сгенерировалось три версии инструкций, причём эти версии находятся в разных местах листинга:

lea       r8, QWORD PTR [rax+rcx*8]                     ;76.2
vcvtdq2pd ymm15, xmm13                                  ;76.2
add       rcx, 16                                       ;76.2
vextracti128 xmm14, ymm13, 1                            ;76.2
vcvtdq2pd ymm14, xmm14                                  ;76.2
vpaddd    ymm13, ymm13, ymm4                            ;76.2
vfmadd213pd ymm15, ymm5, ymm0                           ;76.2
...
lea       r8, QWORD PTR [rax+rcx*8]                     ;76.2
vpaddd    xmm5, xmm5, xmm1                              ;76.2
vmulpd    ymm15, ymm3, ymm15                            ;76.2
add       rcx, 16                                       ;76.2
vaddpd    ymm15, ymm2, ymm15                            ;76.2
vmovupd   YMMWORD PTR [imagerel(a)+rbp+r8], ymm15       ;76.2
vcvtdq2pd ymm15, xmm5                                   ;76.2
...
lea       r8, QWORD PTR [rax+rcx*8]                     ;76.2
movaps    XMMWORD PTR [imagerel(a)+rbp+r8], xmm15       ;76.2
add       rcx, 8                                        ;76.2
cvtdq2pd  xmm15, xmm14                                  ;76.2
mulpd     xmm15, xmm1                                   ;76.2
addpd     xmm15, xmm5                                   ;76.2
paddd     xmm14, xmm3                                   ;76.2

Вот как-то так работают processor-specific оптимизации в интеловском компиляторе. Надеюсь было интересно и познавательно.  До новых встреч!

Immagine icona: 

  • Technical Article
  • Ottimizzazione
  • Vettorizzazione
  • Compilatore C++ Intel®
  • Intel® C++ Composer XE
  • Intel® Composer XE
  • Compilatore Fortran Intel®
  • Intel® Fortran Composer XE
  • Intel® Parallel Composer
  • Intel® Visual Fortran Composer XE
  • Intel® Streaming SIMD Extensions
  • C/C++
  • Fortran
  • Sviluppatori
  • Linux*
  • Microsoft Windows* (XP, Vista, 7)
  • Apple OS X*
  • Limited Time Discount! Upgrade to Current Intel Visual Fortran and Save!

    $
    0
    0

    Are you still using an old, no longer supported version of Intel Visual Fortran? Now through June 30, 2014, you can upgrade to Intel Visual Fortran Composer XE 2013 SP1 and save up to 60%.

    • Eligible products: Intel® Visual Fortran Composer XE for Windows or Intel® Visual Fortran Compiler Standard and Professional license (no restriction on version)
    • Stay with Intel Visual Fortran for Windows or upgrade to Intel Visual Fortran Studio XE, Intel Composer XE, or Intel Parallel Studio XE – same type of license
    • Serial number for the existing Intel Fortran compiler for Windows license with expired support is required to order
    • Offer ends June 30, 2014

    For more information, see Update Your Fortran Compiler

    Intel Software Tools Technical Webinar Series

    $
    0
    0

    These free technical webinars cover tips and techniques that will help sharpen your development skills to create faster, more reliable applications. Technical experts will cover topics ranging from vectorization, code migration, code optimization, using advanced threading techniques (e.g., OpenMP 4.0, Intel® Cilk™ Plus, Intel® TBB), and error checking. Bring programming questions to the live session for our technical experts to answer. A replay of each webinar will be available shortly after the live session so you can share with those unable to attend the live session.

    See http://software.intel.com/en-us/articles/intel-software-tools-technical-... for more information and to register.


    Unable to install the Fortran(x64)

    $
    0
    0

    I have install Visual studio 2008 on my computer and now I want to install the fortran (X64). However, the installation failed and I got the following message:

    "Unable to install the integration into Visual Studio. Failure in"C:\\program files (86)\Microsoft Visual Studio 9.0\IntelFortran \VFPackages\integrate.bat""c:\\program files(86)\Microsoft Visual Studio 9.0\Common7\Tools" (see picture)

    [[{"fid":"320507","view_mode":"default","fields":{"format":"default","field_file_image_alt_text[und][0][value]":"","field_file_image_title_text[und][0][value]":"","field_tags[und]":""},"type":"media","attributes":{"class":"media-element file-default"}}]]

    I found a post (https://software.intel.com/en-us/forums/topic/284459) regarding this problem, the solutions in that post didn't work for me.

    Anyone know how to deal with this?

    Thanks.

    Stack Trace

    $
    0
    0

     Hello

       I am trying to figure out what is wrong with my program because I caught an segmentation fault.I would like to know I can debug it to get the complete stack trace (which options). I also would like to know if I can do that using devenv.exe at the command prompt for any executable without opening the IDE

     

       thanks

    Visual Fortran run-time error

    $
    0
    0

    I am in the process of running a exe file, and shortly after the start of the running the exe stops running and displays a WIndows box headed 'Visual Fortran run-time error' with the following message:

    forrtl: severe (157): Program Exception - access violation

    Image PC Routine Line Source

    roughcal.exe 00412E76 Unknown  Unknown  Unknown 

    The message only appears when I try to run this exe file. Other .exe files are ok and run very well.

    Anyone know how to deal with this problem?

    AllegatoDimensione
    Scaricaproblem.png82.7 KB

    F77 Data statement to F90 parameter - something not quite right

    $
    0
    0

    Here I go again - messing w/ F77 code from the late 90s.  This little subroutine has been converted to F90 but something's not quite right w/ the conversion of the 2 DATA statements.  The parameter statement I have "seems" right but compiler gives:

    Error: The shapes of the array expressions do not conform.   for [UPCASE],  [LWCASE], [INDCHECK] & [RUNSTREAM]

    Strangely, this line gives no compiler error but doesn't seem equivalent:

    character(1), parameter :: UPCASE = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', lwcase = 'abcdefghijklmnopqrstuvwxyz'

    Is the real trouble the interaction with the INDEX intrinsic?

    Full code snippet is here:

    subroutine lowerUPPER(iString,Runstream)
    !================================================================================================100
    ! Purpose: To convert all characters from lower case to UPPER CASE (using INDEX intrinsic function).
    !          Note that the character(80) 'Runstream' Variable Includes the Original Case for Echoing
    !          and for Later Use To Retrieve Filenames.
    !================================================================================================100
    implicit none
    !Local variables:
    !character     :: UPCASE*26
    !character     :: lwcase*26
    character*(*) :: Runstream
    integer(4)    :: I, iString, IndCheck
    
    !Variable Initializations:
    !DATA UPCASE/'ABCDEFGHIJKLMNOPQRSTUVWXYZ'/
    !DATA LWCASE/'abcdefghijklmnopqrstuvwxyz'/
    
    character(1), dimension(26), parameter :: UPCASE = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', lwcase = 'abcdefghijklmnopqrstuvwxyz'
    
          DO 20 I = 1, iString
             if (Runstream(I:I) .NE. '') then
                IndCheck = INDEX(lwcase,Runstream(I:I))
                if (IndCheck .NE. 0) then
                   Runstream(I:I) = UPCASE(IndCheck:IndCheck)
                endif
             endif
       20 EndDo
    
          return
    
    End subroutine lowerUPPER

    Setting upper and lower limits to integer variable values

    $
    0
    0

    Hi,

    I would like to create a Percentage Type variable that can only have integer values between 0 and 100.  I can't see a way of specifying such a type.  The only limits that I can see are those that can be applied is to dimensions, not values.  Am I missing something, please?

    Viewing all 1424 articles
    Browse latest View live


    <script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>