APPCRASH auf Lauf UmfPackLU <> mit Eigen-Bibliothek

Question

ich kompilieren und zu versuchen, die UMfPackLU<SparseMatrix<>> Routine aus Eigen 3.2.9 und UMFPACK v4.5 Bibliotheken mit TDM-GCC 5.1.0 auf Win64-Plattform zu laufen. Aber ich bekomme Appcrash mit exception code c0000005.

Was ich brauche, zu implementieren, ist die folgende:

 _ _  _ _ 
A = | P |, B = | R |, where P and Q are sparse and Z is 0 with 3 cols 
    | Q |  | Z | 
    |_ _|  |_ _| 

X = A\B; 

Was ich tue (Auszug nur) ist folgende:

#define num_t double 
... 
SparseMatrix<num_t,RowMajor> A(P.rows()+Q.rows(), P.cols()); 
A.topRows(P.rows()) = P; 
A.bottomRows(Q.rows()) = Q; 
Matrix<num_t, Dynamic, 3> B(P.rows()+Q.rows(), 3); 
B.topLeftCorner(P.rows(), 3) = R; 
B.bottomLeftCorner(Q.rows(), 3) = S; 

UmfPackLU<SparseMatrix<num_t>> solver(A.transpose()*A); 
auto AtB = A.transpose()*B; 
X.col(0) = solver.solve(AtB.col(0)); // @@@ segmentation error here @@@ 
X.col(1) = solver.solve(AtB.col(1)); 
X.col(2) = solver.solve(AtB.col(2)); 

Notiere die SparseMatrix<> in RowMajor Format ist.

Beim Debuggen mit gdb: Ich bekomme Program received signal SIGSEGV, Segmentation fault. an der Zeile wie oben markiert.

Statt UmfPackLU<SparseMatrix<>>, die Lösung mit SimplicialLLT<SparseMatrix<>>, SimplicialLDLT<SparseMatrix<>> oder CholmodDecomposition<SparseMatrix<>> ordnungsgemäß funktioniert.

Vielen Dank im Voraus für jede Hilfe.

Answer 1

Bitte zögern Sie nicht zu korrigieren/verbessern/etablieren Sie meine Antwort.

Was ich gefunden habe ist, dass ich brauche AtA eine explizite ColMajor Matrix instanziiert, bevor sie an den Solver Fütterung (RowMajor funktioniert nicht) wie folgt:

SparseMatrix<num_t, ColMajor> AtA = A.transpose()*A; 
UmfPackLU<SparseMatrix<num_t>> solver(AtA); 

Ist dies eine Anforderung aufgrund Eigenlazy evaluation Implementierung für den Aufruf einer external routine?

Answer 2

Dies ist ein Fehler in Eigen 3.2.9, der vor einiger Zeit im 3.3-Zweig behoben wurde. Es ist nun auch im 3.2-Zweig behoben (changeset 1e7d97fea51d).

können Sie das Problem umgehen, indem compute(...) anstelle des Konstruktors:

UmfPackLU<SparseMatrix<num_t>> solver; 
solver.compute(A.transpose()*A);