From: Roy Stogner <roystgnr@ic...>  20080213 02:04:05

On Tue, 12 Feb 2008, Yujie wrote: > Now, I am wondering how algebraic method constrains hanging nodes. By default, the matrix line corresponding to each hanging node is the constraint equation which sets its value. This constrains each hanging node to whatever precision your linear solver gives; the hanging node degree of freedom coefficient is then not zero, it's whatever value is correct for the degree of freedom equation on the fine elements. > Whether does it set the values at hanging nodes to zero? With nondefault options set, the matrix line for each hanging node is (like the matrix column) just a "1" on the diagonal, with a corresponding 0 on the residual vector, so that the node coefficient is zero immediately after the linear solve. In this case, user code (or higher level library code like NewtonSolver::solve()) must then use the constraint equations to set the hanging node coefficients to their correct values. > I output the matrix assembled in libmesh using PetSC function, I > find lots of zero values in matrix. Because the matrix in Petsc is > stored using sparse compressed strage format, zero values should not > appear. That is incorrect. The sparsity pattern we tell PETSc to use comes from the connectivity of your mesh, which is much more efficient than building it on the fly as you assemble the matrix with your particular equation. Some multivariable equations (NavierStokes, in particular) and/or some choices of basis functions can then leave you with zero entries. If your equation is of the former type you can use DofObject::_dof_coupling to tell libMesh not to bother allocating matrix entries that you know will always be zero. However, it's also possible that we're allocating too many entries in the sparsity pattern. Can you come up with a specific example of two DoFs that you know shouldn't be coupled?  Roy 