Можно ли использовать две разные программы моделирования для подтверждения результатов друг друга?


8

Компьютерные Модели

Компьютерное моделирование используется в различных областях техники. Я специально рассматриваю структурный анализ или анализ методом конечных элементов (ВЭД). Иногда модели используются для ускорения повторяющихся расчетов, которые могут быть выполнены вручную. Иногда модели используются для выполнения вычислений, которые нелегко или даже невозможно сделать вручную.

проверка

Существует несколько стандартных методов проверки результатов компьютерных моделей.

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

Проблема с первыми двумя методами проверки, приведенными выше, заключается в том, что они либо проверяют только определенные ситуации, либо проверяют только простые части программы.

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

Это оставляет пробел в том, какие результаты могут быть проверены. Для любой сложной модели нет простого способа проверить правильность результатов программы. Инженер должен верить, что программное обеспечение дает правильные результаты из модели.

Проверка сравнения

Модель может быть введена в две разные программы (сделанные разными компаниями). Предполагается, что если результаты двух моделей достаточно похожи, то результаты должны быть правильными для используемой модели. Это не будет отлавливать ошибки при создании исходной модели, но будет отлавливать ошибки при реализации программного обеспечения.

  • Могут ли две отдельные программы использоваться для проверки «правильности» результатов модели?
  • Будет ли использование этого метода сравнения модели в двух отдельных программах обеспечивать такой же уровень уверенности в результатах, как и любой другой метод проверки?
  • Какие могут быть недостатки использования этой процедуры?

«Спейс Шаттл» вышел на орбиту, используя 5 бортовых компьютеров. 4 из них запустили одну и ту же программу, проверили результаты друг друга, договорились между собой, кто был вменяемым, и проголосовали за любого безумного участника. На пятом компьютере работала совершенно другая программа, написанная независимо другой командой. 'Так, на всякий случай'. Я не знаю, было ли это когда-либо необходимо.
Рассел МакМэхон

Обе компьютерные программы могут быть неправильными, поэтому я бы сказал нет. Это не хорошая практика. Лучше сравнивать численные решения со случаями, когда решение известно, аналитически, эмпирически или с помощью опубликованных исследований.
Пол

@Paul Да, именно так все обычно проверяется, но это только показывает, что программа работает для этой проблемы. Вы можете сделать предположение относительно того, что другие конфигурации, которые используют те же пути кода, также являются правильными, но всегда будет крайний случай. Предположение, включенное в использование двух отдельных программ, состоит в том, что у программистов есть ошибки в разных крайних случаях.
Хаззи

Ответы:


7

Да, получение второго мнения может быть полезным. Это обычно делается при прогнозировании погоды, когда точные решения неизвестны, и существует определенное мнение о том, как применять различные факторы.

Будет меньше места для маневра в чем-то вроде анализа напряжений в сетке конечных элементов, потому что итерационные уравнения для его решения будут в основном одинаковыми, независимо от того, кто написал программное обеспечение. Реальная проблема заключается не столько в решении меша, сколько в создании достаточно хорошего меша.

Поэтому один из способов получить несколько мнений - это изменить параметры сетки. Надеюсь, вы до сих пор получаете почти тот же ответ. Если вы сделаете сетку в 2 раза тоньше и получите существенно другой ответ, то это сильная подсказка, что оригинальная сетка недостаточно детализирована. Кроме того, вы не знаете наверняка, что следующая сетка достаточно детализирована, не делая еще более детальную и не получая тот же ответ.

Конечно, в настоящее время само создание сетки несколько автоматизировано и адаптивно. Это больше не просто физика решения меша, а эвристика о том, когда и как делить. Разное программное обеспечение может отличаться в этом отношении, поэтому может быть полезным запуск двух разных программ с одинаковыми исходными данными.


6

Я пишу это с точки зрения инженера, который разрабатывает программное обеспечение для моделирования.

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

В общем, два разных программного обеспечения для моделирования не могут быть использованы для подтверждения чего-либо, кроме их сходства. Два программного обеспечения могут легко получить два одинаковых, но неправильных ответа, особенно если они используют похожие модели. Я могу вспомнить хотя бы один случай, когда это точно так, а Тревор Арчибальд упоминает другой. Я был бы более впечатлен двумя программами, которые используют разные методы моделирования, получая схожие результаты.

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

Проблема с первыми двумя методами проверки, приведенными выше, заключается в том, что они либо проверяют только определенные ситуации, либо проверяют только простые части программы.

