[petsc-dev] API changes in MatIS

[Stefano Zampini]

2012/5/11 Jed Brown <jedbrown at mcs.anl.gov>

> I don't like this idea of the matrix type determining the algorithm, I'd
> rather choose the algorithm.
>

This is note the case in my BDDC: it is the algorithm that drives the type
of matrix to be built.


> Can we decouple it by building the prolongation operator P whose columns
> are harmonic extension of the coarse nodes? Then the coarse operator looks
> like P^T A P just like multigrid (for which we have a matop) instead of
> looking like a Schur complement.
>
I already have it. Each process has its local part, splitted in the
matrices pcbddc->coarse_phi_B (local interface nodes) and  (optionally)
pcbddc->coarse_phi_D (local dirichlet nodes). You can see that I used them
to check the correctness of the coarse local part in the code (see line
1702 of bddc.c). I build the local part of coarse matrix , but I don't use
the expensive PtAP operation. Instead, I evaluate it by exploiting
properties of the saddle point problem they come from.




> On May 10, 2012 2:42 PM, "Stefano Zampini" <stefano.zampini at gmail.com>
> wrote:
>
>>
>> This is to do recursive BDDC or what?
>>>
>>>
>> Yes. When creating the BDDC coarse matrix, now the code has three 3
>> options
>>
>> A) coarse matrix is a MATIS -> multilevel BDDC
>> B) coarse matrix is SEQAIJ -> one level BDDC with only one proc (or all)
>> solving directly the coarse problem
>> C) coarse matrix is MPIAIJ -> one level  BDDC with a parallel direct
>> solve
>>
>> I think that PCREDUNDANT can do the job in both cases of options B if the
>> matrix would be parallel.
>>
>


-- 
Stefano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120511/3b5bf939/attachment.html>