_{оригінал був опублікований 2021.09.30}

Продовжуємо серію роздумів (частина 1, 2). На тему проблем у використанні МСЕ (методу скінченних елементів) та програм на цьому методі в інженерній практиці.

Нагадаю, що все почалося з питання: Яку наукову літературу можна прочитати про метод скінченних елементів (МСЕ)? Що можете порадити?

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

Все це було в рамках “підкасту” під час бігу: https://t.me/Saprobasni_Live/629

Перша частина присвячувалась питанню, а що нам можуть дати класичні книги, і чому саме “нічого”

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

І ось тут треба нагадати, що я не закликаю беззастережно вірити програмі, я стверджую, що глюки вирішувача (solver) знайти досить складно. Особливо ті глюки, які йдуть від вирішувача, а не від нас. А більшість помилок, все ж таки йде саме від нас.

Більше того, я вважаю себе “спеціалістом з CAE розрахунків “зі стажем”” (звісно, десь 20 років тому я сам дуже тіпався від використання стажу в якості аргументів, але… чи то просто постарів і потупішав, чи то знайшов мудрість, яка каже, що стаж, все ж таки, має деяке значення… ну принаймні в поєднанні з деякими іншими факторами)…

Так от, як “спеціаліст із розрахунків зі стажем”, я говорю, що спеціаліст зобов’язаний не вірити нікому, особливо собі. Або можна сказати так: як тільки-но спеціаліст із CAE розрахунків почав вірити собі – він помер (як спеціаліст).

І ось тут стає зрозуміло, що фраза вірити ПЗ більше ніж собі, не означає завжди вірити програмі. Адже собі ми не віримо. І треба розуміти, що цю фразу треба трактувати не у вигляді: “віримо результатам отриманим у ПЗ”, а “результати в ПЗ є продовження нас, а собі ми не віримо”.

Проте, слід розуміти, що “конструктор” і “спеціаліст з CAE (розрахунків)” це не є одне і те саме, і конструктор повинен бути впевнений у тому, що робить. Але не треба перетворювати віру в розрахунки в щось на кшталт “віри в Бога”. А лише, у вигляді розуміння яким шляхом він йде і обрання найбільш стійкого шляху з усіх. Ну чи одного з найстійкіших. І треба зауважити, що не того шляху, що здається стійким, а того, що є. А це означає, що перед використанням треба багаторазово перевіряти.

Тож, узагальнюючи:

Коли ми говоримо про програми, – ми їх повинні сприймати в якості “чорної скриньки”, що на вхід отримує одні дані, а на виході видає інші.

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

І лише після цього, можна починати потихеньку використовувати цю “чорну скриньку” в інженерній практиці. Але не треба забувати, що, навіть, якщо десь щось працює некоректно – це проблема “водія кобили”, а не самої “кобили”.

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

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

Крім того, треба розуміти, що є дві речі:

1. те, що ми хочемо порахувати (вриішити, знайти…)
2. те, що ми подали на вхід програми

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

Треба розуміти, що чим ближче “мова” програми до “нашої”, тим менш вона універсальна. Також треба розуміти, що потрібно відкривати хелп і читати в яких межах її (програму, програмну “мову”) можна використовувати. Якщо там не написано – перевіряти руками.

Через це, ще раз нагадаю, – чим вона (програма та її “мова”) “дружелюбніша” до дебілів (тобто людей, які не розуміють, що вони роблять) тим вужче діапазон застосування. За дебіла прошу не ображатися, я постійно кажу, що немає проблеми, якщо людина в чомусь не розбирається (якщо це не область її компетенції). Але якщо людина і не намагається розібратися в тому куди вона полізла…

то, нажаль, вилазять і жорсткіші епітети.

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

Гаразд. фіг з нами (їми) дебілами.. ідемо далі. Як переконатися, що Ви рахуєте правильно?

1. Ще раз нагадаю, якщо програма рахує неправильно, то в першу чергу це проблема не програми. Так, може її не можна використовувати в цьому випадку, може опцію не включили, може не те задали… Може навіть бути помилка в самій програмі. Але це наша проблема та наша помилка.
2. Якщо програма щось порахувала, це не означає що це , автоматично, правда. Навіть якщо Ви “все поставили правильно”. Бо хто сказав, що Ви все врахували, і зробили правильні припущення про те, що і як працює? А хто сказав… … … … … … загалом тут багато запитань
3. Але, навіть якщо, справді, все поставлено та пораховано правильно… Є ще питання інтерпретації (тобто аналізу та пояснення) результатів.

Вам здається що все? ну в цілому так. Але ні.

А все через те, що є низка питань, які відносяться і до постановки, і до інтерпретації, і навіть до працездатності програми, але потрібний додатковий опис і розшифровка… Або приклади

Отже у вас є конструкція, Ви знаєте, як вона працює Ви припустили як це працює, це порахували, проаналізували – все ок. Причому ОК – це означає, що помилок ви не допускали. І де тут можуть бути приколи?

• Ну, наприклад, зварювальник на підприємстві при виготовленні не контролював катет і якість зварювання.

• Або закінчився потрібний метал і взяли інший (причому можливо, що людям здалося, що вони взяли кращий)

• Або не було потрібного сортаменту, і об’єкт зварили зі шматків.

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

• Або хтось змінив поковку на лиття. Чи змінили постачальника лиття. Чи трохи порушили техпроцеси. або не порушили, але пройшли по краю допустимої області. причому по краю відразу кількох параметрів.

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

Формально ми знову повертаємося до того, що ми помилилися в постановці та аналізі, але для цього треба розуміти, що 2+2 не тільки 4, але й залежить від того, продаємо ми чи купляємо. А у “воєнний час” може досягати і 10. Загалом це приходить із досвідом. (жарт про воєнний час писався до 2022.02.24)

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

