question about PARDISO statistical information output

question about PARDISO statistical information output

I set the msglvl input of PARDISO to one so I get statistical information output to the screen, and when I run PARDISO with phase=33 (solve), I get something like this:

================ PARDISO: solving a complex nonsym. system ================

Summary PARDISO: ( solve to solve )




Time solve : 0.166810 s

Time total : 0.527333 s total - sum: 0.360523 s

The time solve is much much less than the "time total", and then the sum actually seems to be the difference. I couldn't find any information in the MKL documentation on this output. What exactly do these times represent? I'm asking because PARDISO isn't performing nearly as fast as I would want it to, and if I could get it to run 3x as fast (by limiting what I guess is overhead before and after the solve?), it would be a huge benefit. Thanks.

16 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Time solve : 0.166810 s - this is the time of the Solution phase ( 33)

0.360523 s == this the time ofReordering + Numeric Factorization (phases 11 and 22 correspondingly)

Time total : 0.527333 s total - sum: 0.360523 s

>>The time solve is much much less than the "time total"

Yes, this is the expected behavior:thereorderingand numeric factorizationphases,take much more time then the solution phase.--Gennady

OK, thanks for the response. I'd like to store the factorization in memory, as I'm calling the solve multiple times iteratively with different right-hand-sides. I've read about this on the forum, and it seems like the way to do this is to either use the maxfct/mnum functionality, or to store the pointer when you do the factorization somewhere in memory. I have several matrices of different sizes that I would like to store the factorizations for, so I'm guessing I should use the "store the pointers" approach.

So I have the pardiso pointer stored in void *pardisoPt[64]. I can create a new pointer with void *myPardisoPt[64], and then set them equal to each other iteratively:

for (i = 0; i < 64; i++) {



And then when I call PARDISO with phase=33, I'd use myPardisoPt, and it would use the factorization it's already done? Thanks.

One other thing: when I try to do an out-of-core solution, I get:

pardiso_read_ooc_file: Read error: No such file or directory

PARDISO_OOC_NUMBER_OF_READ_NOT_EQUAL_COUNT occured: blkslv1_unsym_ooc read 1 lindx

By default, it should store stuff in the current working directory, right? I have ooc_temp files stored in the directory; do I have to manually set the environment variable for the path PARDISO looks in?

I don't mean to spam the topic, but one more question:

When I set the matrix type to 6 (Complex and symmetric matrix), is this complex and symmetric or complex and hermitian? i.e. if the matrix element (1,2) is 1+2j, is the matrix element (2,1) 1+2j or 1-2j?

this is Complex and Symmetric but nothermitian ==>(1,2) is 1+2j, then the matrix element (2,1) 1+2j--Gennady

yes, you can set the environmental variablesMKL_PARDISO_OOC_PATH.MKL_PARDISO_OOC_PATH = \ooc_filewhere - the directory for storing data,
ooc_file - file name without extension

OK, thanks a lot for the responses. So in my original post, where I'm calling PARDISO with phase=33, it's re-doing phase=11 and phase=22? I can internally save the factorizations, right? Either with the maxfct/mnum functionality, or by saving the PARDISO pointer in memory?

I think I misunderstand the functionality of maxfct and mnum. That's for matrices with the same sparsity pattern but different values, right? What I have is the exact same matrix where I'm calling solve multiple times with a bunch of different right hand sides. I've already called PARDISO on the matrix with phase=11 and phase=22, so why does it re-dothe reordering and factorizationwhen I call PARDISO with phase=33. How do I make it just do the solve? That would be a huge savings in time. Thanks a lot.

Does anyone know why I can't call PARDISO to just do the solve portion without re-doing phaes 11 and 22? It would be a huge help.

If you didnt change matrix and changed just right hand size (rhs), you can run only phase=33 with new rhs. Let me note that:

1) Should to use same handle() array as on previous phases 11 and 22.

2) Dont run phase=-1, because this phase frees all PARDISO memory and internal data.

I'm assuming by handle() array, you're referring to the pt (solver internal data address pointer) array? I am using that same array every time i call PARDISO (for phase=11, then phase=22, then phase=33). I've declared pardisoPt as the pointer in my header file: void *pardisoPt[64]. The pointer seems to point to the same location every time I call PARDISO, but the first element in the array, pardisoPt[0] seems to increment every time phase=33 is called. In my statistical output, I still get a large amount of time for the "sum" for the solve phase, which apparently means it's redoing the reordering and factorizing every time. I'm not calling PARDISO with phase=-1 until the very end. Does anyone have any ideas as to what's going on?


I am the author of PARDISO. I think you are using iterative refinement and it seems that you are doing two or three solve steps (this is the difference in the "sum" timing)


OK, thanks for the response.Looking at iparmafter factorization shows that there were no perturbed pivots during factorization (iparm(14) is 0), but it's still performing two iterative refinements. Does the solver still do iterative refinements when there were no perturbed pivots? Is therea way to turn perturbed pivots off? I have a complex symmetric matrix (type=6), btw.

EDIT: Can you turn iterative refinement completely off?


Hi,Intel MKL PARDISO does NOT perform itarative refinements ONLY when iparm(8) was set to 0 and there were no pertrubed pivots during the factorization.In all other cases at least 1 iteration refinement step will be performed.And there's no possibility to competely turn-off refinements.Regards,Konstantin

Ahh, ok. I was under the impression that iparm(8) was ignored if there were no perturbed pivots, so I had it set to two and assumed there wouldn't be any refinements. Thanks, that sped up the process a lot.

Leave a Comment

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