Продолжаем серию рассуждений (часть 1, часть 2). На тему проблем в использовании МКЭ и программ на этом методе в инженерной практике.
Напомню, что началось все с вопроса: Какую научную литературу можно прочитать про метод конечных элементов (МКЭ)? Что можете порекомендовать?
и дошли до: как понять, что ты считаешь правильно, как убедиться, что программы считают правильно, как доказать другим, что считаешь правильно и ты и программа.
Все это было в рамках "подкаста" на бегу: https://t.me/Saprobasni_Live/629
Первая часть посвящалась вопросу, а что нам могут дать классические книги, и почему это "ничего"
Вторая, почему не смотря на то, что программы содержат ошибки им надо верить. Причем верить больше чем себе.
И вот тут я напомню, что я не призываю безоговорочно верить программе, я утверждаю, что глюки решателя найти достаточно сложно. Особенно те глюки которые идут от решателя, а не от нас.
Более того, как расчетчик со стажем (да 20 лет назад я сам бесился от упоминания стажа, но то ли просто постарел и отупел, то ли обрел мудрость, которая говорит что стаж все таки имеет некоторое значение, по крайней мере в сочетании с другими факторами)...
Так вот, как расчетчик со стажем, я говорю, что расчетчик обязан не верить никому, особенно себе. Ну или: как только расчетчик начал верить себе - он умер.
И прочая, прочая... И вот тут становится понятно что фраза верить ПО больше чем себе, не означает верить программе. Ведь себе то мы не верим. И надо понимать, что эту фразу надо трактовать не как: верим результатам полученным в ПО, а результаты в ПО - есть продолжение нас, а себе мы не верим.
Да конструктор и расчетчик это не есть одно и то же, и конструктор должен быть уверен в том что делает, но это должна быть не вера аки в Бога. А понимание по какому пути он идет и избрание наиболее устойчивого пути из всех. Ну или одного из наиболее устойчивых. Причем не того, который кажется устойчивым, а того который является. А это значит что прежде использования надо многократно проверять.
В общем. Говоря про программы мы их должны воспринимать как некий черный ящик. Который на вход получает одни данные, а на выход выдает другие.
Естественно, что желательно убедиться, что такой процесс происходит достаточно устойчиво. Естественно надо немного представлять внутренности и принцип работы черного ящика, а также понимать что именно на входе гарантированно приводит к изменению выхода, а что может привести.
И вот после этого, можно начинать пытаться использовать этот черный ящик в инженерной практике. Понимая, что даже если где-то он работает не корректно - это проблема водителя кобылы, а не самой кобылы.
Естественно что нам хочется думать, что раз программа нам выдала результат - то это и есть ответ на вопрос. Но нужно понимать что программа имеет свой язык, на котором она понимает задачу, свой язык на котором она выдает результаты. И оба этих языка надо знать нам.
Для каких-то простых случаев она даже может общаться на языке приближенном к нашему, но он ей всегда чужд
Кроме того, надо понимать, что есть две вещи:
- то что мы хотим посчитать
- то что мы подали на вход программы
и это совсем не одно и то же. Программа не умеет читать наши мысли, и даже наш язык не понимает. Поэтому именно наша задача научиться понимать тот язык, с помощью которого программа принимает данные на вход.
Надо понимать, что чем ближе язык программы к "нашему" тем менее она универсальна. Также надо понимать что нужно открывать хелп и читать в каких пределах ее можно использовать. Если там не написано - проверять руками.
Потому что, еще раз напомню, чем она "дружелюбнее" к дебилам (т.е. людям, которые не понимают, что они делают) тем уже диапазон применимости. За дебила прошу не обижаться, я постоянно говорю, что нет проблемы если человек в чем-то не разбирается (если это не область его компетенции). Но если человек и не пытается разобраться в том куда лезет....
то к сожалению вылазят и более жесткие эпитеты.
Кроме того как человек, который давно занимается популяризацией и обучением, я знаю что гиперболы дают более четкую (хоть и не всегда правильную) картину мира, и больше эмоций, что способствует и запоминанию, и пониманию. Себя я дебилом тоже называю не так уж и редко... если уж совсем быть честным
Ладно. фиг с нами (йими) дебилами и идем далее. Как убедиться что Вы считаете правильно?
1. Еще раз напомню, что если программа считает не правильно, то в первую очередь это проблема не программы. Да, может она не применима в этом случае, может опцию не включили, может не то задали.... Может даже быть ошибка. Но это наша проблема и наша ошибка.
2. Если программа что-то посчитала то, это не значит автоматически что это правда. Даже если вы "все задали правильно". Потому что а кто сказал что вы все учли, и сделали правильные предположения о том, что и как работает? А кто сказал... в общем тут много вопросов
3. Но даже если действительно все задано и посчитано правильно... Есть еще вопрос интерпретации (т.е. анализа и объяснения) результатов.
Вам кажется все? ну в целом да. Но нет.
Потому что есть ряд вопросов которые относятся и к постановке и к интерпретации и даже к работоспособности программы, но нужно дополнительное описание и расшифровка... Ну или примеры
Итак у вас есть конструкция, Вы знаете как она работает Вы предположили как это работает, это рассчитали, проанализировали - все ок. Причем ОК - это значит что ошибок вы не допускали. И где же тут могут быть приколы?
Ну например сварщик на предприятии при изготовлении не контролировал катет и качество сварки.
Или закончился нужный металл и взяли другой (причем возможно, что людям показалось что они взяли лучший)
Или не было нужного сортамента, и объект сварили из кусков.
Или Вы отработали конструкцию по номиналу. но не проверили, а что будет если размеры будут с учетом полей допусков и общей технологичности
Сменили поковку на литье. Сменили поставщика литья. чуть нарушили техпроцессы. или не нарушили но прошли по краю допустимой области. причем по краю сразу нескольких параметров.
Более того вы даже могли провести оптимизацию параметров, сделать оптимальную конструкцию, но не учесть, что оптимальная - значит очень чувствительная к любым изменениям чего либо.
Формально мы снова возвращаемся к тому что мы ошиблись в постановке и анализе, но для этого надо понимать что 2+2 не только 4 но и зависит от того продаем мы или покупаем. А в военное время может достигать и 10. В общем это приходит с опытом.
А еще есть другой вариант. Мы считаем и считаем лажу. У нас в конструкции и пластика, и ползучесть и длительные многоцикловые нагружения и ударные деформации, и контакт и динамика... и чего там только нет.
а мы все это считаем в простейшей линейной статической постановке. И на базе этого делаем выводы будет ли работать конструкция или нет. Кто-то может начать говорить что так не бывает. но в большинстве стандартов которые мы используем мы уходим от всех описанных явлений в сторону линейного расчета и компенсируем не только запасом, но и коэффициентами по "предельным состояниям" и пр.
мы упрощаем конструкции, забываем за детали и детализацию. забываем за очень многое. И продолжаем так работать. И это бывает правильным
Почему?
потому что точный расчет требует огромного числа неизвестных данных, а они реально нам не известны.
Потому что точный расчет требует очень сложных расчетов, очень сложного анализа. Очень много ресурсов. И в первую очередь времени
потому что они требуют офигительной подготовки кадров. а их нет. есть мы
НО
Никого не интересует что всего этого нет. И нам надо что-то делать. И на основе опыта, статистики, сравнения расчетов и действительности и пр. разрабатываются методы, которые позволяют тем специалистам (или не специалистам), которые есть, на том оборудовании/ПО что есть, за то время которое есть (а вернее которого нет), с учетом тех данных которые есть...
В общем разрабатываются методы которые позволяют вести проектирование даже когда ничего этого нет, а есть одни проблемы.
Всегда ли успешно работают такие методики? НЕТ!
Можно ли без них? тоже - нет!
И если формально подходить: постановка неправильная, софт не подходящий, расчетная схема и точность - ни в МКЭ ни в красную армию. Анализ результатов дает результаты сравнимые с гаданием на кофейной гуще. Причем в первую очередь по общему подходу.
В общем все неправильно. Все кроме результатов.
Почему? Как так?
А вот так! Потому что гладиолус. Потому что в совокупности это правильно. Но не потому, что минус на минус дал плюс. А потому что это сделано с учетом эмпирики: сплава реальности, физики, опыта. И 90% классических методик расчета именно так и рождались. В том числе тех, которые сейчас вошли в стандарты (и не только наши).
Но надо помнить что любое изменение чего либо в таких методах крайне негативно влияет на результаты. Если мы возьмем МКЭ с программами и в чистом виде применим их как замену устаревшему "сопромату" в классических методиках. Мы получим ахинею и кучу проблем.
А чтобы привести это к реальности придется потратить кучу времени. Человеческого времени
Так все же. Как убедиться в том, что считаешь правильно? Вы до сих пор не поняли? Никак, ибо мы всегда считаем неправильно и не то. Важно просто чтобы итог нашей деятельности на основе имеющихся данных и
ресурсов, был предсказуем и предсказания совпадали с реальностью.
Соответственно надо углублять и расширять знания по тому, как работают наши конструкции, по языку общения с ПО (как конкретным ПО, там и вообще подобного класса), методам расчета, эксперимента...
Кроме знаний надо углублять и расширять понимание и навыки.
Говорят что чтобы стать в чем-то мастером надо потратить 10 000 часов.
Вот так и тут. Считает задачи из аналитики, считаем задачи из проверок... из учебников, из практики. Вносим небольшие и большие изменения с тем чтобы в мозгу выработалось понимание того, как это работает. Скрупулёзно проверяем это знание и понимание.
Все время задаем вопросы более опытным товарищам и проверяем всех и вся, начиная с себя.
Снова перечитываем книги. Снова возвращаемся к уже решенным задачам..
Как можно ускорить процесс? До того как садимся за комп, пытаемся прикинуть, что мы будет делать и что мы будем иметь на каждом из этапов. Прикидываем что мы должны получить качественно и количественно. И постоянно сравниваем наши прикидки и итог. В случае хоть совпало хоть нет - трижды проверяем и пытаемся понять почему так. Опять же делаем предположения и проверяем.
И работаем, работаем, работаем. нарабатываем в мозгу нейронные связи. Формируем "естественный"-"искусственный" "интеллект" заточенный под решение таких задач.
Когда проверяем любые задачи (хоть из теории, хоть из практики), нам их всегда нужно делить на три зоны: гарантированно рабочая, гарантированно нерабочая, и что-то среднее (вроде как иногда работает, иногда нет, но хз. почему). И для каждого метода расчета, для каждого случая мы у себя в картине нашего внутреннего мира должны выработать знание и понимание почему так. и навык определять в какую из зон со своими расчетами мы попадем.
Рано или поздно выработается стойкая уверенность (и я говорю не про ту уверенность, что "да я во всем разобрался" в стиле "идущего к реке")
А скорее сократовскую: я знаю что я ничего не знаю, но многие не знают и этого.
Но проверять себя надо :)
остался вопрос, а как доказать кому-то что ты считаешь правильно, или что программы считают правильно.
Тут ответ прост. он лежит не в области методологии а по сути человеческой природы и "политики". Проверяющий Вас должен сам пройти по тем же дорогам, что и Вы (см выше по публикациям). И либо он готов это делать либо нет.
Если готов - Вам повезло. Если нет.... то большая часть остального рассуждения просто теряет смысл. Там есть о чем поговорить... и кое что дополнительное в аудио-подкасте есть... Но надо ли это писать? решать не мне