I am using Pardiso and everything works well except one thing. I noticed that my application keeps increasing the memory usage when Pardiso is repeatedly called. I found in the documentation that I should use the phase -1 to release all internal memory. I am trying to do so, but I am getting a "forrtl: severe(157): Program Exception - access violation" error.
I use the same call to Pardiso, just phase is changed to -1; is this wrong?
integer(4) :: pt(64) ! Solver internal data address pointer integer(4) :: mtype ! Matrix type integer(4) :: iparm(64) ! Pass information to and from Pardiso integer(4) :: nDimension integer(4), parameter :: numberOfRHS = 1 ! number of right-hand sides integer(4) :: maxfct, mnum, mtype, phase, error, msglvl do i=1,64 pt(i) = 0 enddo do i=1,64 iparm(i) = 0 end do mtype = 11 ! real + nonsymmetric maxfct = 1 ! maximum number of numerical factorizations mnum = 1 ! what factorization to use msglvl = 0 ! message level, 0 = no output, 1 = statistical information error = 0 ! error flag initialization call PardisoInit ( pt, mtype, iparm ) phase = 13 call PARDISO ( pt, maxfct, mnum, mtype, phase, nDimension, Avec, iVec, jVec, + perm, numberOfRHS, iParm, msglvl, Bmat, Xmat, error ) phase = -1 call PARDISO ( pt, maxfct, mnum, mtype, phase, nDimension, Avec, iVec, jVec, + perm, numberOfRHS, iParm, msglvl, Bmat, Xmat, error )
Avec(:) is real*8, iVec(:), jVec(:), perm(:) are integer(4), Bmat(:,:) and Xmat(:,:) are real*8, all of them allocatable. I checked that they are initialized.
Question 1: Any ideas why phase -1 crashes with the access violation error?
Question 2: The first call to Pardiso yield error = 0, so I hope there is nothing wrong about data passed to it. I noticed some people use dummy integers and doubles in places of those arguments that are not needed in particular Pardiso phases; is this acceptable/supported ?
I tried checking MKL cookbook samples, but the example for Pardiso is for C, not Fortran.
Which version of MKL did you use, and which version of the Intel Fortran compiler? OS version?
I ran your code with an old version of IFort (Version 188.8.131.52) and the associated MKL, and it ran with no errors.
I use Intel Parallel Studio XE 2016 Composer Edition Update 4 in Visual Studio 2010 Professional SP1.
I wanted to try the same example in Intel Parallel Studio XE 2017 Composer Edition Update 2 in Visual Studio 2015 Community, but it does not compile due to an internal compiler error. Should I report this in another forum?
1>------ Rebuild All started: Project: Pardiso_Test, Configuration: Debug x64 ------
1>Deleting intermediate files and output files for project 'Pardiso_Test', configuration 'Debug|x64'.
1>Compiling with Intel(R) Visual Fortran Compiler 184.108.40.206 [Intel(R) 64]...
1>fortcom: Fatal: There has been an internal compiler error (C0000005).
1>ifort: error #10298: problem during post processing of parallel object compilation
1>compilation aborted for D:\Source_Fortran\VITREOUS\Intel\Pardiso-Reduced - Copy\solver_matrix_Pardiso.for (code 1)
The ICE is gone if I remove calls to Pardiso...
How do I find out which version of MKL is used? I guess it is the one associated with the compiler.
OS is Windows 7 Professional SP1 64-bit.
It seems that you have answered yourself regarding the MKL version, and your code of #2 queries and prints out the MKL version.
I built your example again at the command line, this time on Windows 10 X64 with VS2010 and Parallel Studio 2016U4. As in my earlier test, the program ran with no errors. There must be something specific to your system that is causing a problem.
Regarding the ICE with the 2017U2 compiler, please report in the Fortran compiler forum. Try compiling without /MP (parallel compile).
Thank you very much for your trials, even though they are making me desperate as I do not see any direction where to go from here.
Anyone from Intel, would you please try recommending what else I can try to make the simple example work?
Here is something that may be useful in pinpointing the problem: please recompile and run with (i) optimizations off, and (ii) traceback enabled and /link /map specified. You should get addresses, line numbers and routine names in the traceback. With that additional information, we'll know where the crash occurred. This will take only a few minutes of time, and will be of help to the Intel people when they respond.
I am using testing the Debug x64 configuration where /Od and /traceback are already used. The /map linker option generates a file during linking. Regarding the /link option, do you mean I should use it with the /map option?
Anyway, I used the command line to run the Debug x64 configuration executable. I added mkl_avx2.dll, mkl_core.dll, mkl_def.dll and mkl_intel_thread.dll to the folder with the executable; I took them from C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016\windows\redist\intel64_win\mkl. When i run the executable, I get the same output like if I debug the application in Visual Studio:
forrtl: severe (157): Program Exception - access violation
Image PC Routine Line Source
mkl_core.dll 000007FEC698EDF0 Unknown Unknown Unknown
mkl_core.dll 000007FEC66AF4AA Unknown Unknown Unknown
mkl_core.dll 000007FEC67500AE Unknown Unknown Unknown
mkl_core.dll 000007FEC66BE787 Unknown Unknown Unknown
Pardiso_Test.exe 000000013F5C2609 MATRIXSOLVERPARDI 179 solver_matri
Pardiso_Test.exe 000000013F5C4BDE MAIN__ 15 pardiso_test
Pardiso_Test.exe 000000013F5C70CE Unknown Unknown Unknown
Pardiso_Test.exe 000000013F5C520C Unknown Unknown Unknown
Pardiso_Test.exe 000000013F5C505E Unknown Unknown Unknown
kernel32.dll 0000000076AE59CD Unknown Unknown Unknown
ntdll.dll 0000000076D1A561 Unknown Unknown Unknown
This is probably where all your troubles started: The array PT is supposed to be a "pointer" array for internal use in Pardiso. Each element of PT is 4 or 8 bytes for IA-32, and 8 bytes for Intel-64. In your program, however, you only have INTEGER*4. You have, therefore, an incorrect type and an insufficient memory block allocated for PT.
Note, in addition, that in recent years the recommended type for PT is TYPE(MKL_PARDISO_HANDLE) rather than INTEGER*4 or INTEGER*8. If you use this new style declaration for PT, you will also be forced to include MKL_PARDISO.FI or USE the corresponding MKL module, so the length will be correct whether you build for IA-32 or Intel-64.
Your are right that the array PT should be a different type.
I changed it to integer(8) in IPS 2016 and I am now able to run the sample code without the access violation error.
I changed the type to integer(8) also in IPS 2017 and I still get the internal compiler error.
I would like to try using TYPE(MKL_PARDISO_HANDLE), but I do not know how.
I am sorry to keep asking possibly silly questions; I am a beginner, inexperienced in this "advanced" stuff.
Thank you very much for your kind help, tips and advices; I appreciate it.
There is a file called mkl_pardiso.f90 in the MKL include directory. If you compile it, the module file mkl_pardiso.mod will be created (the module files are specific to IA32 and Intel64, so put the module file into the appropriate directory -- .../mkl/include/ia32 or .../mkl/include/intel64. This only needs to be done once for a given compiler release. Once this is done, you can add USE MKL_PARDISO in your source files in order to have the MKL_PARDISO_HANDLE and other related declarations available.
Thank you for your detailed instructions; I will try them soon.
In between, I decided to use integer(8) for the PT array, because it works in the small example.
My current problem is that after correcting the definition of the PT array to integer(8), I still get the access violation error when calling the Pardiso routine with phase=-1.
I am using the same data for A, jA, iA, B and X; the phase 13 works well and error is 0 after it finishes, but while phase -1 finishes with error 0 in the small example, it crashes with the access violation error in the original application. Both small and original application yield the same result X in the phase 13, output from the Pardiso routine is almost identical (completely the same information about arrays, calculation times are slightly different because I use 4 threads).
Since the function solveLinearSystemPardiso is the same in both applications (see the small example) and arrays and settings are the same, I do not know what could be causing the access violation error.
It is not feasible to read all the posts in this thread and reconstruct the latest version of the source that is still giving you the access error. Bugs (in your code or in MKL or even the OS) are often sensitive to the environment in which they exist. You may think that all the relevant parts are "the same", but there could be side effects elsewhere.
Please post a "reproducer" again, and I'll take a look.
I am sorry for not being specific; I agree it is not possible to try resolving any issues then. My apologies.
I think I found the cause of the problem. I was accessing the pt array directly in subroutine initializePardiso ( ). I removed following code from the subroutine
do i=1,64 pt(i) = 0 enddo do i=1,64 iparm(i) = 0 end do
and replaced it by
mtype = 11 call PardisoInit ( pt, mtype, iparm )
The call to PardisoInit was then deleted in function solveLinearSystemPardiso ( ) not to have it called twice. I am no longer getting any access violation errors.
I tried one more thing to see how the pt array can be defined. Instead of defining it as integer(8), I added this code
module PardisoPrivate type MKL_PARDISO_HANDLE integer(kind=8) dummy end type end module PardisoPrivate
and defined the pt array as type(MKL_PARDISO_HANDLE). Functionality remained the same and no errors were issued.
Finally, when trying to save data used by the Pardiso solver, I tried call pardiso_handle_store ( pt, "", error ) right after PardisoInit, and I am getting access violation error. I do not need to save pt, I just came across this while trying to resolve my original problem.