Pardiso memory leak

Pardiso memory leak



I have the following subroutine works perfectly. However, I am using it in a nonlinear solution. I call it many times in a program. After each call, the memory usage increases, though I am using 'Release memory' option at the end of the subroutine. Does anyone have an idea what may be the reason for memory increase here? Is there any way of chasing the variables at the begining and the end of subroutine; so that I can see which of them stay unreleased?

Many thanks.



      USE XX  ! this is module of already allocated variables


      integer omp_get_max_threads

      external omp_get_max_threads

      !This is OK in both cases

      INTEGER*8 pt(64)

      !All other variables

      INTEGER maxfct, mnum, mtype, phase, n, nrhs, error, msglvl

      INTEGER i, idum

      INTEGER iparm(64)           

      REAL*8 waltime1, waltime2, ddum

      complex*16 cdum

      ! Fill all arrays containing matrix data.

      DATA nrhs /1/, maxfct /1/, mnum /1/

      n = nodes   


      !Set up PARDISO control parameter


      do i = 1, 64

            iparm(i) = 0

      end do

      iparm(1) = 1 ! no solver default

      iparm(2) = 2 ! fill-in reordering from METIS

      iparm(3) = mkl_get_max_threads()

      ! numbers of processors, value of MKL_NUM_THREADS

      iparm(4) = 0 ! no iterative-direct algorithm

      iparm(5) = 0 ! no user fill-in reducing permutation

      iparm(6) = 0 ! =0 solution on the first n components of x

      iparm(7) = 0 ! not in use

      iparm(8) = 9 ! numbers of iterative refinement steps

      iparm(9) = 0 ! not in use

      iparm(10) = 13 ! perturb the pivot elements with 1E-13

      iparm(11) = 1 ! use nonsymmetric permutation and scaling MPS

      iparm(12) = 0 ! not in use

      iparm(13) = 0 ! not in use

      iparm(14) = 0 ! Output: number of perturbed pivots

      iparm(15) = 0 ! not in use

      iparm(16) = 0 ! not in use

      iparm(17) = 0 ! not in use

      iparm(18) = -1 ! Output: number of nonzeros in the factor LU

      iparm(19) = -1 ! Output: Mflops for LU factorization

      iparm(20) = 0 ! Output: Numbers of CG Iterations

      iparm(60) = 1 ! OOC core selection

      error = 0 ! initialize error flag

      msglvl = 1 ! print statistical information

      mtype = 13 ! COMPLEX unsymmetric

      !Initialize the internal solver memory pointer. This is only

      !necessary for the FIRST call of the PARDISO solver.

            do i = 1, 64

                  pt(i) = 0

            end do


      !Reordering and Symbolic Factorization, This step also allocates

      !all memory that is necessary for the factorization

      phase = 11 ! only reordering and symbolic factorization

      CALL pardiso (pt,maxfct,mnum,mtype,phase,nodes, valuesCoo,  &

        rowIndex, colsCoo, idum, nrhs, iparm, msglvl, cdum, cdum, error)

      WRITE(*,*) 'Reordering completed ... '

      IF (error .NE. 0) THEN

             WRITE(*,*) 'The following ERROR was detected: ', error


      END IF

      WRITE(*,*) 'Number of nonzeros in factors = ',iparm(18)

      WRITE(*,*) 'Number of factorization MFLOPS = ',iparm(19)



      phase = 22 ! only factorization

      CALL pardiso(pt,maxfct,mnum,mtype, phase,nodes, valuesCoo,  &

        rowIndex, colsCoo,idum, nrhs, iparm, msglvl, cdum, cdum, error)

      WRITE(*,*) 'Factorization completed ... '

      IF (error .NE. 0) THEN

            WRITE(*,*) 'The following ERROR was detected: ', error




      !Back substitution and iterative refinement

      iparm(8) = 2 ! max numbers of iterative refinement steps

      phase = 33 ! only factorization

!      do i = 1, n

!            b(i) = 1.d0

!      end do


      CALL pardiso(pt,maxfct,mnum,mtype,phase,nodes, valuesCoo,  &

        rowIndex,colsCoo,idum, nrhs, iparm, msglvl, bglb, sln, error)

      WRITE(*,*) 'Solve completed ... '


      !Termination and release of memory

      phase = -1 ! release internal memory


      CALL pardiso (pt, maxfct, mnum, mtype, phase, nodes, ddum, idum, idum,  &

      idum, nrhs, iparm, msglvl, ddum, ddum, error)




Downloadapplication/vnd.openxmlformats-officedocument.wordprocessingml.document subroutine-sparse.docx15.77 KB
2 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


In order to improve the performance, Intel MKL internally maintain one memory buffer, such buffer will be freed when the application exit.  But if you want to free these buffers by yourself, you need to call some MKL APIs explicitly. Check the MKL user guide for more info:


Leave a Comment

Please sign in to add a comment. Not a member? Join today