[Libmesh-devel] As long as we're futzing with Numeric*

[Roy S. <roy...@ic...>]

I hope nobody minds if I risk breaking them.


I'm committing a bugfix to svn (PetscMatrix::operator() leaks when
called on entries outside of the sparsity pattern), but I've made some
other changes:

I've added parallel_only() (and semiparallel_only(), which acts like
parallel_only() on distributed sparse matrices but not on serial ones)
assertion calls to those operations which (I believe) need to be
called on every processor at once for a non-Seq matrix.  In other
words:

close()
add(T,SparseMatrix&)
init (when called with differing global and local sizes)
zero()
clear()  (when MatDestroy is needed)
l1_norm()
linfty_norm()
print_matlab()

close() was what prompted the additions; I was (via operator())
calling it from only one processor at a time, which can break your
code in interesting ways and which is the sort of thing that
parallel_only() was intended to help debug.  But if I've
misinterpreted the PETSc docs about which functions can be safely
called from only one processor, some of those assertions are going to
be overzealous.


My other potentially code-breaking change: making operator()
semiparallel-only doesn't make sense, so instead of calling close() it
now asserts that the mesh is already closed.  That's probably fine -
nobody uses operator() in a non-debugging sense anyway.  But I spotted
the same helpful "we'll close it for you" code in add(T,SparseMatrix&)
and replaced that with an assert too.  I figure either the user has
already closed the matrix (in which case we're just wasting
communication time reaffirming that) or they can add their own close()
call.  But that could break existing code, so someone tell me if I've
gone too far and I'll revert the change.
---
Roy