[petsc-dev] API changes in MatIS

[Stefano Zampini]

2012/6/11 Jed Brown <jedbrown at mcs.anl.gov>

> 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" <stefano.zampini at gmail.com>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120611/eab6a51c/attachment.html>