[petsc-dev] API changes in MatIS

Stefano Zampini stefano.zampini at gmail.com
Sat May 12 07:09:14 CDT 2012


First, sorry for the long email...

I think the construction of the prolongation/restriction operators, the
local part of the coarse matrix and the assembling (or subassembling) of
the global coarse matrix should all belong to PCIS (with PCBDDC and PCNN as
subclasses). In fact, for both PCBDDC and PCNN all stuffs involved in the
preconditioner application can be viewed as a subassembled matrices
(Prolongation/Restrictions, static condensation also). This would need to
change the actual structure of MATIS and allowing for the creation of
rectangular operators mapping between two different spaces; MATIS creation
will thus need both LocalToGlobalMapping (row mapping) and
GlobalToLocalMapping (column mapping) arguments to be created. A brand new
logic in PCIS setup I would like can be

PCISSetup() /* common to all PCIS methods */
"PCISDealWithAllLocalStuffNeededByTheSpecificNonOverlappingMethod()"
PCISCreateRestrictionAndProlongationOperators(pc)
PCISAssembleLocalCoarseMat(pc)
PCISCreatePartitionOfCoarseMesh(pc,&partition)
PCISAssembleGlobalCoarseMat(pc,partition)

"PCISDealWithAllLocalStuffNeededByTheSpecificNonOverlappingMethod()"  will
contain the construction of the "Neumann" solver (for BDDC, it is actually
a saddle point problem)

For PCBDDC and PCNN:

PCISCreateRestrictionAndProlongation_NN will create a MATIS representing a
default P which, in case of a scalar PDE, will be the constant function
scaled by the partition of unity operator, with global dimensions N x
sum^N_{i=1}pcis->n with N the number of subdomains and pcis->n the size of
the local matis matrix (local dirichlet plus interface nodes) (in case of
more complex vector valued PDEs it will need a MatNearNullSpace object as
already implemented in BDDC)

PCISCreateRestrictionAndProlongation_BDDC: (in case of exact solvers for
the Dirichlet problems) default P will be of size
n_coarse_dofs*sum^N_{i=1}pcis->n_B with local matrices of P the actual
pcbddc->coarse_phi_B

PCISCreateRestrictionAndProlongation_BDDC: (in case of inexact solvers for
the Dirichlet problems) default P will be of size
n_coarse_dofs*sum^N_{i=1}pcis->n with local matrices of P the actual
pcbddc->coarse_phi_B concatenated with pcbddc->coarse_phi_D
(pcis->n=pcis->n_B+pcis->n_D)

PCISAssembleLocalCoarseMat will assemble the sequential matrix representing
subdomains' contribution to the global coarse matrix (_NN and _BDDC cases
can be easily written using already existing codes)

PCISAssembleCoarseMat(pc,IS partition) would then decide how to finally
assemble the coarse matrix depending on the partition passed in (and
possibly change the row mapping of the default prolongation operators).

Does this logic fits what you have in mind?

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

> On Fri, May 11, 2012 at 6:11 PM, Stefano Zampini <
> stefano.zampini at gmail.com> wrote:
>
>> Isn't PtAP still the right operation, you just have a particular
>>> implementation that takes advantage of structure?
>>>
>>
>> yes it is, but since it is an expensive operations (P is dense), in BDDC,
>> once you solved the local problems to create P, you have almost straigthly
>> (and at a very low cost) the columns of the coarse matrix. The latter can
>> be obtained (as it is implemented in the code) as C^T\Lambda where C is the
>> local sparse  matrix of constraints, and \Lambda is a dense and small
>> matrix of lagrange multipliers.
>>
>>> I know you can also assemble B A^{-1} B^T, which is the same thing, and
>>> maybe we should provide a generic op for that.
>>>
>> What is B? the jump operator?
>>
>
> Your C above.
>
> I have other algorithms in mind where the the interpolants would be
> constructed somewhat differently. I may need to think a bit about what the
> right common operation is for that case. I just feel like we may be getting
> too tightly dependent on the specific BDDC algorithm (which has exponential
> condition number growth in the number of levels), which we probably want to
> generalize in the future.
>



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


More information about the petsc-dev mailing list