2012/6/11 Jed Brown <[email protected]>

The problem is that you can't factor the subdomain problem directly because it is singular. So you either copy it into a bigger matrix (with Lagrange multipliers) or extract a submatrix (by dropping vertices).

In my experience, a singular subdomain matrix does not constitute a real problem if you use 0 as tolerance for zero pivots to avoid PETSc errors (zero pivot detection) at runtime ( I always use UMFPACK or SuperLU solvers; even the PETSc solver do the right job). For FETI and NN, if you design a coarse space in the right way, you can always solve for the local problems (at least for the problems I faced). The solution will have a nonzero component on the kernel of the local matrix, but this will be uneffective for the convergence of the global problem. If I assemble a matrix with selected vertices, I can factor it and solve

the constrained problems without needing to refactor.

The case with no selected vertices could be a special case, and worked with exactly like MatIS is now.

thus the Mat should have a public flag indicating Assembly or not at preselected vertices during MatAssembly?

On Jun 11, 2012 8:35 AM, "Stefano Zampini" <[email protected]> wrote:

...

I missed your answer...my e-mail client hid your last email.

...

...

Do you mean assembling the matrix on preselected vertices during MatAssemblyBegin/End? Note that this will imply that standard Neumann-Neumann methods will not work (they need the unassembled matrix to solve for the local Schur complements).

I'm not too concerned about that since I consider the classic N-N and original FETI methods to be rather special-purpose compared to the newer generation. I would like to limit the number of copies of a matrix to control peak memory usage.

Duplicate vertices don't concur so much to memory usage as faces and edge nodes do, so why limit your matrix class? In principle the new class should handle _every_ nonoverlapping method, either belonging to the old or the new generation.

-- Stefano

-- Stefano