Barry Smith <[email protected]> writes: > Forwarding this to people who might have a clue. > > On Sep 17, 2013, at 5:09 PM, Jungho Lee <[email protected]> wrote: > >> I'm looking into the 6*6 grid case, with dof=3, so the system matrix size is >> 108*108. >> >> 1) It turns out that using >> >> -pc_type gamg -pc_gamg_type agg >> >> results in two levels with the coarse problem being 13*13. Wouldn't >> it be natural for the coarse problem to be of size that's an integer >> multiple of 3, though? It turned out that KSP->mat->rmap->bs = 1 for >> the finest level matrix, so I added >> >> MatSetBlockSize(user.M,3) >> >> in the main code, but it seems like this information somehow gets >> lost by the time lower-level functions (such as graph, coarsen, >> createlevel...) in gamg.c, agg.c, tools.c, etc., are called.
That code should have aggregated first and worked with the block graph. Is your preconditioning matrix different from the operator? Where is the code to reproduce the behavior you see? >> 2) For the specific set of parameters I'm using for testing purposes, >> the smallest nonzero entry of the finest level matrix is of order >> e-7. For the coarse level matrix (size 13*13), whose entries are >> determined by MatPtAP called in createlevel (in gamg.c), the smallest >> nonzero entry is of order e-24 - this jumped out at me as a potential >> sign of something wrong. What does -mg_coarse_pc_type svd -mg_coarse_pc_svd_monitor tell you about the condition number of the coarse operator? Send -ksp_view.
pgpS9hmLh2j1d.pgp
Description: PGP signature
