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

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

Ще раз, це не означає, що вони не потрібні. Це не означає, що не треба намагатися розібратися в підґрунтях самого методу, але це означає, що зараз підходи до навчання треба трохи змінювати.

Перш ніж йти далі, нагадаю, що оригінальний “подкаст” (у всій його “пишноті” докладно можна прослухати на каналі: https://t.me/Saprobasni_Live/629 але нагадую, що відповіді йшли під час”забігів”, тобто звук ще гірший ніж зазвичай, а відповіді трохи сумбурніші).

Тепер ми перейдемо до другої частини “марлезонського балету”…. тобто, до питання:

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

Здається, що це два питання… І так воно і є. Але, ці питання частково взаємопов’язані.

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

Навіть якщо якісь опції вибираються автоматично, то це означає, що саме Ви їх залишили на вибір програми. Тож це ВАШЕ рішення.

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

Більше того, у двох різних калькуляторах можна зробити однакову послідовність операції, наприклад “2+2*2” (чи “6/2(2+1)”) і отримати різний результат. Але це не проблема калькуляторів, бо просто вони розраховані на різні аудиторії, які працюють відповідно до різних “алгоритмів”, що не відміняє можливості порахувати правильно, якщо ти знаєш математику. Ну а якщо не знаєш – то важко оцінити, який із варіантів правильний.

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

• загальні питання, і

• правильність постановки, які застосовуються до будь-якого або (якщо не до будь-якого) то до різного софту.

Звичайно, мені це простіше робити на потужному софті, який мені добре знайомий (а це Ansys), але це не про Ансіс, це про розрахунки.

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

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

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

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

Так чому, якщо програми можуть містити помилку, я вважаю, що все ок?

А це через те, що будь-яка компанія, яка пише подібне ПЗ, дуже ретельно займається тестуванням вирішувача (Solver). І якщо помилки інтерфейсу буває складно відловити і відповідно пофіксувати, то з вирішувачем все в якомусь плані простіше.

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

Звідки беруться такі завдання? Найчастіше це класичні теоретичні завдання, які мають чітке аналітичне вирішення.

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

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

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

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

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

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

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

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

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

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

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

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

Як приклад аналізу завдань, у яких “рахується одне й те саме, а результати “різні””:

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

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

А там уже кожен вирішує “що – куди” самостійно.

Втім, якщо є особлива думка – завжди буду радий дізнатися її та подискутувати.