I need Intel Parallel Studio XE 2017 with Intel Fortran compiler 17.0 to create executables for some engineering simulations. This work is related to my PhD research project. I was wondering where I can download "Intel Parallel Studio XE 2017" and get license for it. I am looking for a student license.
Any help will be greatly appreciated
Thanks for your response. I have to link user-defined subroutine to a commercial software. For that, it will be great if I use Intel Parallel Studio XE 2017. I even do not see a new version of Intel Parallel Studio XE on Intel website. Can you please share the link where I can download the new version of Intel Parallel Studio XE?
Parallel Studio is no longer sold. In its place, Intel offers OneAPI; the pricing model has also changed. The new product no longer requires license fees to be paid or a license file/license manager to be installed; paid support can be purchased if desired by the user.
Download the new release and, if you run into problems with making it work with the commercial package, ask for help from the package vendor or in this forum.
You can get the current version by installing the Intel oneAPI Base and HPC Toolkits, which you can get here . You should have VS2017 or VS2019 installed first (Community Edition is fine), with the "Desktop Development for C++" component installed.
From the Base toolkit, you need only "Intel Distribution for GDB" as this contains the Fortran debugging support for Visual Studio. From the HPC Toolkit you need only Intel Fortran. You should also install the Intel Fortran Compiler Classic Runtime.
No license is needed.
Thanks for explaining what should be installed. I have installed all the components that you mentioned in your response. However, when I try to install, I get the following error:
"NMAKE: Fatal error U1077: ''ifort.exe": return code: 0X1.
Do you have any what might be wrong? NMAKE is the file that I am using to compile the source codes. "ifort.exe" is the compiler.
You are probably attempting to build from a Visual C++ command window that is not configured to build using the Intel Fortran compiler.
Open an Intel OneAPI command window from the Start menu of Windows, and run the nmake command (or batch file that calls nmake) from that command window.
From your screenshot (it is far better to copy and paste text into your messages than to attach screenshots as images), it is clear that Nmake, the compiler and the OneAPI installation are functioning as is to be expected. What has happened is that the Fortran source file being compiled has errors that the compiler detected and reported.
Read the error messages and fix the source accordingly. Simply reporting "Nmake error Uxxx..." makes no distinction between not having a Fortran compiler, compilation errors, linker errors and runtime errors. These distinctions are important since the remedy depends on the specific symptoms.
Thanks for your response. I have noticed the "Common Block error" that appeared in the source file. However, the issue is that these source files are provided by the LSTC (a commercial FEA code provider). I am trying to run these source files without any change. I am not sure why this error is appearing. Every researcher uses these files as it is.
One thing that is different is that LSTC recommends to use the same versions of the MVS and Intel Fortran compiler that LSTC used to create the source files and related executables. I was wondering whether this error could be due to that reason. Please advise. Or you think using the later versions of MVS and Intel compiler should not an issue.
It is common for new versions of compilers to catch errors older versions did not. The OpenMP syntax this source use is apparently in error, maybe not detected by older compiler versions. I am not an OpenMP expert, but the message seems reasonably clear, and you should be able to correct the source.
A program may be correct when compiled without OpenMP, but contain errors regarding how it is being parallelized. Thus, when you specify /Qopenmp, errors may arise which were not present in the sequential version of the program.
I suggest that you try to get the program to work correctly before attempting to turn on OpenMP to parallelize and make the program run faster. If you leave out /Qopenmp, the compiler will ignore all $OMP directives and the errors related to parallelization.
It is not possible to comment on specific errors in source codes without having access to those source codes. You could ask if dyn21.F was verified in sequential mode or in parallel mode.
In general, it is not beneficial to try to use an older version of the compiler as a means of removing errors in the program.
By leaving out OpenMP option, I am able to build lsdyna.exe. However, I am having "error LNK2001: unresolved external symbol _iob fun". This error has been repeated between libdyna.lib and object files. At the end, I am getting the following message:
Warning "lsdyna.exe: image being generated due to /Force option/. Image may not run. ''
Any idea, how I can get rid of the above errors. Thanks
You cannot get the 2016 version.
I am pretty sure that the symbol you are missing is __iob_func (with a c at the end). This is a Microsoft Visual C++ symbol that MSVC is no longer supplying. The error tells me that the libraries you are linking against were compiled with a very old version of the Microsoft C++ compiler (prior to VS2015).
The only solution I can think of is to ask for a version of those libraries built with a more recent MSVC. Nothing you can do on the Fortran side will fix this.
Thanks Steve for getting back. You are right. There are two symbols. Most of the errors contains iob_func and some contains fscanf. Those libraries were built using "Microsoft Visual C++ 2013 x64 cross tools". Therefore, it is recommended to use the same version to compile user defined codes. However, oneAPI kit requires to use MSV 2017 or 2019. I need to check back with LSTC for the latest version, and I hope they would have used a comparatively newer version.
As a former language and OS library developer, let me vent a bit about how irresponsible it is for commercial products to drop library entry points, referenced by compiled code, in newer versions of the product If you want to add new symbols referenced by the newer product, fine, but don't break old objects. Back when I worked for DEC on the VMS compilers, this was an absolute no-no and we had tests to check for it.
The Intel Fortran team (started out as DEC) maintains the philosophy of not breaking old objects (with rare exceptions due to bugs), but I know some other Intel teams (cough..MKL..cough) do not.