а ми все це рахуємо у найпростішій лінійній статичній постановці. І на базі цього робимо висновки: чи працюватиме конструкція, чи ні. Хтось може почати говорити, що так не буває. але в більшості стандартів, які ми використовуємо – ми уникаємо всіх описаних явищ у бік лінійного розрахунку і компенсуємо не тільки запасом, а й коефіцієнтами по “граничним станам” та ін.

ми спрощуємо конструкції, забуваємо за деталі та деталізацію. забуваємо за безліч речей та подробиць. І продовжуємо так працювати. І це буває правильним.

Чому?

• Через те, що точний розрахунок вимагає величезної кількості невідомих даних, що нам дійсно невідомі.

• Через те, що точний розрахунок потребує дуже складних розрахунків, дуже складного аналізу (результатів). Дуже багато ресурсів. І насамперед часу.

• Через те, що вони вимагають офіційної підготовки кадрів. а їх (кадрів) немає. є ми

АЛЕ

Нікого не цікавить, що всього цього немає. Бо нам треба щось робити. Тож на основі:

• досвіду, статистики, порівняння розрахунків і дійсності та всього іншого, розробляються методи, які дозволяють:
  • тим спеціалістам (або не спеціалістам), які є,
  • на тому устаткуванні/ПЗ що є,
  • за той час який є (а вірніше якого немає),
  • з урахуванням тих даних, які є…

Загалом…. розробляються методи, які дозволяють вести проектування, навіть коли нічого цього немає, а є одні проблеми.

Чи завжди успішно працюють такі методики? нажаль НІ!

Чи можна без них? теж – ні!

І якщо формально підходити:

• постановка неправильна,
• софт якийсь незрозумілий, р
• озрахункова схема та точність – ні в МСЕ ні в ЗСУ (алюзія на загальновідому фразу про “червону армію”, але жодним чином не спроба якось принизити ЗСУ – їм низький уклін, честь і хвала).
• Аналіз результатів дає результати, порівняні з ворожінням на кавовій гущі. Причому насамперед із загального підходу.

Загалом, все неправильно. Все окрім результатів.

Чому? Яким чином?

А отаким! Як то кажуть: “через те, що гладіолус!”. Бо коли все це поєднується у єдину методику все разом це може стати правильним. Але не через те, що мінус на мінус завжди дає плюс. А через те, що це було зроблено з урахуванням “емпірики”: сплаву реальності, фізики, досвіду. І 90% класичних методик розрахунків саме так і народжувалися. У тому числі тих, які зараз пувійшли до стандартів (і не тільки “наші”).

Проте, треба пам’ятати, що будь-яка зміна “чогось” у таких методах – вкрай негативно може вплинути на результати. Якщо ми візьмемо МСЕ з програмами, та в чистому вигляді застосуємо їх як заміну застарілому “сопромату” у класичних методиках. Ми в 90% отримаємо ахінею та купу проблем.

А щоб привести це до реальності, доведеться витратити купу часу. Людського часу

І ми знову повертаємося до питання. Як переконатися, що рахуєш (вирішуєщ задачі) правильно? Ви досі не зрозуміли? погано…

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

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

Відповідно треба поглиблювати та розширювати знання з того, як працюють наші конструкції, з мови спілкування з ПЗ (як конкретним ПЗ, там і взагалі подібного класу), методами розрахунку, експерименту…

Крім знань треба поглиблювати та розширювати розуміння та навички.

Кажуть, щоб стати в чомусь майстром, треба витратити 10 000 годин.

Отак і тут. Розраховуємо в ПЗ задачі аналогічні до аналітичних, розраховуємо завдання з перевірок… із підручників, із реальної практики. Вносимо невеликі (та з часом великі) зміни для того, щоб у мозку виробилося розуміння того, як це працює. Ретельно перевіряємо ці знання та розуміння.

Весь час ставимо питання досвідченішим товаришам і перевіряємо всіх і вся, починаючи з себе.

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

Як можна прискорити процес? Перш ніж сідати за комп’ютер, намагаємося прикинути, що ми будемо робити і що ми матимемо на кожному з етапів. Прикидаємо, що ми повинні отримати якісно та кількісно. І постійно порівнюємо наші прикидки та результат. У кожному випадку, не важливо чи співпал, чи ні – тричі перевіряємо, та намагаємося зрозуміти чому так. Знову ж таки робимо припущення і перевіряємо.

І працюємо, працюємо, працюємо. Напрацьовуємо у мозку нейронні зв’язки. Формуємо “природний штучний інтелект” заточений під вирішення таких завдань.

Коли перевіряємо будь-які завдання (хоч із теорії, хоч із практики), нам їх завжди треба ділити на три зони: гарантовано робоча, гарантовано неробоча, і щось середнє (наче іноді працює, іноді ні, але хз. чому). І для кожного методу розрахунку, для кожного випадку ми в картині нашого внутрішнього світу повинні виробити знання і розуміння чому так. А також відпрацювати навичку визначати в яку із зон зі своїми розрахунками ми потрапимо. Рано чи пізно виробиться стійка впевненість (і я говорю не про ту впевненість, що “та я в усьому розібрався” у стилі “идущего к реке”)

А скоріше в сократівську: я знаю, що я нічого не знаю, але багато хто не знає і цього.

Але перевіряти себе треба, навіть після цього 🙂

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

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

Якщо готовий – Вам пощастило. Якщо ні…. то більшість іншого міркування просто втрачає сенс. Там є про що поговорити… і щось додаткове в аудіо-подкасті є… Але чи треба це писати? вирішувати не мені