Add a comment following a suggestion by Daniel Gerecht (thanks!).

git-svn-id: https://svn.dealii.org/trunk@25554 0785d39b-7218-0410-832d-ea1e28bc413d

diff --git a/deal.II/doc/doxygen/headers/constraints.h b/deal.II/doc/doxygen/headers/constraints.h
index 1a96c8519d444f286d72e1c439e0c825d4bf54d7..3e2940097894afa67330b0e7d2213cfd88804e94 100644 (file)
--- a/deal.II/doc/doxygen/headers/constraints.h
+++ b/deal.II/doc/doxygen/headers/constraints.h
@@ -100,13 +100,23 @@
  * This scheme of first building a linear system and then eliminating
  * constrained degrees of freedom is inefficient, and a bottleneck if there
  * are many constraints and matrices are full, i.e. especially for 3d and/or
- * higher order or hp finite elements. We therefore offer a second way of
+ * higher order or hp finite elements. Furthermore, it is impossible to
+ * implement for %parallel computations where a process may not have access
+ * to elements of the matrix. We therefore offer a second way of
  * building linear systems, using the
  * ConstraintMatrix::add_entries_local_to_global() and
  * ConstraintMatrix::distribute_local_to_global() functions discussed
  * below. The resulting linear systems are equivalent to those one gets after
  * calling the ConstraintMatrix::condense() functions.
  *
+ * @note While these two ways are <i>equivalent</i>, i.e., the solution of
+ * linear systems computed via either approach is the same, the linear
+ * systems themselves do not necessarily have the same matrix and right
+ * hand side vector entries. Specifically, the matrix diagonal and right hand
+ * side entries corresponding to constrained degrees of freedom may be different
+ * as a result of the way in which we compute them; they are, however, always
+ * chosen in such a way that the solution to the linear system is the same.
+ *
  *
  * <h4>Condensing matrices and sparsity patterns</h4>
  *