Чи можна використовувати дві різні програми моделювання для підтвердження результатів один одного?

Комп'ютерні моделі

Комп'ютерне моделювання використовується в різних інженерних галузях. Я спеціально розглядаю структурний аналіз або аналіз кінцевих елементів (FEA). Іноді моделі використовуються для прискорення повторюваних розрахунків, які можна було б зробити вручну. Іноді моделі використовуються для виконання розрахунків, які непросто або навіть неможливо зробити вручну.

Перевірка

Існує кілька стандартних методів перевірки результатів комп'ютерних моделей.

• Запустіть верифікаційні моделі та підтвердьте, що результати відповідають попередньо обчисленій відповіді.
• Запускайте прості моделі, які можна перевірити ручними розрахунками.
• Перевірка фізичних моделей.

Проблема перших двох способів перевірки, наведених вище, полягає в тому, що вони або перевіряють лише конкретні ситуації, або перевіряють лише прості частини програми.

Метод фізичної моделі може бути дорогим для повнорозмірних моделей, а масштабні моделі не завжди можуть давати ті самі результати, що і повний розмір.

Це залишає прогалину в тому, які результати можна перевірити. Для будь-якої складної моделі не існує простого способу перевірити правильність результатів програми. Інженер повинен вірити, що програмне забезпечення дало правильні результати від моделі.

Перевірка порівняння

Модель може бути внесена у дві різні програми (зроблені різними компаніями). Припущення полягає в тому, що якщо результати двох моделей досить схожі, то результати повинні бути правильними для використовуваної моделі. Це не спричинило б жодних помилок у створенні оригінальної моделі, але воно призведе до помилок у впровадженні програмного забезпечення.

• Чи можна використовувати дві окремі програми для перевірки «правильності» результатів від моделі?
• Чи може використання цього методу порівняння моделі в двох окремих програмах забезпечити той самий рівень впевненості в результатах, як будь-який з інших методів перевірки?
• Які можуть бути недоліки використання цієї процедури?

Так, отримання другої думки може бути корисним. Це робиться звичайно при прогнозуванні погоди, де точні рішення невідомі, і є певне судження про те, як застосовувати різні фактори.

У приміщенні аналізу напруженості з кінцевими елементами буде менше місць, оскільки ітеративні рівняння для його вирішення будуть в основному однаковими незалежно від того, хто написав програмне забезпечення. Справжня проблема полягає не в тому, щоб вирішити сітку настільки, як створити достатньо хорошу сітку в першу чергу.

Тому один із способів отримати декілька думок - це зміни параметрів сітки. Сподіваємось, ви все одно отримаєте майже таку ж відповідь. Якщо ви зробите сітку в 2 рази більш тонкою і отримаєте суттєво іншу відповідь, то це сильна підказка, щоб оригінальна сітка була недостатньо детальною. Ви також точно не знаєте, що наступна сітка досить детальна, не роблячи ще більш детальної і не отримуючи приблизно однакової відповіді.

Зрозуміло, нині сама генерація сітки є дещо автоматизованою та адаптивною. Йдеться вже не про фізику розв’язання сітки, а включають евристику про те, коли і як підрозділити. У цьому плані різні програми можуть відрізнятися, тому запуск двох різних програм з однаковими вихідними даними може бути корисним.

Я пишу це з точки зору інженера, який розробляє програмне забезпечення для моделювання.

Я вважаю, що описана практика погана, і я рекомендую не використовувати два різних програмних забезпечення для "підтвердження" результатів.

Загалом, два різних програмних засоби для моделювання не можуть бути використані для підтвердження нічого іншого, крім їх подібності. Два програмних забезпечення можуть легко отримати два подібних, але неправильних відповіді, особливо якщо вони використовують подібні моделі. Я можу придумати хоча б один випадок, коли це, безумовно, так, і Тревор Арчібальд згадує інший. Мене більше вразить два програмні засоби, які використовують різні методи моделювання, отримуючи подібні результати.

