GCS: Increase documentation of diagnose() routine

This commit is contained in:
Abdullah Tahiri
2020-12-13 06:46:09 +01:00
committed by abdullahtahiriyo
parent ad549d49e1
commit d9bca3e8c1

View File

@@ -25,12 +25,12 @@
#pragma warning(disable : 4996)
#endif
//#define _GCS_DEBUG
//#define _GCS_DEBUG_SOLVER_JACOBIAN_QR_DECOMPOSITION_TRIANGULAR_MATRIX
//#define _DEBUG_TO_FILE // Many matrices surpass the report view string size.
#undef _GCS_DEBUG
#undef _GCS_DEBUG_SOLVER_JACOBIAN_QR_DECOMPOSITION_TRIANGULAR_MATRIX
#undef _DEBUG_TO_FILE
#define _GCS_DEBUG
#define _GCS_DEBUG_SOLVER_JACOBIAN_QR_DECOMPOSITION_TRIANGULAR_MATRIX
#define _DEBUG_TO_FILE // Many matrices surpass the report view string size.
//#undef _GCS_DEBUG
//#undef _GCS_DEBUG_SOLVER_JACOBIAN_QR_DECOMPOSITION_TRIANGULAR_MATRIX
//#undef _DEBUG_TO_FILE
// This has to be included BEFORE any EIGEN include
// This format is Sage compatible, so you can just copy/paste the matrix into Sage
@@ -3880,6 +3880,36 @@ SolverReportingManager::Manager().LogToFile("GCS::System::diagnose()\n");
makeReducedJacobian(J, jacobianconstraintmap, pdiagnoselist, tagmultiplicity);
// There is a legacy decision to use QR decomposition. I (abdullah) do not know all the
// consideration taken in that decisions. I see that:
// - QR decomposition is able to provide information about the rank and redundant/conflicting constraints
// - The QR decomposition of J and the QR decomposition of the transpose of J are unrelated (for reasons see below):
https://mathoverflow.net/questions/338729/translate-between-qr-decomposition-of-a-and-a-transpose
// - QR is cheaper than a SVD decomposition
// - QR is more expensive than a rank revealing LU factorization
// - QR is less stable than SVD with respect to rank
// - It is unclear whether it is possible to obtain information about redundancy with SVD and LU
// Given this legacy decision, the following is observed:
// - A = QR decomposition can be used for the diagonise of dependency of the "columns" of A. the
// reason is that matrix R is upper triangular with columns of A showing the dependencies.
// - The same does not apply to the "rows".
// - For this reason, to enable a full diagnose of constraints, a QR decomposition must be done on
// the transpose of the Jacobian matrix (J), this is JT.
// Eigen capabilities:
// - If Eigen full pivoting QR decomposition is used, it is possible to track the rows of JT during
// the decomposition. This can be leveraged to identify a set of independent rows of JT (geometry)
// that form a rank N basis. However, because the R matrix is of the JT decomposition and not the J
// decomposition, it is not possible to reduce the system to identify exactly which rows are dependent.
// - The effect is that it provides a set of parameters of geometry that are not constraint, but it does not
// identify ALL geometries that are not fixed.
// - If SpareQR is used, then it is not possible to track the rows of JT during decomposition. I do not know
// if it is still possible to obtain geometry information at all from SparseQR. After several years these
// questions remain open:
// https://stackoverflow.com/questions/49009771/getting-rows-transpositions-with-sparse-qr
// https://forum.kde.org/viewtopic.php?f=74&t=151239
// QR decomposition method selection: SparseQR vs DenseQR
#ifdef EIGEN_SPARSEQR_COMPATIBLE