Это реальная проблема, стоящая перед разработчиками и пользователями программного обеспечения. Есть установленные способы справиться с этим, которые намного лучше, чем сравнение двух разных программ.

Проблема в том, что вы никогда не сможете проверить все возможные случаи. Ваше программное обеспечение может проходить случай А, но случай А не включает физику X, Y или Z, и это полностью исключает случай Б. Таким образом, вам нужно большое количество проверок, которые охватывают, по крайней мере, все основные функции, которые вы хотите проверить. Многие программные продукты имеют «комплекты V & V», которые в основном именно это.

С точки зрения проверки, существует множество вариантов. Вы можете генерировать новые точные решения для разных случаев. Иногда одного этого достаточно. Однако, как вы заметили, часто то, что вы можете сделать вручную, ограничено очень простыми случаями. Для более общих случаев можно использовать метод, называемый методом готовых решений (Google it). Это требует программирования и может запутаться, но позволяет вам протестировать практически все, о чем вы могли подумать. (Часть беспорядка может быть обработана через библиотеку как MASA , между прочим.)

Кроме того, я хотел бы отметить, что вопреки тому, что предлагает Олин Латроп, с помощью метода готовых решений вы можете создавать то, что для целей тестирования являются точными решениями. Они не являются «точными» в строгом смысле, потому что они точно не удовлетворяют уравнениям, которые программное обеспечение решает без изменений. Но они удовлетворяют уравнениям, которые очень близки, и разница учитывается, чтобы сделать тест строгим. Этот метод в настоящее время не очень популярен, но он использовался для проверки того, что раньше считалось трудным для тестирования.

С точки зрения валидации, вы можете искать больше экспериментальных данных или проводить свои собственные эксперименты.


4

Я думаю, что это хорошая практика в целом.

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

Если программное обеспечение достаточно разное, вероятность получения в два раза одного и того же неправильного результата низкая.

Тем не менее, таким образом нельзя избежать ошибок, связанных с неправильным выбором модели. Поэтому я бы сказал, что основным недостатком является чрезмерное доверие к результатам, поскольку они были подтверждены двумя программами.

Я действительно считаю, что лучше освоить одно программное обеспечение, выполняя все виды тестовых случаев (например, сравнение с академическими результатами), чем использовать несколько программ и иметь только средние знания. Более того, я думаю, что лучше всего знать основы анализа FEM, и использование только двух программ «один клик для запуска» является плохой практикой, потому что пользователи могут воспроизводить ошибки моделирования.

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


2

Ответ с точки зрения инженера-конструктора

Сравнение результатов одной программы с другой даст вам определенный уровень уверенности в правильности результатов. Это вряд ли даст вам 100% уверенности, но тогда такой уровень уверенности трудно достичь.

Большая проблема, которую я вижу, - это возможность переноса модели из одного программного обеспечения в другое. Хотя большинство программных компаний улучшают импорт / экспорт моделей (из-за BIM), я не ожидаю, что все функции модели будут экспортируемыми. Геометрию относительно легко импортировать / экспортировать, поскольку файл обмена должен содержать только координаты. Но, например, конечные выпуски участников, скорее всего, будут храниться по-разному в разных программах, поэтому, если / пока не будет согласован универсальный формат обмена файлами, я подозреваю, что потребуется много усилий, чтобы полностью перестроить модель во второй программе.

Исходя из моего собственного опыта, ошибки в результатах гораздо более вероятны из-за неправильного ввода данных или неверных предположений, чем из-за плохо написанного программного обеспечения. Следовательно, время и усилия при использовании независимого программного обеспечения для проверки ответа, вероятно, не являются хорошим использованием вашего времени.

Ответ с точки зрения разработчика программного обеспечения

Проверка программного обеспечения по сравнению с другим программным обеспечением не считается подтверждением правильности вашего программного обеспечения. Гораздо лучше найти опубликованные данные / результаты, которые можно использовать для проверки того, что программное обеспечение дает правильные ответы. Представьте себе встречу по продажам, на которой компания-разработчик пытается продать свое программное обеспечение инжиниринговой компании:

Инженер: Откуда мы знаем, что ваше программное обеспечение правильно?

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

Инженер: То есть, вы говорите, что ваш конкурент намного лучше вас, что его программное обеспечение является критерием, по которому вы измеряете свое программное обеспечение? Похоже, мы должны купить его программное обеспечение вместо этого!


