Hi Jed,
I think you are doing hard work for the next release but, have you already
take a look to my last email in the discussion?
2012/5/12 Stefano Zampini <stefano.zampini at gmail.com>
> 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
>
--
Stefano
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120520/222723ce/attachment.html>
