<div dir="ltr">Thanks, it's true that with <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">MAT_IGNORE_ZERO_ENTRIES<span> I get the same performance. I assumed that explicitly calling to </span></span><span style="font-size:12.8px">KSPSetType(petsc_ksp, KSPBCGS, petsc_ierr) it wouldn't use the direct solver from PETSC. Thank you for the detailed response, it was really convenient!</span></div><div class="gmail_extra"><br><div class="gmail_quote">2018-02-01 16:20 GMT+01:00 Smith, Barry F. <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
1)   By default if you call MatSetValues() with a zero element the sparse Mat will store the 0 into the matrix. If you do not call it with zero elements then it does not create a zero entry for that location.<br>
<br>
2)   Many of the preconditioners in PETSc are based on "nonzero entries" in sparse matrices (here a nonzero entry simply means any location in a matrix where a value is stored -- even if the value is zero). In particular ILU(0) does a LU on the "nonzero" structure of the matrix<br>
<br>
Hence in your case it is doing ILU(0) on a dense matrix since you set all the entries in the matrix and thus producing a direct solver.<br>
<br>
The lesson is you should only be setting true nonzero values into the matrix, not zero entries. There is a MatOption MAT_IGNORE_ZERO_ENTRIES which, if you set it, prevents the matrix from creating a location for the zero values. If you set this first on the matrix then your two approaches will result in the same preconditioner and same iterative convergence.<br>
<span class="HOEnZb"><font color="#888888"><br>
  Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On Feb 1, 2018, at 2:45 AM, Adrián Amor <<a href="mailto:aamor@pa.uc3m.es">aamor@pa.uc3m.es</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> First, I am a novice in the use of PETSC so apologies for having a newbie mistake, but maybe you can help me! I am solving a matrix of the kind:<br>
> (Identity                     (50% dense)block<br>
> (50% dense)block     Identity)<br>
><br>
> I have found a problem in the performance of the solver when I treat the diagonal blocks as sparse matrices in FORTRAN. In other words, I use the routine:<br>
> MatCreateSeqAIJ<br>
> To preallocate the matrix, and then I have tried:<br>
> 1. To call MatSetValues for all the values of the identity matrices. I mean, if the identity matrix has a dimension of 22x22, I call MatSetValues 22*22 times.<br>
> 2. To call MatSetValues only once per row. If the identity matrix has a dimension of 22x22, I call MatSetValues only 22 times.<br>
><br>
> With the case 1, the iterative solver (I have tried with the default one and KSPBCGS) only takes one iteration to converge and it converges with a residual of 1E-14. However, with the case 2, the iterative solver takes, say, 9 iterations and converges with a residual of 1E-04. The matrices that are loaded into PETSC are exactly the same (I have written them to a file from the matrix which is solved, getting it with MatGetValues).<br>
><br>
> What can be happening? I know that the fact that only takes one iteration is because the iterative solver is "lucky" and its first guess is the right one, but I don't understand the difference in the performance since the matrix is the same. I would like to use the case 2 since my matrices are quite large and it's much more efficient.<br>
><br>
> Please help me! Thanks!<br>
><br>
> Adrian.<br>
<br>
</div></div></blockquote></div><br></div>