Ifpack2: LocalSparseTriangularSolver should use ZERO CombineMode on Import

[mhoemmen]

@trilinos/ifpack2

Suppose that users give LocalSparseTriangularSolver a matrix with a nontrivial Import object. What is the correct interpretation of "local sparse triangular solve" in that case?

Compare to ILU(k). If users give a matrix with a nontrivial Import to ILU(k), what they generally expect is domain decomposition with no overlap across MPI processes, and ILU(k) within each MPI process, as a subdomain solver.

This implies doing an Import with the ZERO CombineMode to take care of any local permutations from the domain Map to the column Map. Off-process entries should be zeroed out. The only reason LocalSparseTriangularSolve needs to do the Import, is to take care of any local permutations that may exist.

If the domain Map is fitted to the column Map on a process, it could avoid the copy by making its column Map (multi)vector just an alias of its domain Map (multi)vector on that process. Import of a MultiVector knows not to copy if the pointers are the same.

This may be part of #558. @ambrad pointed out that LocalSparseTriangularSolver does an Import (and is doing a nontrivial Import! suggesting that Ifpack2::AdditiveSchwarz is behaving badly), but CrsMatrix::localSolve does not (it assumes a post-Imported input (multi)vector).

[mhoemmen]

This is, in fact, how Ifpack2::LocalFilter::apply should behave.