Hai chương trình mô hình khác nhau có thể được sử dụng để xác nhận kết quả của nhau không?


8

Mô hình máy tính

Mô hình máy tính được sử dụng trong các lĩnh vực kỹ thuật khác nhau. Tôi đặc biệt xem xét phân tích cấu trúc hoặc phân tích phần tử hữu hạn (FEA). Đôi khi các mô hình được sử dụng để tăng tốc các tính toán lặp đi lặp lại có thể được thực hiện bằng tay. Đôi khi các mô hình được sử dụng để thực hiện các phép tính không dễ dàng hoặc thậm chí có thể thực hiện bằng tay.

Kiểm tra

Có một vài phương pháp tiêu chuẩn để kiểm tra kết quả của các mô hình máy tính.

  • Chạy các mô hình xác minh và xác nhận rằng kết quả khớp với câu trả lời được tính toán trước đó.
  • Chạy các mô hình đơn giản có thể được kiểm tra bằng tính toán tay.
  • Thử nghiệm mô hình vật lý.

Vấn đề với hai phương pháp kiểm tra đầu tiên ở trên là chúng chỉ kiểm tra các tình huống cụ thể hoặc chúng chỉ kiểm tra các phần đơn giản của chương trình.

Phương pháp mô hình vật lý có thể tốn kém cho các mô hình kích thước đầy đủ và các mô hình tỷ lệ có thể không phải lúc nào cũng cho kết quả giống như kích thước đầy đủ.

Điều này để lại một khoảng cách trong những kết quả có thể được kiểm tra. Đối với bất kỳ mô hình phức tạp nào, không có cách nào dễ dàng để kiểm tra xem kết quả từ chương trình có chính xác không. Kỹ sư phải tin tưởng rằng phần mềm tạo ra kết quả chính xác từ mô hình.

Kiểm tra so sánh

Mô hình có thể được nhập vào hai chương trình khác nhau (được thực hiện bởi các công ty khác nhau). Giả định là nếu kết quả của hai mô hình là đủ tương tự nhau, thì kết quả phải chính xác cho mô hình được sử dụng. Điều này sẽ không bắt được bất kỳ lỗi nào trong việc tạo mô hình ban đầu, nhưng nó sẽ bắt lỗi trong quá trình thực hiện phần mềm.

  • Hai chương trình riêng biệt có thể được sử dụng để kiểm tra "tính chính xác" của kết quả từ mô hình không?
  • Việc sử dụng phương pháp so sánh một mô hình này trong hai chương trình riêng biệt có cung cấp cùng một mức độ đảm bảo trong kết quả như bất kỳ phương pháp kiểm tra nào khác không?
  • Điều gì có thể là những bất lợi của việc sử dụng thủ tục này?

"Tàu con thoi" đã đi vào quỹ đạo bằng 5 máy tính bay. 4 trong số này chạy cùng một chương trình đã kiểm tra kết quả của nhau, đồng ý giữa những người lành mạnh và bỏ phiếu cho bất kỳ thành viên điên rồ nào. Máy tính thứ 5 chạy một chương trình hoàn toàn khác được viết độc lập bởi một nhóm khác. "Chỉ trong trường hợp". Tôi không biết nếu nó cần thiết.
Russell McMahon

Cả hai chương trình máy tính có thể sai theo cùng một cách, vì vậy tôi sẽ nói không. Đây không phải là thực hành tốt. Tốt hơn là so sánh các giải pháp số với các trường hợp trong đó một giải pháp được biết đến, phân tích, thực nghiệm hoặc thông qua nghiên cứu được công bố.
Paul

@Paul Vâng, đó là cách mọi thứ thường được kiểm tra, nhưng điều đó chỉ cho thấy rằng chương trình hoạt động cho vấn đề đó . Bạn có thể đưa ra một giả định về việc liệu các cấu hình khác sử dụng cùng một đường dẫn mã cũng đúng hay không, nhưng sẽ luôn có trường hợp cạnh. Giả định bao gồm trong việc sử dụng hai chương trình riêng biệt là các lập trình viên có lỗi trong các trường hợp cạnh khác nhau .
hazzey

Câu trả lời:


7