Ця тема називається верифікацією та валідацією комп'ютерних моделей, і вона має досить велику літературу. Я запропоную ескіз основ. Перевірка - це порівняння моделі з «точним» рішенням (яке може бути ручним підрахунком або чимось складнішим), тобто перевірка математики програмного забезпечення. Припущення щодо точного рішення можуть бути помилковими, але, принаймні, ви хочете переконатися, що програмне забезпечення правильно відповідає математичній частині. Перевірка - це порівняння моделі з експериментом. Це дозволяє перевірити, чи модель, яку ви використовуєте, точна, що перевірка не може зробити для вас.

Проблема перших двох способів перевірки, наведених вище, полягає в тому, що вони або перевіряють лише конкретні ситуації, або перевіряють лише прості частини програми.

Це справжня проблема, з якою стикаються розробники та користувачі програмного забезпечення. Існують усталені способи поводження з цим набагато краще, ніж порівняння двох різних програмних програм.

Проблема полягає в тому, що ви ніколи не можете перевірити кожен можливий випадок. Ваше програмне забезпечення може передавати справу A, але випадок A не стосується фізики X, Y або Z, і це абсолютно не відповідає випадку B. Отже, що ви хочете, це велика кількість перевірок, які охоплюють принаймні всі основні функції, які ви хочете перевірити. Багато програмного забезпечення мають "V&V набори", які в основному саме так.

Щодо верифікації, існує чимало варіантів. Ви можете створити нові точні рішення для різних випадків. Іноді це одне адекватно. Однак, як ви вже помітили, часто те, що ви можете зробити вручну, обмежується дуже простими випадками. Для більш загальних випадків ви можете використовувати методику, яку називають методом виготовлених рішень (Google it). Це вимагає програмування і може стати безладним, але дозволяє протестувати в основному все, що ви могли подумати. (До речі, безладна частина може бути оброблена через бібліотеку типу MASA .)

Крім того, я хотів би зазначити, що всупереч тому, що пропонує Олін Летроп, за допомогою методу виготовлених рішень ви можете генерувати, які є, для тестування, точними рішеннями. Вони не є "точними" в суворому розумінні, тому що вони точно не задовольняють рівнянням, яке програмне забезпечення вирішує без змін. Але вони задовольняють рівняння, які дуже близькі, і різниця враховується для того, щоб зробити тест суворим. Ця методика наразі не дуже популярна, але її використовували для тестування речей, які раніше вважалися важкими для перевірки.

З точки зору перевірки, ви можете шукати більше експериментальних даних або проводити власні експерименти.

Я думаю, що це загалом хороша практика.

Використовуючи дві різні програмні програми, ви можете уникнути двох помилок: 1) помилок, які виникають із-за неточного програмного забезпечення (яке не слід випускати з уваги), 2) помилок, які виникають через відсутність звички користувача до програмного забезпечення (приховані параметри, налаштування за замовчуванням ...).

Якщо програмне забезпечення досить різне, шанси отримати два рази однакові помилкові результати низькі.

Однак помилок, які випливають з неправильного вибору моделювання, не можна уникнути таким чином. Тому я б сказав, що головним недоліком є ​​надмірна довіра результатам, оскільки вони підтверджені двома програмами.

Я думаю, що краще освоїти одне програмне забезпечення, виконуючи всілякі тестові приклади (порівняно, наприклад, з академічними результатами), ніж використовувати декілька програмних програм та мати лише середні знання. Більше того, я вважаю, що найкраще знати основи FEM-аналізу, а використання лише двох програмних програм "одним клацанням на запуск" є поганою практикою, оскільки користувачі, можливо, відтворюють помилки моделювання.

PS: Я пишу як користувач з аналізу електромагнетизму / термічного FEM (немає інших доменів).

Відповідь з точки зору інженера-дизайнера

Перевірка результатів однієї програми проти іншої дасть вам певний рівень впевненості, що результати правильні. Навряд чи це дасть вам 100% впевненість, але тоді такого рівня визначеності важко досягти.

