Comment 10 for bug 927539

Hi Garth,

> I don't like the look of this. It's mixing a linear algebra issue
> (PETSc bug?) with the assembler. Moreover, it will be horrendously
> slow if the diagonal has not been allocated during the initialisation
> of the matrix.
I agree. I was suggesting it more as a way of prompting better
suggestions as this has become a major issue for me with petsc-dev.

> There is a suggestion in the thread to make the sparsity pattern
> contain the diagonal entry, which seems a reasonable option, but there
> is not answer on whether this solves the problem. Would it solve the
> problem?
In all the examples I've looked at the sparsity returned by
AssemblerTools::init_global_tensor *does* contain the diagonal entry.
The problem arises when the tensor is finalized and entries in the
sparsity which haven't been used are collapsed out. Hence the petsc
error about the matrix being in the wrong state and missing the diagonal
and also why ident_zeros is painfully slow (and in petsc-dev produces
lots of very verbose errors).

Looking at the code again a possible alternative way to get around this
might be to set finalize_tensor to false and finalize the assembly
separately (after calling ident_zeros if you want 1s on the diagonal or
some other routine to set the zeros on the diagonal if not)? This would
at least separate out the linear algebra issue from the assembly and
require minimal code modification.

Let me know what I'm missing.

Cheers,
Cian

>
> Garth
>
> On 9 May 2012 06:05, Cian Wilson<email address hidden> wrote:
>> ** Patch added: "diag.diff"
>> https://bugs.launchpad.net/dolfin/+bug/927539/+attachment/3137879/+files/diag.diff
>>
>> --
>> You received this bug notification because you are a member of DOLFIN
>> Core Team, which is subscribed to DOLFIN.
>> https://bugs.launchpad.net/bugs/927539
>>
>> Title:
>> Missing diagonals after subdomain assembly
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/dolfin/+bug/927539/+subscriptions