Vâng, có được một ý kiến ​​thứ hai có thể hữu ích. Điều này được thực hiện thường xuyên trong dự báo thời tiết nơi các giải pháp chính xác chưa được biết, và có một số đánh giá về cách áp dụng các yếu tố khác nhau.

Sẽ có ít phòng ngọ nguậy hơn trong một cái gì đó giống như phân tích ứng suất lưới phần tử hữu hạn bởi vì các phương trình lặp để giải quyết nó về cơ bản sẽ giống nhau cho dù ai đã viết phần mềm. Vấn đề thực sự là không giải quyết được lưới nhiều như việc tạo ra một lưới đủ tốt ngay từ đầu.

Do đó, một cách để có được nhiều ý kiến ​​là thay đổi các tham số lưới. Hy vọng rằng bạn vẫn nhận được khá nhiều câu trả lời tương tự. Nếu bạn làm cho lưới gấp 2 lần và nhận được câu trả lời khác nhau đáng kể, thì đó là một đầu mối mạnh mẽ, lưới ban đầu không đủ chi tiết. Sau đó, bạn cũng không biết chắc chắn lưới tiếp theo đủ chi tiết mà không cần thực hiện chi tiết hơn nữa và nhận được cùng một câu trả lời.

Tất nhiên ngày nay thế hệ lưới tự nó có phần tự động và thích ứng. Đây không còn là về vật lý giải quyết lưới, mà bao gồm các phương pháp phỏng đoán về thời điểm và cách chia nhỏ. Phần mềm khác nhau có thể khác nhau về vấn đề này, do đó, việc chạy hai chương trình khác nhau với cùng một dữ liệu ban đầu có thể hữu ích.


6

Tôi viết điều này từ quan điểm của một kỹ sư phát triển phần mềm mô phỏng.

Tôi nghĩ rằng thực tế được mô tả là xấu và tôi khuyên bạn không nên sử dụng hai phần mềm khác nhau để "xác nhận" kết quả.

Nói chung, hai phần mềm mô hình hóa khác nhau không thể được sử dụng để xác nhận nhiều thứ khác ngoài sự giống nhau của chúng. Hai phần mềm có thể dễ dàng nhận được cả hai câu trả lời tương tự nhưng sai, đặc biệt nếu chúng sử dụng các mô hình tương tự nhau. Tôi có thể nghĩ về ít nhất một trường hợp trong đó đây là trường hợp chắc chắn, và Trevor Archibald đề cập đến một trường hợp khác. Tôi sẽ ấn tượng hơn bởi hai phần mềm sử dụng các kỹ thuật mô hình khác nhau có kết quả tương tự nhau.

Chủ đề này được gọi là xác minh và xác nhận các mô hình máy tính, và nó có một tài liệu khá rộng lớn. Tôi sẽ cung cấp một bản phác thảo của những điều cơ bản. Việc xác minh đang so sánh một mô hình với một giải pháp "chính xác" (có thể là tính toán tay hoặc một cái gì đó phức tạp hơn), nghĩa là kiểm tra toán học của phần mềm. Các giả định đằng sau giải pháp chính xác có thể sai, nhưng ít nhất bạn muốn chắc chắn rằng phần mềm có phần toán học đúng. Xác nhận là so sánh một mô hình chống lại một thử nghiệm. Điều này cho phép bạn kiểm tra xem mô hình bạn đang sử dụng có chính xác hay không, đây là điều mà xác minh không thể làm cho bạn.

Vấn đề với hai phương pháp kiểm tra đầu tiên ở trên là chúng chỉ kiểm tra các tình huống cụ thể hoặc chúng chỉ kiểm tra các phần đơn giản của chương trình.

Đây là một vấn đề thực sự phải đối mặt với các nhà phát triển phần mềm và người dùng. Có nhiều cách được thiết lập để xử lý nó tốt hơn nhiều so với việc so sánh hai phần mềm khác nhau.

Vấn đề là bạn không bao giờ có thể kiểm tra mọi trường hợp có thể. Phần mềm của bạn có thể vượt qua trường hợp A, nhưng trường hợp A không liên quan đến vật lý X, Y hoặc Z và điều đó khiến bạn hoàn toàn không có trường hợp B. Vì vậy, điều bạn muốn là một số lượng lớn các kiểm tra bao gồm ít nhất tất cả các tính năng cơ bản bạn muốn kiểm tra. Nhiều phần mềm có "bộ V & V" về cơ bản là chính xác.

