Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Possible upper/lower triangle storage inconsistency in rates() in multi-phase equilibrium solver

Đang mở
  • Có gì không ổn?
#331 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
Nửa ngày
Mức phù hợp với người mới
50/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
cpp
Lĩnh vực
backend

Hướng nghiên cứu

The suspect code is in rates() in src/thermo/MultiPhaseEquilSolver.cpp: the loop assembling A(m,p) only fills the lower triangle, and the solve near line 1136 uses selfadjointView<Upper>(). Read the assembly loop and that solve to confirm whether the upper triangle is filled elsewhere before the solve. Done means either switching to selfadjointView<Lower>() or populating the upper triangle, with a maintainer confirming which one is intended and the solver results checked against a known equilibrium case.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

I believe there may be an inconsistency in the rates() routine between the way the matrix A is assembled and the triangular part subsequently used by Eigen's self-adjoint solver.

A is populated with:

for (int p = 0; p < npr; ++p) {
    for (int m = p; m < npr; ++m) {
        for (int j = p_sizes[m]; j < p_sizes[m+1]; ++j) {
            sum = 0.0;
            for (int i = 0; i < ncr; ++i)
                sum += H(j,i)*dlamy(i,p);
            A(m,p) += y[j]*sum;
        }
    }
}

Since m >= p, this explicitly computes the lower triangular part of A, i.e. A(m,p) for m >= p. This appears intentional, since A is expected to be symmetric.

However, the resulting system is then solved with
https://github.com/mutationpp/Mutationpp/blob/7607ef4d67f4de115705f78f467b1ea48bf02c26/src/thermo/MultiPhaseEquilSolver.cpp#L1136

As I understand Eigen's SelfAdjointView, selfadjointView<Upper>() treats the upper triangular portion of the matrix as the stored representation of the self-adjoint matrix and does not use the corresponding entries in the lower triangle. I believe this is therefore causing the off-diagonal elements to be discarded in the calculation of dx.

In other words, since the assembly produces

[ a  0  0
  b  c  0
  d  e  f ]

the intended symmetric matrix is presumably

[ a  b  d
  b  c  e
  d  e  f ]

However, since the upper-triangular off-diagonal elements remain zero, selfadjointView<Upper>() represents the matrix as

[ a  0  0
  0  c  0
  0  0  f ]

instead.

Should selfadjointView<Lower>() be used here instead? Alternatively, is there some reason the upper triangle is expected to be populated elsewhere before this solve?

Ngôn ngữ chính
C++
Star
145
Fork
79
Merge trung bình
1 ngày 15 giờ
Pull request đã merge (30 ngày)
2

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của mutationpp/Mutationpp

Tất cả issue của mutationpp/Mutationpp

Issue tương tự

Thêm issue về C++

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.