Thanks for the clarification Barry! And Stefano, thanks for your suggestion!

2018-02-01 20:08 GMT+01:00 Stefano Zampini <stefano.zamp...@gmail.com>:

> Note that you don’t need to assemble the 2x2 block matrix, as the solution
> can be computed via a Schur complement argument
>
> given the matrix [I  B; C I] and rhs [f1,f2], you can solve S x_2 = f1 - B
> f2, with S = I - CB, and then obtain x_1 = f1 - B x_2.
>
> On Feb 1, 2018, at 8:34 PM, Adrián Amor <aa...@pa.uc3m.es> wrote:
>
> Thanks, it's true that with MAT_IGNORE_ZERO_ENTRIES I get the same
> performance. I assumed that explicitly calling to 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!
>
> 2018-02-01 16:20 GMT+01:00 Smith, Barry F. <bsm...@mcs.anl.gov>:
>
>>
>> 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.
>>
>> 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
>>
>> 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.
>>
>> 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.
>>
>>   Barry
>>
>> > On Feb 1, 2018, at 2:45 AM, Adrián Amor <aa...@pa.uc3m.es> wrote:
>> >
>> > Hi,
>> >
>> > 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:
>> > (Identity                     (50% dense)block
>> > (50% dense)block     Identity)
>> >
>> > 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:
>> > MatCreateSeqAIJ
>> > To preallocate the matrix, and then I have tried:
>> > 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.
>> > 2. To call MatSetValues only once per row. If the identity matrix has a
>> dimension of 22x22, I call MatSetValues only 22 times.
>> >
>> > 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).
>> >
>> > 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.
>> >
>> > Please help me! Thanks!
>> >
>> > Adrian.
>>
>>
>
>

Reply via email to