Về mặt xác minh, có rất nhiều lựa chọn. Bạn có thể tạo ra các giải pháp chính xác mới cho các trường hợp khác nhau. Đôi khi điều này một mình là đủ. Tuy nhiên, như bạn đã nhận thấy, đôi khi những gì bạn có thể làm bằng tay chỉ giới hạn trong các trường hợp rất đơn giản. Đối với các trường hợp tổng quát hơn, bạn có thể sử dụng một kỹ thuật gọi là phương pháp của các giải pháp được sản xuất (Google nó). Điều này đòi hỏi lập trình và có thể trở nên lộn xộn, nhưng cho phép bạn kiểm tra cơ bản bất cứ điều gì bạn có thể nghĩ đến. (Nhân tiện, phần lộn xộn có thể được xử lý thông qua một thư viện như MASA .)

Ngoài ra, tôi muốn chỉ ra rằng trái với những gì Olin Lathrop gợi ý, với phương pháp giải pháp được sản xuất, bạn có thể tạo ra những gì, với mục đích thử nghiệm, giải pháp chính xác. Chúng không "chính xác" theo nghĩa chặt chẽ, bởi vì chúng không thỏa mãn chính xác các phương trình mà phần mềm đang giải quyết mà không sửa đổi. Nhưng chúng thỏa mãn các phương trình rất gần và sự khác biệt được tính toán để làm cho bài kiểm tra nghiêm ngặt. Kỹ thuật này hiện không phổ biến lắm, nhưng nó đã được sử dụng để kiểm tra những thứ mà trước đây được cho là khó kiểm tra.

Về mặt xác thực, bạn có thể tìm kiếm nhiều dữ liệu thử nghiệm hơn hoặc chạy thử nghiệm của riêng bạn.


4

Tôi nghĩ rằng đây là một thực hành tốt tổng thể.

Bằng cách sử dụng hai phần mềm khác nhau, bạn có thể tránh được hai loại lỗi: 1) lỗi xuất phát từ một phần mềm không chính xác (không nên bỏ qua), 2) lỗi xuất phát từ việc người dùng không có thói quen sử dụng phần mềm (tùy chọn ẩn, cài đặt mặc định ...).

Nếu các phần mềm đủ khác nhau, tỷ lệ nhận được hai lần kết quả sai giống nhau là thấp.

Tuy nhiên, các lỗi xuất phát từ lựa chọn mô hình xấu không thể tránh được theo cách này. Vì vậy, tôi muốn nói rằng nhược điểm chính là quá tin tưởng vào kết quả vì chúng đã được xác nhận bởi hai phần mềm.

Tôi nghĩ rằng tốt hơn là thành thạo một phần mềm, chạy tất cả các loại trường hợp kiểm tra (ví dụ so với kết quả học tập), hơn là sử dụng một số phần mềm và chỉ có kiến ​​thức trung bình. Hơn nữa, tôi nghĩ tốt nhất nên biết những điều cơ bản về phân tích FEM và chỉ sử dụng hai phần mềm "một lần nhấp để chạy" là một cách làm tồi vì người dùng có thể tái tạo lỗi mô hình hóa.

PS: Tôi đang viết như một người sử dụng phân tích FEM điện từ / nhiệt (không có tên miền nào khác).


2

Trả lời từ quan điểm của một kỹ sư thiết kế

Kiểm tra kết quả của một chương trình so với chương trình khác sẽ cho bạn một mức độ chắc chắn rằng kết quả là chính xác. Không chắc bạn có thể chắc chắn 100%, nhưng sau đó mức độ chắc chắn đó khó đạt được.

Một vấn đề lớn tôi thấy là có thể chuyển mô hình từ phần mềm này sang phần mềm khác. Mặc dù hầu hết các công ty phần mềm (vì BIM) đang cải thiện việc xuất / nhập mô hình, nhưng tôi không mong đợi tất cả các tính năng của một mô hình có thể xuất được. Hình học tương đối dễ dàng để nhập / xuất vì tệp trao đổi chỉ cần chứa tọa độ. Nhưng ví dụ: các bản phát hành cuối thành viên có thể được lưu trữ rất khác nhau bởi các phần mềm khác nhau, vì vậy trừ khi / cho đến khi một định dạng trao đổi tệp chung được đồng ý, tôi nghi ngờ sẽ cần rất nhiều nỗ lực để xây dựng lại hoàn toàn một mô hình trong chương trình phần mềm thứ hai.

