-
X-Received: by 10.140.109.53 with SMTP id k50mr413196qgf.13.1456056629369; Sun, 21
Feb 2016 04:10:29 -0800 (PST)
X-Received: by 10.140.109.53 with SMTP id k50mr413196qgf.13.1456056629369; Sun, 21
Feb 2016 04:10:29 -0800 (PST)
Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.
atman.pl!goblin3!goblin.stu.neva.ru!news.ripco.com!news.glorb.com!ok5no4130174i
gc.0!news-out.google.com!g2ni716qgg.1!nntp.google.com!w104no2429034qge.1!postne
ws.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: pl.sci.inzynieria
Date: Sun, 21 Feb 2016 04:10:29 -0800 (PST)
In-Reply-To: <4...@g...com>
Complaints-To: g...@g...com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=212.39.34.44;
posting-account=s_knbgoAAABnjazG523hnYRJDlH9qW0F
NNTP-Posting-Host: 212.39.34.44
References: <4...@g...com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f...@g...com>
Subject: Re: Inżynier analogowy vs cyfrowy
From: Konrad Anikiel <a...@g...com>
Injection-Date: Sun, 21 Feb 2016 12:10:29 +0000
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
Xref: news-archive.icm.edu.pl pl.sci.inzynieria:35800
[ ukryj nagłówki ]W dniu sobota, 20 lutego 2016 02:53:44 UTC+1 użytkownik s...@g...com napisał:
> Jakiś czas temu było na grupie o tym że nauka rysunku ręcznego to anachronizm.
> Ostatnio rzucił mi się tytuł o inżynierach hiszpańskich którzy
> zapomnieli uzględnić w obliczeniach masy uzbrojednia
> w projekcie łodzi podwodnej.
>
> Z innej bajki sam byłem świadkiem na budowie jak zanim młodzi inżynierowie
> wyciągnęli z laptopy to starzy majstrzy w głowie ile trzeba betonu.
>
> Jak tak czasami słucham mądrzejszych od siebie to oni traktują kompy jak
> pudełka. Coś powpisywali i wyskoczyło 1000.
> Trzeba tysiąc.
> A nikt się nie zastanawia czy taka liczba ma sens.
> A ręcznie oszczacować już nikt nie umie bo komputry robią wszystko.
W świecie coraz bardziej skomplikowanych metod projektowych, coraz bardziej wąskich
marginesów, zoptymalizowanych kosztów, coraz wyższych parametrów procesów, narzędzia
będą robiły coraz bardziej skomplikowaną robotę, czy się to komuś podoba czy nie.
Z tego wynika ileś tam wniosków:
1. Nie ma możliwości powtórzenia tej pracy ręcznymi metodami w rozsądnym czasie i z
zadowalającym poziomem zaufania. Komputer jak zrobi to samo miliard razy, to
prawdopodobieństwo zrobienia błędu nie wzrośnie, a jak sam coś zrobisz miliard razy,
to masz miliard szans na zrobienie błędu, o ile nie umrzesz wcześniej.
2. O wiele prościej jest zrobić oprogramowanie które automatycznie wykonuje mnóstwo
operacji, nawet jeśli jego użytkownik nie zna się na nich. Na przykład ja, jako
konstruktor, nie przejmuję się ani trochę że nie mam bladego pojęcia jakie algorytmy
są użyte w oprogramowaniu którego używam. Mam wiedzieć jak uzyskać wynik, jak
oszacować jego poprawność, jak wreszcie zaprezentować wyniki mojej pracy tak, żeby
inni ludzie w procesie nie zostali wprowadzeni w błąd. Ten Mars Climate Observer
został świetnie zaprojektowany, tylko ktoś w raporcie ze swoich obliczeń nie dopisał
co te cyferki oznaczają. On myślał że on robi cyferki, a w rzeczywistości robił sondę
kosmiczną. Cyferki wyszły śliczne, sonda poleciała w pizdu.
3. Kiedyś nawet grube pomyłki przechodziły niezauważone, bo marginesy projektowe były
bardzo duże. Tak naprawdę nikt nie wie, czy rzymskie Koloseum wytrzyma dwa razy
więcej widzów, czy może dwadzieścia razy więcej. Dzisiaj w bardzo wielu konstrukcjach
masz kryterium na przykład 95% rzeczywistej granicy wytrzymałości materiału (czy
jakiegoś innego, twardego kryterium po którym jest już tylko katastrofa). Pomyśl
tylko z jaką dokładnością trzeba określić parametry wejściowe, z jaką dokładnością
trzeba robić rachunki, jak trzeba robić próby materiałów, żeby wyeliminować wady, jak
trzeba kwalifikować procesy i personel itd.
4. Coraz wyższe parametry procesów powodują że to co projektujemy podlega coraz
większej liczbie mechanizmów zniszczenia i nie wiadomo które są istotne, a które
można zignorować. Ja w niektórych projektach mam 16 mechanizmów zniszczenia. Znaczy,
16 razy trzeba to samo zaprojektować, za każdym razem licząc inną fizykę, bo nie wiem
czy się połamie od zmęczenia, pełzania, ratchetingu, kruchego pęknięcia,
zlokalizowanego płynięcia w stanie braku umocnienia itp. Niektóre z tych symulacji
potrzebują własności materiałów które nie są dostępne w żadnej literaturze, trzeba
projekt zaczynać od programu badań materiału, żeby wiedzieć jak on się zachowa w
warunkach pracy.
To jest rzeczywistość dzisiejszej inżynierii. Ludzie którzy twierdzą że tu jest
gdzieś miejsce (i uzasadnienie) na jakieś idiotyzmy w rodzaju ręcznego rysowania
czegoś, nie wiedzą o czym mówią. Ręcznie to ja mogę narysować na tablicy szkic
jakiejś koncepcji, żeby komuś pokazać o co mi chodzi. Potem się wciska guzik i
zawartość tablicy wysyła się w postaci pdf-a na skrzynki emailowe zainteresowanych.
Następne wpisy z tego wątku
- 22.02.16 01:02 Robert Tomasik
- 22.02.16 12:44 J.F.
- 22.02.16 13:30 Robert Wańkowski
- 26.02.16 15:43 4...@g...com
- 02.03.16 11:53 s...@g...com
- 02.03.16 12:17 Konrad Anikiel
- 02.03.16 13:18 s...@g...com
- 02.03.16 14:12 Konrad Anikiel
- 09.03.16 20:46 W.Kr.
- 09.03.16 20:48 W.Kr.
Najnowsze wątki z tej grupy
- Ster w trolejbusie.
- DeepSeek nie lubi gadać o polityce
- pokolenie Z
- huta ruszyla
- piece wodorowe
- Żarówka do lampy z czujnikiem ruchu
- most kilometrowy
- kladka Zagorze
- zapora Zagorze
- Rodzaj przekładni planetarnej z
- Zapora Stronie Śląskie cd
- Filtr do pompy ruskiej
- Wyważanie kół rowerowych
- Belka
- Precyzyjne cięcie opony samochodowej
Najnowsze wątki
- 2025-03-05 Środa Wielkopolska => Konsultant wewnętrzny SAP FI/CO <=
- 2025-03-05 Zielona Góra => Senior Field Sales (system ERP) <=
- 2025-03-05 Warszawa => Data Engineer (Tech Lead) <=
- 2025-03-05 Kraków => Business Development Manager - Network and Network Security
- 2025-03-05 Zaniepokojeni mieszkańcy
- 2025-03-05 Ile pieniędzy ma bank?
- 2025-03-05 Ostrów Świętokrzy => Node.js / Fullstack Developer <=
- 2025-03-05 Białystok => Architekt rozwiązań (doświadczenie w obszarze Java, A
- 2025-03-05 Warszawa => Frontend Developer (Angular13+) <=
- 2025-03-05 Warszawa => Frontend Developer (obszar Angular13+) <=
- 2025-03-05 Chiny-Kraków => Backend Developer (Node + Java) <=
- 2025-03-05 Warszawa => JavaScript / Node / Fullstack Developer <=
- 2025-03-05 China-Kraków => Key Account Manager IT <=
- 2025-03-05 China-Kraków => Senior PHP Symfony Developer <=
- 2025-03-05 Gdańsk => Specjalista ds. Sprzedaży <=