И снова здравствуйте (с)
Итак, в первой части мы рассматривали какие есть книги по МКЭ (методу конечных элементов) и что большая часть таких книг также помогает разобраться в современных программах их среднестатистическому пользователю, как и книги по термодинамике ДВС повышают качество вождения среднестатистического водителя.
Еще раз, это не значит, что они не нужны. Это не значит, что не надо пытаться разобраться в подоплеках самого метода, но это значит что сейчас подходы немного надо менять.
Прежде чем идти раньше напомню, что оригинальный "подкаст" (во всем его "великолепии" подробно можно прослушать на канале: https://t.me/Saprobasni_Live/629 но напоминаю, что ответы шли в ходе "забегов", т.е. звук еще хуже чем обычно, а ответы чуть более сумбурны.
Теперь мы перейдем ко второй части марлезонского балета. т.е. к вопросу:
"как понять, что ты считаешь правильно, как убедиться, что программы считают правильно"
Кажется что это два вопроса. и так оно и есть. но это вопросы частично взаимосвязанные.
Что тут надо понимать. По первой части ("как понять, что ты считаешь правильно") - любая Программа - это не более чем калькулятор (более подробно на блоге сапробасен по ссылке). Да он продвинутый. Он с бОльшим количеством кнопок, он визуальный. Но это тупой калькулятор, который делает только то, что Вы ему сказали сделать.
Даже если какие-то опции выбираются автоматом - то вы их оставили на выбор программы. Но это ВАШЕ решение.
Естественно что также как калькуляторы есть "для бухгалтеров" для "инженеров" и пр. Так есть и программы в которых очень различен функционал.
Более того в двух разных калькуляторах можно ввести одни и те же операции 2+2*2 и получить разный результат. Но это не проблема калькуляторов, ибо просто они рассчитаны на разные аудитории, которые просто работаю в соответствии с разными "алгоритмами", что не отменяет возможности посчитать правильно, если ты знаешь математику. Ну а если не знаешь - то трудно оценить, какой из вариантов правильный.
именно поэтому и надо учиться правильно считать и именно для этого я веду ютуб канал... и именно поэтому я снимаю видео не про конкретный софт (по большей части) а про общие вопросы, и правильность постановки, которые применимы к любому или к(если не к любому) то к разному софту. Естественно мне это проще делать на мощном софте, который мне хорошо знаком (а это Ansys), но это не про Ансис, это про расчеты.
Из выше сказанного становится понятен посыл, что я как расчетчик априори считаю, что программы считают правильно и вопрос лишь к пользователю с тем ЧТО они считают.
Соответственно нужно пояснить почему я считаю, что программы считают правильно, и других вариантов тут нет.
1. Все всегда делают люди. И программы тоже пишут люди. И даже очень дорогие программы содержат ошибки. Особенно в интерфейсе на каких-то редких сочетаниях. Но и в решении задач ошибки бывают. И в лиц соглашении сказано, что никто за это ответственности не несет.
Но ведь и в экспериментах бывают ошибки, и даже в аналитических методах расчета есть случаи, когда в целом все считается точно, но в отдельных точках - проблемы. Причем последнее это не ошибка, это просто сложности применимости чистой аналитики в отдельных случаях.
Так почему если программы могут содержать ошибку, я считаю что все ок?
Потому что любая компания которая пишет подобное ПО очень тщательно занимается тестированием решателя. И если ошибки интерфейса бывает сложно отловить и соответственно пофиксить, то с решателем все в каком-то плане проще.
И существуют сотни и тысячи задач, на которых проверяют правильность работы инженерного ПО. Часть из них доступны пользователям. В хелпе программ есть раздел "Verification Manual" в рамках которого описываются как раз такие задачи и методы их решения. Кстати, как по мне такие задачи даже более полезны чем туториал. Потому что туториал учит кнопкам программы, а верификейшн меньюал - правильным постановкам.
Откуда берутся такие задачи? Чаще всего это классические теоретические задачи, которые имеют четкое аналитическое решение.
Также это бывают реальные эксперименты, которые не имеют аналитического решения, но повторены и проверены многократно и имеют четкие границы работоспособности и характер изменения результатов.
Очень часто бывают веселые задачи от клиентов компании разработчика инженерного ПО, которые сталкиваются с какими-то веселыми задачами, и они просто так не решаются.
Собственно чем ближе софт к вашей отрасли и чем больше у него клиентов которые занимаются задачами сходными с Вашими - тем выше вероятность того что там все считается ок.
Еще раз повторюсь таких задач - тысячи, а то и десятки/сотни тысяч (зависит от разработчика) и при любом изменении автоматизировано проверяется адекватность решения всех этих задач.
У нас, как у пользователей, возможности проверить столько задач - нет. Плюс для того чтобы делать такие проверки нужно понимать и программирование и математику и физику, иначе будет не совсем понятно "а судьи кто?". Естественно это не значит, что проверять не надо. Но как бы надо понимать что проверяешь ;)
По своему опыту могу сказать, что за 20 лет работы в разных CAE комплексах, у нас были примеры ошибок в последних. И не так мало. Но почти все - это просто глюки интерфейса. Что касается решателей, то тут все гораздо стабильнее. Пара случаев есть, но там все было понятно уже на этапе ввода данных. Плюс это "официальные" глюки, которые были официально пофикшены самой компанией, и они были найдены достаточно быстро самой же компанией.
Если вы решаете что-то редкое - то ошибки могут возникать чаще, но для редкого и понимания нужно больше. Так что сотрудничайте с компанией разработчиком и будет Вам счастие.
Чаще всего, когда мы видели какие-то неточности или несовпадения результатов, которые были получены в разном ПО или в разных постановках. Это были не глюки программ, а либо разные алгоритмы работы в программах. Либо, что еще чаще, - наши собственные глюки.
По итогу тестирование ПО я делаю скорее чтобы понимать возможности, чем точности. Хотя для принципиально новых программ - стараюсь насчитать сначала кучу всего мелкого, чтобы понять как оно работает.
Нередко работаю в двух программах сразу сравнивая результаты и выискивая свои глюки.
И вот тут мы снова возвращаемся к тому, а как же понять есть "свой глюк" или нет? Тут можно только порекомендовать расти над собой всеми возможными способами - но не только увеличивая практику, но и погружаясь в пучины теории. Можно делать это не только читая, но и задавая вопросы более опытным коллегам.
Как пример разбора задач, в которых считается одно, а результаты разные:
Настоятельно рекомендую всегда считать чуть больше чем надо, всегда быть более компетентным чем надо для выполнения практических задач и пр.
А там уже каждый решает "что - куда" самостоятельно.
Впрочем, если есть особое мнение - всегда буду рад узнать его и подискутировать.