Dựa trên kinh nghiệm của bản thân tôi, các lỗi trong kết quả có nhiều khả năng đến từ việc nhập dữ liệu không chính xác hoặc các giả định không chính xác so với các phần mềm được viết kém. Do đó, thời gian và nỗ lực trong việc sử dụng phần mềm độc lập để xác minh câu trả lời có lẽ không phải là cách sử dụng tốt thời gian của bạn.

Trả lời từ quan điểm của một kỹ sư phần mềm

Xác minh phần mềm so với phần mềm khác không được coi là phần mềm của bạn là chính xác. Tốt hơn hết là tìm dữ liệu / kết quả được công bố có thể được sử dụng để xác minh rằng phần mềm đưa ra câu trả lời chính xác. Hãy tưởng tượng một cuộc họp bán hàng nơi một công ty phần mềm đang cố gắng bán phần mềm của họ cho một công ty kỹ thuật:

Kỹ sư: Làm thế nào để chúng tôi biết rằng phần mềm của bạn là chính xác?

Nhân viên bán phần mềm: Chà, chúng tôi đã kiểm tra nó với phần mềm của đối thủ cạnh tranh và nhận được câu trả lời tương tự.

Kỹ sư: Vì vậy, bạn đang nói rằng đối thủ cạnh tranh của bạn đủ tốt hơn bạn rằng phần mềm của anh ta là thước đo để bạn đo lường phần mềm của mình? Âm thanh như chúng ta nên mua phần mềm của mình thay thế!


1
Tôi hy vọng rằng Kỹ sư phần mềm không quảng cáo rằng phần mềm được so sánh với chương trình khác, ngay cả khi đó là trường hợp trong phòng thí nghiệm. Tôi cũng sẽ nghĩ rằng một kỹ sư phần mềm sẽ đánh giá cao rằng có thể có các trường hợp cạnh chưa được bao phủ hoàn toàn với các bài kiểm tra đơn vị.
hazzey

2

Tôi đồng tình với các câu trả lời khác ở đây, rằng điều này nói chung có thể là một ý tưởng tốt và sẽ giúp đảm bảo tính chính xác của kết quả mô phỏng. Xét về mức độ tốt của nó so với các phương pháp xác minh khác, tôi cho rằng các kết quả và kiểm tra vật lý đã biết trước đây đều là những lựa chọn tốt hơn nếu khả thi, nhưng tính toán tay có thể yêu cầu đơn giản hóa quá mức nếu mô hình đủ phức tạp.

Điều tôi thực sự muốn chỉ ra là một điều chưa được giải quyết ở điểm cuối cùng: điểm yếu tiềm tàng của thực tiễn này. Sử dụng hai gói FEA khác nhau có thể bắt gặp một đặc thù của một gói gây ra lỗi, miễn là bạn có thể xác định phân tích nào là đúng và gói nào bị tắt. Tuy nhiên, có một số hạn chế chung đối với FEA nói chung, bất kể phương pháp hay cách thực hiện. Góc nhọn và các bộ tập trung căng thẳng khác gây ra điểm kỳ dị trong mô hình không phải là thứ sẽ thay đổi nhiều từ gói này sang gói khác, đây sẽ luôn là những điểm yếu. Đây là nơi đòi hỏi kiến ​​thức kỹ thuật và trực giác.

Tôi đã thực hiện mô phỏng trên các bộ phận mà tôi biết dễ dàng đứng lên trước một số ứng suất nhất định và mô hình cho thấy rằng ứng suất bên trong gấp 10 lần cường độ năng suất; điều này rõ ràng là không chính xác, bởi vì nó nằm trên một mẫu spline không liên quan và phần mềm FEA không như vậy.

Cuối cùng, rõ ràng là việc thay đổi phần mềm không loại bỏ lỗi người dùng. Nếu bạn mắc lỗi trong mô hình hoặc tham số, lỗi đó sẽ làm bạn khó chịu cho dù bạn sử dụng gì để phân tích.


