* Constraints typically come from several sources, for example:
* - If you have Dirichlet-type boundary conditions, $u|_{\partial\Omega}=g$,
* one usually enforces
- * them by requiring that that degrees of freedom on the boundary have
+ * them by requiring that degrees of freedom on the boundary have
* particular values, for example $x_{12}=42$ if the boundary condition
* $g(\mathbf x)$ requires that the finite element solution $u(\mathbf x)$
* at the location of degree
* below. The resulting linear systems are equivalent to those one gets after
* calling the ConstraintMatrix::condense() functions.
*
+ * @note Both ways of applying constraints set the value of the matrix
+ * diagonals to constrained entries to a <i>positive</i> entry of the same
+ * magnitude as the other entries in the matrix. As a consequence, you need to
+ * set up your problem such that the weak form describing the main matrix
+ * contribution is not <i>negative definite</i>. Otherwise, iterative solvers
+ * such as CG will break down or be considerably slower as GMRES.
+ *
* @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
* 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>
*
* As mentioned above, the first way of using constraints is to build linear