From: heister Date: Mon, 25 Feb 2013 23:16:29 +0000 (+0000) Subject: update glossary again X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=fb2194d5cc1d52a6ce19222e30151e14c7498e8e;p=dealii-svn.git update glossary again git-svn-id: https://svn.dealii.org/trunk@28562 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/doc/doxygen/headers/glossary.h b/deal.II/doc/doxygen/headers/glossary.h index fabe557680..2b1c70e65f 100644 --- a/deal.II/doc/doxygen/headers/glossary.h +++ b/deal.II/doc/doxygen/headers/glossary.h @@ -532,46 +532,25 @@ * functions are collective, i.e. they need to be called by all * processors. * - * There is one snag, however: both PETSc and Trilinos need to know - * whether the operation that these compress() functions - * invoke applies to adding elements or setting them. Usually, you - * will have written or added elements to the vector or matrix before - * (and after compress() was last called), and in this - * case the wrapper object knows that the global communication - * operation is either an add or a set operation since it keeps track - * of this sort of thing. However, there are cases where this isn't - * so: for example, if you are working on a coarse grid and there are - * more processors than coarse grid cells; in that case, some - * processors will not assemble anything, and when they come to the - * point where they call compress() on the system matrix - * and right hand side, these objects are still in their pristine - * state. In a case like this the wrapper object doesn't know whether - * it is supposed to do a global exchange for add or set operations, - * and in the worst case you end up with a deadlock (because those - * processors that did assembly operations want to communicate, while - * those that didn't assemble anything do not want to communicate). - * - * The way out of a situation like this is to use one of the two following - * ways: - * - * - You tell the object that you want to compress what operation is - * intended. This can be done using the VectorOperation argument in - * the various compress() functions. - * - You do a fake addition or set operation on the object in question. For - * example, you can add a zero to an element of the matrix or vector, - * which has no effect other than telling the object that the next - * compress operation should be in Add mode. - * - * Some of the objects are also indifferent and can figure out what to - * do without being told. The TrilinosWrappers::SparseMatrix can do that, - * for example. - * - * In short, you need to call compress() in the following cases (and - * only in those cases, though calling compress() in other cases - * just costs some performance): + * There is one snag, however: both PETSc and Trilinos need to know whether + * the operation that these compress() functions invoke applies + * to adding elements or setting them. In some cases, not all processors may + * be adding elements, for example if a processor does not own any cells when + * using a very coarse (initial) mesh. For this reason, compress() takes an + * argument of type VectorOperation, which can be either ::add, or ::insert. + * This argument is required for vectors and matrices starting with the 7.3 + * release. + * + * In olde releases we also proposed fake add/set operations. Those were the + * cause of many bugs and deadlocks, so the usage of VectorOperation is now + * required. + * + * In short, you need to call compress() in the following cases (and only in + * those cases, though calling compress() in other cases just costs some + * performance): * * 1. At the end of your assembly loop on matrices and vectors. This needs to - * be done if you write entries directly and if you use + * be done if you write entries directly or if you use * ConstraintMatrix::distribute_local_to_global. Use VectorOperation::add. * * 2. When you are done setting individual elements in a matrix/vector before @@ -581,8 +560,9 @@ * 3. Like in 2., but for adding values to individual elements. Use * VectorOperation::add. * - * All other operations like scaling or adding vectors, assignments, or solvers - * do not require calls to compress(). + * All other operations like scaling or adding vectors, assignments, calls + * into deal.II (VectorTools, ConstraintMatrix, ...) or solvers do not require + * calls to compress(). * * *