Tôi không biết "mô hình spline không liên quan" là gì, vì vậy nhận xét này có thể không liên quan, nhưng nếu bạn đang bị căng thẳng bên trong với năng suất gấp 10 lần, có lẽ việc lập mô hình bằng vật liệu phi tuyến tính sẽ theo thứ tự? Điều đó sẽ loại bỏ nồng độ căng thẳng cục bộ cực đoan.
AndyT

Tại thời điểm này, tôi không nhớ nếu tôi đã sử dụng phản hồi vật liệu đàn hồi tuyến tính hoặc một cái gì đó cơ bản hơn, nhưng tôi không muốn mô phỏng chạy mãi mãi và đây là việc sử dụng FEA sớm cho chúng tôi. Nó thực chất là một thiết kế lại của một bộ phận hiện có mà chúng ta biết chế độ thất bại, và cách chúng ta phải thiết lập mô hình đặt một số hạn chế khó khăn trên spline (một spline không liên quan là hình dạng của hầu hết các răng bánh răng). Nếu tôi đang thực hiện một phân tích toàn diện hơn, tôi có thể thử và sửa nó, nhưng đây là bằng chứng về khái niệm, so với phần hiện có.
Trevor Archibald

1

Các điều kiện biên và kỹ thuật mô hình sẽ ảnh hưởng rất lớn đến kết quả. Những gì tôi đề xuất là chạy một phiên bản đơn giản hóa / lý tưởng hóa (như phẳng, hoặc đối xứng trục) và một phiên bản hoàn toàn vững chắc và so sánh hai phiên bản.

Vấn đề với hai phần mềm FEA khác nhau là dưới phần mềm, các bộ giải sẽ giống nhau. Sự khác biệt quan sát được có thể là từ các tiêu chí hội tụ khác nhau có thể, hoặc từ các giả định khác nhau về cách áp dụng các điều kiện biên. Bạn không kiểm tra mô hình, nhưng khả năng của mỗi người giải quyết biết nó đã đạt được một giải pháp.

Tôi nghĩ rằng kết quả FEA nên được xác nhận bằng các tính toán thông thường và bàn tay thông thường đầu tiên, sau đó bằng các mô hình tương tự nhưng khác nhau (ví dụ như chất rắn thay vì chùm tia) và cuối cùng bằng thử nghiệm vật lý để xem các bộ phận thất bại ở đâulàm thế nào FEA dự đoán. Các khi một phần sẽ thất bại là khó khăn hơn bởi vì nó được infuenced bởi các quá trình sản xuất, biến đổi vật chất và căng thẳng resudial.


Không phải tất cả các ngành kỹ thuật đều có sự sang trọng để có thể thực hiện một bài kiểm tra phá hủy vật lý. Trong kỹ thuật dân dụng và kết cấu, phần lớn các dự án đang xây dựng các hạng mục độc nhất một lần - xây dựng một công trình hoàn toàn riêng biệt chỉ để kiểm tra nó để phá hủy sẽ rất tốn kém!
AndyT

Điểm lấy. Vẫn là một ý tưởng tốt để xác nhận kết quả FEA bằng các xét nghiệm, ngay cả khi đó là với các mẫu hoặc tỷ lệ mẫu.
ja72

Tôi có thể thấy quan điểm của bạn ... nhưng trong sáu năm thiết kế cây cầu của tôi, tôi chưa bao giờ nghe về một bài kiểm tra vật lý được thực hiện trên mô hình quy mô của cây cầu.
AndyT

Vậy những cây cầu nào tôi nên tránh? Đùa. Vì vậy, phải có đủ biên độ an toàn để tính đến những thứ không phải mô hình với FEA. Không có thứ gọi là mô hình FEA chính xác 100%.
ja72

Thật vậy, chúng tôi có các yếu tố an toàn ở khắp mọi nơi! Tiêu chuẩn Anh BS5400 (hiện không còn tồn tại) bao gồm hệ số 1.1, được gọi là gammaf3, đó là "một yếu tố đánh giá không chính xác về tác động của tải, phân phối ứng suất không lường trước trong cấu trúc và sự thay đổi độ chính xác đạt được trong xây dựng . " tức là bất cứ điều gì phân tích FE của bạn cho bạn biết sự căng thẳng là gì, hãy nhân nó với 1,1 chỉ trong trường hợp đó là một giá trị vô thức.
AndyT
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.