Я бачу велику проблему - можливість передати модель з одного програмного забезпечення на інший. Хоча імпорт / експорт моделі вдосконалюється більшістю програмних компаній (через BIM), я не очікував, що всі функції моделі будуть експортованими. Геометрію відносно легко імпортувати / експортувати, оскільки обмінний файл повинен містити лише координати. Але, наприклад, випуски учасниць, ймовірно, зберігатимуться по-різному різним програмним забезпеченням, тому, якщо / до тих пір, поки не буде узгоджено універсальний формат обміну файлами, я підозрюю, що для повного відновлення моделі в другій програмі буде потрібно багато зусиль.

Виходячи з власного досвіду, помилки в результатах набагато частіше трапляються від неправильного введення даних або неправильних припущень, ніж від погано написаного програмного забезпечення. Тому час і зусилля для використання незалежного програмного забезпечення для перевірки відповіді, ймовірно, не є корисним для вашого часу.

Відповідь з точки зору програмного інженера

Перевірка програмного забезпечення щодо іншого програмного забезпечення не сприймається як підтвердження того, що ваше програмне забезпечення є правильним. Набагато краще знайти опубліковані дані / результати, за допомогою яких можна перевірити, чи програмне забезпечення дає правильні відповіді. Уявіть торгову зустріч, де програмна компанія намагається продати своє програмне забезпечення інженерній компанії:

Інженер: Як ми можемо знати, що ваше програмне забезпечення правильне?

Продавець програмного забезпечення: Ну, ми перевірили це на предмет програмного забезпечення нашого конкурента і отримали таку ж відповідь.

Інженер: Отже, ви говорите, що ваш конкурент достатньо кращий за вас, що його програмне забезпечення є мірою, за якою ви вимірюєте своє програмне забезпечення? Здається, ми повинні замість цього придбати його програмне забезпечення!

Я погоджуюся з іншими відповідями тут, що це в цілому може бути хорошою ідеєю і допоможе забезпечити точність результатів моделювання. Щодо того, наскільки це добре стосовно інших методів верифікації, я б сказав, що раніше відомі результати та фізичні тести є і кращими варіантами, якщо це можливо, але ручні розрахунки можуть зажадати надмірного спрощення, якщо модель є достатньо складною.

Те, що я дійсно хочу зазначити, - це те, на що не було вирішено остаточного питання: потенційні слабкі сторони цієї практики. Використання двох різних пакетів FEA може визначити особливість одного пакету, який викликає помилку, за умови, що ви можете визначити, який аналіз є правильним, а який - вимкненим. Однак існують деякі загальні обмеження щодо загальної ЗЕД, незалежно від способу чи реалізації. Гострі кути та інші концентратори напруги, що спричиняють особливості моделі - це не те, що сильно зміниться від пакету до пакету, це завжди будуть слабкі місця. Тут потрібні інженерні знання та інтуїція.

Я робив моделювання на частинах, які я знаю, легко витримую певні напруги, і модель показує, що внутрішнє напруження в 10 разів перевищує міцність; це, очевидно, неправильно, тому що це за схемою згладженого сплайну, а програмне забезпечення FEA цього не любить.

Нарешті, повинно бути очевидним, що зміна програмного забезпечення не усуває помилок користувача. Якщо ви допустите помилку в моделі або параметрах, ця помилка накрутить вас незалежно від того, що ви використовуєте для її аналізу.

Прикордонні умови та техніка моделювання значно вплинуть на результати. Що я пропоную - це спрощена / ідеалізована версія (наприклад, плоска або осесиметрична) та повністю суцільна і порівнюється.

Проблема двох різних програм FEA полягає в тому, що під капотом вирішувачі будуть майже однаковими. Розбіжності, що спостерігаються, полягали б у різних критеріях конвергенції, або в різних припущеннях щодо застосування граничних умов. Ви не перевіряєте модель, але здатність кожного вирішувача знати, що вона досягла рішення.

Я думаю, що результати FEA повинні бути підтверджені спочатку підрахунками здорового глузду та рук, потім за аналогічними, але різними моделями (наприклад, тверді речовини замість балок) і, нарешті, шляхом фізичного тестування, щоб побачити, чи не виходять з ладу деталі, де і як прогнозує FEA. , Коли частина зазнає невдачі є більш важким , так як він infuenced з допомогою виробничих процесів, матеріальних варіацій і resudial напружень.