\section{Limitations and Future Plans}
\label{sec:plans}

The user should be aware of a few limitations in \BS:
\begin{itemize}
\begin{item}
Each row of the matrix must have a diagonal entry.  That entry may
be zero, but it must be explicitly represented in the matrix
structure.
\end{item}

\begin{item}
If the matrix is indefinite, one cannot solve for a block of 
vectors simultaneously in the current code.
\end{item}

\begin{item}
\BS\ does not check for or catch exceptions associated with
floating-point errors.
\end{item}

\begin{item}
Each processor involved in a BlockSolve call 
must have at least one row of the matrix.
\end{item}

\begin{item}
\BS\ does not allow the user to mix machines with different
byte orderings or different sizes for datatypes in the same
computation.\sindex{different byte orderings}
\end{item}
\end{itemize}

Another limitation involves coloring options.
It is possible with the current version that if the portion of
the matrix structure contained on some processors is very different
from the structure contained on other processors, then the number
of colors on each of these processors can be quite different.
Such a situation could arise if different-order finite elements are
used on different processors (but would not arise just by applying
boundary conditions to some processors, but not to others).  This
imbalance in the number of processors could degrade performance.
A balanced coloring heuristic that addresses this situation is described
in \cite{gjp:balanced}; however, this heuristic is not yet included
in \BS.
\sindex{balanced colorings}

\newpage
