I am calling pardiso with mtype=11 (real nonsymmetric).
I first call it with phase=11, iparm(1)=0, and the result is error=0. So all is good.
I then call it with phase=22, and error=0. So all is still good.
I then call it multiple times with phase=33 with different rhs's. The first two calls return error=0, but the third call returns error=-4. What does this mean? Does -4 mean I have a bug somewhere, or can -4 be generated by something it doesn't like about the rhs? The rhs for the third call looks normal to me (i.e. no outlier elements).
I ran an unsymmetric problem with n=576, n_nz=2088 (matrix data file in Matrix Market format) with three different right hand sides, and there were no cases in which the error argument came back with a non-zero value. The code to read the data files and call Pardiso was in C. Conclusion: if there is a problem, it is not generic, but may surface only with specific inputs to Pardiso.
Can you make up an example (code + data) with the failure that you described? Did you ask for iterative refinement? If not, I don't see why you should get that specific error (-4).
Thanks for the reply, mecej4. The main thing I am trying to find out are the implications of the -4 error code. I read the documentation about it, and looked at the iparam values returned by the call, but I cannot figure out what pardiso is trying to tell me with this error code. I don't want to burden anyone by sending the matrix and the three rhs's. If someone (pardiso's developers?) can tell me what sort of rhs can cause -4, that will give me a clue as to what to look for. Or if someone can say that the rhs cannot be the reason for -4, that would also help me.
For the time being, I am having my code just ignore the -4 error and continue running. Results agree with what I get using umfpack. Umfpack doesn't generate any error codes for this case.
The code+data that you mentioned did not come from me. I have run lots of other test cases and they run fine and do not generate any nonzero error codes.
how about you define the nrhs from the begin of phase=11 call. I recalled there is issue about nrhs change in phase =33 step in early MKL version.
There are two workaround, 1. define the nrhs=max of possible value at the begin of program. or use latest version. for example, the MKL 2016 in http://software.intel.com/sites/campaigns/nest/
NRHS has to be one. The calls are part of an Arnoldi iteration to find eigenvalues, so the rhs vectors are generated on the fly one at a time.
I tried installing the MKL for Composer XE 2016, but it would not work with XE 2013. I should point out that I cannot upgrade my version of Composer XE because I am not the administrator of the license.
Thanks for your question.
Can you please provide additional information, so that we can investigate this problem and find the root cause:
Set parameter msglvl to 1 and show me the output info and print number of pivots after factorization step (phase = 22) which value is iparm(30) ( iparm in C ).