1
Я надеюсь, что Software Engineer не афиширует, что программное обеспечение сравнивается с другой программой, даже если это имеет место в лаборатории. Я также думаю, что разработчик программного обеспечения будет признателен за то, что могут быть крайние случаи, которые не были полностью охвачены модульными тестами.
Хаззей

2

Я согласен с другими ответами здесь, что это в целом может быть хорошей идеей и поможет обеспечить точность результатов моделирования. С точки зрения того, насколько он хорош по сравнению с другими методами верификации, я бы сказал, что ранее известные результаты и физические тесты являются лучшими вариантами, если это возможно, но ручные вычисления могут потребовать чрезмерного упрощения, если модель достаточно сложна.

Что я действительно хочу отметить, так это то, что не было затронуто в последнем пункте: потенциальные слабые стороны этой практики. Использование двух разных пакетов FEA может выявить особенность одного пакета, который вызывает ошибку, при условии, что вы можете определить, какой анализ является правильным, а какой нет. Тем не менее, существуют общие ограничения FEA, независимо от метода или реализации. Острые углы и другие концентраторы напряжений, которые вызывают особенности в модели, не сильно изменятся от пакета к пакету, это всегда будут слабые места. Это где инженерные знания и интуиция необходимы.

Я провел моделирование деталей, которые, как я знаю, легко выдерживают определенные напряжения, и модель показывает, что внутреннее напряжение в 10 раз превышает предел текучести; это, очевидно, неверно, потому что оно имеет форму спонтанного сплайна, а ПО FEA это не нравится.

Наконец, должно быть очевидно, что смена программного обеспечения не устраняет ошибку пользователя. Если вы допустите ошибку в модели или параметрах, эта ошибка вас испортит независимо от того, что вы используете для ее анализа.


Я понятия не имею, что такое «эвольвентный сплайн-паттерн», поэтому этот комментарий может быть неактуальным, но если вы получаете внутреннее напряжение с 10-кратным выходом, возможно, вам подойдет моделирование с нелинейным материалом? Это позволит устранить экстремальные концентрации локального стресса.
AndyT

На данный момент я не помню, использовал ли я линейно-упругий отклик материала или что-то более простое, но я не хотел, чтобы моделирование работало вечно, и это раннее использование FEA для нас. По сути, это был редизайн существующей детали, для которой мы знаем режим отказа, и способ, которым мы должны были настроить модель, наложил некоторые жесткие ограничения на сплайн (эвольвентный сплайн является формой большинства зубьев зубчатого колеса). Если бы я проводил более всесторонний анализ, я мог бы попытаться исправить это, но это было больше подтверждения концепции по сравнению с существующей частью.
Тревор Арчибальд

1

Граничные условия и метод моделирования будут сильно влиять на результаты. Я предлагаю запустить упрощенную / идеализированную версию (например, плоскую или осесимметричную) и полностью твердую версию и сравнить их.

Проблема с двумя различными программами FEA заключается в том, что под капотом решатели будут практически одинаковыми. Наблюдаемые различия могут быть связаны с различными критериями сходимости или с различными предположениями о применении граничных условий. Вы не проверяете модель, но способность каждого решателя узнать, что она достигла решения.

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


Не все инженерные дисциплины могут позволить себе испытание на физическое разрушение. В гражданском и структурном проектировании подавляющее большинство проектов строят одноразовые уникальные предметы - создание совершенно отдельного объекта только для того, чтобы проверить его на разрушение, будет непомерно дорого!
AndyT

Дело принято. Хорошей идеей является проверка результатов FEA с помощью тестов, даже если это с образцами или частями.
ja72

Я понимаю вашу точку зрения ... но за шесть лет проектирования мостов я никогда не слышал о физических испытаниях, проводимых на масштабной модели моста.
AndyT

Итак, каких мостов мне следует избегать? Шучу. Таким образом, должны быть достаточные запасы безопасности, чтобы учитывать материал, а не модель с FEA. Нет такой вещи, как 100% точная модель ВЭД.
ja72

Действительно, у нас есть факторы безопасности везде! Британский стандарт BS5400 (в настоящее время в значительной степени несуществующий) включал в себя коэффициент 1,1, называемый gammaf3, который был «фактором, учитывающим неточную оценку эффектов нагрузки, непредвиденного распределения напряжений в конструкции и изменений в точности размеров, достигнутых в конструкции». «. т. е. независимо от того, что ваш анализ FE говорит вам о стрессе, умножьте его на 1,1 на случай, если это неконсервативное значение.
AndyT
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.