Po ponad dwudziestu latach zbierania komercyjnych i akademickich doświadczeń traktuję inżynierską dydaktykę (w tym – wdrażanie technik symulacyjnych) jako swoiste zadanie optymalizacyjne, czasem łatwe i przyjemne, niekiedy jednak zahaczające o „infeasible design”.
W tym artykule opiszę blaski i cienie takiego zadania, skupiając się na pracy ze studentami, a zostawiając na inną okazję specyfikę szkoleń i wdrożeń B2B.
Piętrowe wyzwanie
Software symulacyjny, który wdrażam na Politechnice Gdańskiej (OptiStruct, Ansys, Calculix, OpenFoam…), stawia dydaktyczne wyzwania na kilku poziomach naraz: środowiska, interfejsu, fizyki zjawiska i specyfiki/techniki/technologii samego modelowanego przedmiotu (pojazdu, konstrukcji, urządzenia…). Wyjaśnię po kolei:
◾ Środowisko, czyli system operacyjny i hardware
Pół biedy, jeśli pracujemy na Windowsach, gorzej, jeśli trzeba użyć Linuxa i trybu tekstowego. Podobnie może nieco „zaboleć” praca z komputerami zdalnymi, poprzez zdalne pulpity. Niekiedy w ogóle nie da się połączyć albo sesje się zrywają, brakuje miejsca na dyskach twardych, myli się komputer lokalny i zdalny… Zresztą bywają i bardziej podstawowe problemy, jak na przykład pytanie: „a do czego służy CTRL+F”? lub „co to znaczy, że nie mamy tworzyć plików na pulpicie?”. Pokolenie smartfonowców miewa już tego typu kłopoty z komputerami.
◾ Nawet najdroższy program ma bugi i różne uciążliwe „kwiatki”
Od ich opisu zaczynam zwykle zajęcia, aby przygotować uczestników na nieuniknione trudności, ale i tak zdarzają mi się w ankietach opinie takie jak te: „Program XXX jest programem niemożliwie nieintuicyjnym i bez funkcji „cofania”, co nieraz prowadziło do porzucenia wykonywanej pracy”, albo „Programy stosowane na zajęciach są beznadziejne. Nie można nawet sobie poćwiczyć na nich w domu przed zajęciami lub pojawiają się błędy, które wynikają z niewiadomej mi przyczyny. (…) Wracając do błędów, to powinien Pan uczyć nas jak interpretować i sobie z nimi radzić”.
Tymczasem software tego typu jest złożony jak – powiedzmy – las. Z wersji na wersję rozwija się, znikają jedne błędy, pojawiają się inne, niektóre zawinione przez użytkownika, inne przez programistów, jeszcze inne przez trudny do przewidzenia konflikt kodu, przedmiotu modelowania i środowiska. Mam zresztą wrażenie, że najbardziej kosztowne programy (rozwijane przez Autodesk, Ansys czy Siemens) są niekoniecznie dużo bardziej wolne od usterek i komplikacji niż te darmowe (FreeCAD, Salome, Calculix…). Sprzedawałem software i znam od kuchni presję na sprzedaż, niemal za wszelką cenę. Taniej jest przecież wzmocnić przekaz reklamowy niż żmudnie i uczciwie poprawiać to, co już „jakoś” działa. Programy są często sprzedawane „en bloc” z jednego koncernu do drugiego, co zrywa ciągłość ich rozwoju i powoduje efekt „patchworku”. A pisanie kodu od początku się prawie nigdy nie opłaca; zresztą nie gwarantuje, że tym razem powstanie już program-ideał.
◾ Interfejs użytkownika
Może być tekstowy, graficzny, lub – najczęściej – hybrydowy. Interfejs graficzny, pełen kolorów i ikon, jest sympatyczny, ale zwykle można w nim zdziałać mniej niż w hybrydowym. Niestety, elementy kodowania, wpisywania komend, niektórych odstraszają. Być może dlatego ANSYS w wersji „klasycznej”, który proponuję od wielu lat, i który jest wciąż bardzo istotny na rynku światowym, nie spotyka się zwykle z entuzjazmem studenckiej braci. Tu zresztą mam jeszcze pole manewru – mogę większą część zajęć poświęcić na zupełne podstawy, prowadzenie za rękę, zanim przejdziemy na głębsze wody.
◾ Fizyka zjawiska, specyfika modelowanego przedmiotu
Tu otwiera się prawie bezkresny obszar do zagospodarowania. W skrócie nazywam to „drony, smartfony, perony i sztuczne hormony”. Przygotowałem przez lata ćwiczenia dotyczące większości dziedzin inżynierii. Aby wymienić kilka tylko przykładów: modelujemy rower, batyskaf, zderzenie samochodu, spoinę, łuk strzelecki, bazę marsjańską, kamerton, miernik pola magnetycznego, spiralę grzejną i spinacz do papieru. W zanadrzu mam także symulacje mikrobiologiczne, a w przygotowaniu – mechanikę płynów. Każdy z takich obiektów to długa historia. Weźmy gotowanie jajka – jedno z najczęściej przeze mnie stosowanych ćwiczeń komputerowo-eksperymentalnych. Jaki software wybrać? Jak znaleźć wiarygodne dane materiałowe (przewodności i pojemności cieplne, gęstości żółtka i białka)? Jak traktować w symulacji nieścięte jeszcze białko: jako płyn czy ciało stałe? Jak traktować skorupkę? Czy warto/trzeba modelować ją oddzielnie? Jak porównać wyniki komputerowe z symulacją? W jaki sposób wiarygodnie zmierzyć czas, po jakim żółtko się ścina (częściowo, lub w całości)? Niby proste, przyziemne zagadnienie, a nie raz dało się nam – mi samemu i studentom – we znaki, mimo że cały skrypt tworzący model i ustawiający obliczenia przygotowałem zawczasu, i nie trzeba go pisać od podstaw. A przecież jajo to dopiero „przedszkole” inżyniera. Faktyczna praca w firmach wymaga rozumienia obiektów tak złożonych, jak samochody, samoloty, wymienniki ciepła, układy antenowe etc. Za każdym z nich stoi ogromna ilość wiedzy technicznej, technologii wytwórczych, norm, dobrych i złych praktyk.
cały artykuł jest dostępny w wydaniu 9/10 (228/229) wrzesień/październik 2026
