[petsc-dev] [SPAM] Re: [petsc-users] user experience with PCNN

[Jed Brown]

On Sun, Oct 9, 2011 at 15:50, Jakub Sistek <sistek at math.cas.cz> wrote:

>  Well, let me share my experience here. Mathematically, they are just a
> different language. But not from the point of view of implementation. In
> this respect, I like work of C. Dohrmann (2003, 2007), which is in my eye
> more implementation aware. I have already tried to implement three ways to
> solve these saddle point problems, changing of basis among them (A). The
> other two were splitting the constraints into (i) and (ii), enforcing group
> (i) by changing the system as Dirichlet boundary conditions and group (ii)
> by Lagrange multipliers (B), and solving the saddle point system as such by
> a direct method with suitable pivoting (C). Let me summarize (up to my
> understanding to the approaches) my current (and very personal) feeling of
> (A), (B) and (C):
>
> (A)
> (+) allows implementation of the preconditioner by solving system with a
> large (assembled in subdomains and at coarse dofs) distributed matrix
> (-) changing of basis produces a lot of fill into the matrix, which becomes
> very expensive especially for faces among subdomains, making direct solves
> after the change a lot more expensive
> (-) does not provide explicit coarse problem, which is the basis for
> multilevel method
> (-) not simple to generalize for arbitrary weighted averages on edges/faces
> (this may be my limited understanding)
>
> (B)
> (+) averages on faces do not present a problem
> (+) allows using variety of solvers for the block K (inexact, iterative,
> ...)
> (-) requires two solves of the problem with K in each application of
> preconditioner (one in constructing the RHS for Lagrange multipliers
> problem, another one for actual solve with corrected RHS)
> (-) requires enough point constraints to regularize K for direct solvers
>
> (C)
> (+) averages on faces do not present a problem
> (+) simplicity of implementation - no distinction between group (i) and
> (ii) needed
> (-) quite restrictive for subdomain solvers, which need to be robust for
> saddle-point type of systems
>
> Since inexact solvers seem to me now quite important, I would be inclined
> to try (B) next time I would implement this task. This is in my opinion
> pretty much the approach of Dohrmann (2007) in "An approximate BDDC
> preconditioner".
>

This sounds sensible. My concern is that iterative solvers for saddle point
problems are much more delicate.

>
>  NullSpace is specifically for singular operators (e.g. the global problem
> is floating). NearNullSpace is just describing the low-energy modes (which
> need to be suitably represented in the coarse space to have a scalable
> method).
>
> Thank you for explanation. These would probably correspond to subdomain
> coarse basis functions, which are computed in BDDC by these saddle point
> problems rather than from an exact knowledge. The coarse space here contains
> all the nullspaces of subdomains and typically is much larger than exact
> nullspace of subdomain matrices (e.g. for elasticity in 3D with cubic
> subdomains considering arithmetic averages on faces and edges, each
> subdomain has 26*3 = 78 coarse basis functions compared to dimension 6 of
> exact nullspace.
>

Well yes, but remember that faces are shared two ways and edges and vertices
are shared many ways. This contributes to an average of much less than 78
dofs per coarse space. So you need many subdomain solves, but the coarse
problem need not be much bigger.


> OK. As I have mentioned, I think that jumps inside domains are naturally
> taken care for by subdomain solves, so very well for exact solvers. Jumps
> aligned by interfaces (for example coefficients constant for subdomains) are
> handled well by stiffness scaled averaging operator. The remaining group
> present troubles. We have created a small test problem (100k dofs) in a
> recent paper (http://dx.doi.org/10.1016/j.matcom.2011.03.014) for
> elasticity computation, where much stiffer 'rods' embedded in softer
> material were punching through faces of subdomains. There, the contrast in
> coefficients was only 10^5 and the resulting estimated condition number even
> after preconditioning ~2x10^4 when using arithmetic averages on faces. I
> know it is not a complete test of the phenomena, but one can conclude that
> the standard type of coarse problem does not suffice here. I can remember
> that by playing with the difference in coefficients, we were essentially
> able to make the solver stagnate. Hopefully, I should look into it again in
> a month or so, so I can keep you updated of a bit more systematic tests.
> Papers by Pechstein and Scheichl (2009 a,b) contain systematic tests
> already.
>

Thanks for the references. For a few problems that I run into, aligning
subdomains is just not practical.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111014/7fb604b8/attachment.html>