Kiểm tra và trực quan hóa các mảng chỉ số lớn

Tôi sẽ sớm triển khai phương pháp Galerkin không liên tục và đã thực hiện điều này trước khi tôi biết các mảng lập chỉ mục cơ bản mà tôi sẽ cần tính toán, đưa ra một dữ liệu lưới và đa thức.

Vấn đề tôi gặp phải trong mã trước đó là những sai lầm tinh vi mà tôi đã mắc phải trong việc tính toán những thứ như lập chỉ mục theo dõi bên trong / bên ngoài. Các vấn đề không phát sinh đối với các trường hợp thử nghiệm đơn giản hơn sẽ phát sinh trên các lưới lớn hơn và thường điều này mang lại một sơ đồ không ổn định do các điều kiện biên không được áp đặt đúng cách (vì vậy không có cơ hội chỉ xem mô phỏng cứ sau 10 bước hoặc nhìn thấy vấn đề cục bộ) .

Tôi hy vọng một số người có kinh nghiệm hơn ở đây biết các bài kiểm tra tốt để chạy trên các mảng chỉ số để có được sự tin tưởng rằng họ đúng. Quadratures, dẫn xuất và tương tự là rất dễ dàng để kiểm tra, nhưng những thứ khác tôi không thể tìm ra.

Một số thử nghiệm tôi đã thực hiện trong quá khứ là thêm các quy tắc nội thất vào các quy tắc bên ngoài, sẽ mang lại 0 hoặc + -2. Có thể nhanh chóng thấy kết quả của một số thay đổi mã là hữu ích, nhưng tôi không thể nghĩ ra một cách có ý nghĩa để làm điều này với lập chỉ mục.

Tôi cũng nên đề cập rằng những thứ này sẽ được sử dụng cho các hình tứ giác và hình lục giác, với tiềm năng cho các yếu tố đường cong. Không có nhiều mã hiện có để so sánh với một thư viện đang hoạt động.

Điểm thưởng nếu có bài kiểm tra đơn vị tốt mà tôi có thể viết mà sẽ không dựa vào câu trả lời đúng hiện có để so sánh với. Tôi sẽ giải quyết cho rất nhiều heuristic tốt.

Câu trả lời rõ ràng tất nhiên sẽ là không tự mình thực hiện nó mà sử dụng những gì người khác đã làm trước đây. Ví dụ: deal.II (http://www.dealii.org - từ chối trách nhiệm: Tôi là một trong những tác giả của thư viện này) đã có các phần tử DG trên các hình tứ giác, hình lục giác và các phần tử cong, các chương trình hướng dẫn cho biết cách sử dụng chúng, v.v ... Tất cả điều này đã được kiểm tra trong một thập kỷ và được kiểm tra thông qua 2.700 bài kiểm tra hồi quy sau mỗi thay đổi đối với kho lưu trữ. Có rất nhiều công việc để được lưu cho bạn.

Nhưng để trở lại câu hỏi ban đầu: Những gì tôi thường làm cho những việc này khi viết các trường hợp thử nghiệm cho thỏa thuận .II là làm một cái gì đó mà tôi biết giải pháp chính xác và xác minh rằng tôi thực sự có được nó. Ví dụ: Nếu bạn có phần tử nội suy (nút), thì trên một ô , gán cho mọi mức độ tự do giá trị của hàm tại các nút . Làm điều này bằng tay , sử dụng kiến ​​thức của bạn về mức độ tự do được sắp xếp. Điều này mang lại một hàm trong đó . Sau đó, sử dụng công thức bậc hai để tính toán một cái gì đó như . Nếu$K$$f(x)$$x_i$$u_h(x)=\sum_i U_i \varphi_i(x)$$U_i=f(x_i)$$\|u_h-f\|^2 = \int_K |u_h(x)-f(x)|^2 \; dx$$f$là một đa thức có cùng thứ tự với không gian ansatz của bạn, thì kết quả sẽ bằng không. Nếu bạn trộn lẫn các chỉ số, khi gán giá trị cho mức độ tự do bằng tay hoặc trong chương trình của bạn khi đánh giá tại các điểm cầu phương, bạn sẽ nhận được thứ gì đó khác không.$u_h$

Điểm chính của tất cả những điều này là trong thử nghiệm của bạn, bạn sử dụng hai phương pháp độc lập để xử lý lập chỉ mục (kiến thức của bạn, khi gán giá trị cho DoF bằng tay và mã của bạn nghĩ gì là chính xác khi đánh giá ) và chúng cần phải đồng ý. Nếu họ không, ít nhất một trong số họ là không chính xác.$u_h$

Tất nhiên, một khi bạn có hoạt động này, bạn cần lưu testcase và chạy định kỳ để đảm bảo rằng bạn không vô tình phá vỡ loại chức năng này một lần nữa.