User: unknown  ||   Login  ||  NEWS: Lecture by P. Yadegari, pyLife, WCFA2023, TFP to watch, FABER

 

Fatigue Lounge

News

Conference List

Photo Gallery

Reports

Links

Glossary

 

Title PragTic

Concept

PragTic SW

Author

FAQs

Bugs

Users

User Profile

 

Suporting Institutions

Sponsors

 

FME CTU in Prague

Language / Jazyk: English

Koncepce projektu


Úvod

Projekt je zaměřen na kategorii softwaru, která je v současnosti již poměrně slušně obsazena komerčními produkty. Během období, kdy jsem dělal průzkum pro svého zaměstnavatele ŠKODU VÝZKUM s.r.o., jsem v této oblasti získal jistý přehled. Mezi všemi těmito produkty jsme nebyli schopni nalézt jediný, který by splňoval naše požadavky. Pokud si chcete prohlédnout jejich stručný přehled, podívejte se do kapitoly 4.1 mé disertace. Přitom se jednalo o softwary vyvíjené už léta a s mnohem větším počtem programátorů, než si vůbec mohu představit. Zdá se, že se rok od roku stále zlepšují. Stále tu jsou však některé body, které se mi nelíbí.

Výpočet únavového poškození je pěkně komplikovaný problém. I když si seženete všechny ty materiálové konstanty, zatěžovací historii, popis technologie výroby a budete zkrátka znát všechno možné..., nebudete mít jistotu, že výsledek vašeho výpočtu je v pořádku. K tomu je potřeba ještě dosti zkušeností a znalostí.

V oblasti únavového výpočtu jsou stále oblasti, jejichž řešení je stále v běhu. Já osobně jsem se ve své disertaci zaměřil na vysokocyklovou multiaxiální únavu. Výpočet je zde o něco jednodušší a rychlejší oproti nízkocyklové únavě, takže by člověk mohl předpokládat, že se zřejmě po všech těch letech (problém se s velkou intenzitou řešil na počátku 90. let 20. století) nedostane k o moc lepším výsledkům. Jenže mně se to podařilo. Mám přitom dojem, že je tu navíc stále ještě prostor pro další zpřesňování.

Vyjma multiaxiální únavy existují i další oblasti, kde je potřeba věnovat řešení obzvláštní péči:

  • rychlý výpočet nízkocyklové únavy, kde se vyskytují plastizované oblasti;
  • termomechanická únava;
  • poškození způsobené creepem;
  • růst trhlin;
  • vibrační únava;
  • svary;
  • atd.

Je svým způsobem legrační, že obvykle nenajdete daný problém lokalizovaný do jediné oblasti. Naopak se tyto oblasti různě překrývají a ovlivňují výsledek únavového výpočtu.

Znalost všech těchto oblastí se stále rozvíjí. V souladu s tím se stávají výpočetní procedury čím dál složitějšími. Protože konstruktéři a výpočtáři vyžadují možnost takových specializovaných výpočtů, snaží se jim vývojáři jít na ruku a dané procedury jim poskytnout v rámci svých programů. Můj osobní pocit ale je, jako by v některých případech byl řešen především problém, jak danou otázku správně algoritmizovat, než ověření, s jakou úspěšností bude taková metoda reálně fungovat. U mnoha multiaxiálních metod implementovaných do komerčních balíků nevím o žádné referenci, která by hovořila o jejich testovaném použití a přesnosti.

Výrobci softwaru se přitom snaží chránit své výpočetní postupy před konkurencí. Proto pak ale případní uživatelé dostávají jen strohé, kouskovité informace o tom, co vlastně program dělá, na čem byl testován, s jakým výsledkem, atd.

A na závěr - pokud právě nespolupracujete s daným výrobcem softwaru na nějakém projektu implementace nové metody, nemáte žádnou možnost, jak testovat různé výpočetní přístupy, jejich nastavení, či jak je variovat. Tento bod byl pro mě prvopočátečním iniciátorem tohoto projektu.

up

Co dál s PragTicem?

Výzkumníkům

Jestliže jste výzkumník zabývající se tímtéž problémem, čelíte pravděpodobně stejné potřebě naprogramovat cokoli, co vymyslíte nového. Jak se výpočetní metody stávají stále složitějšími, narůstá také penzum práce, která musí být věnována programovací činnosti. Navíc, pokud by vaše metoda měla být testována i na nějakém konkrétním složitějšími technickém celku než je běžný hladký únavový vzorek, budete pravděpodobně konfrontován s potřebou zpracovávat MKP data.

Je docela dobře možné, že máte opravdu rád Matlab a jste schopen jej pro daný problém použít. Je třeba si ale uvědomit, že na to, abyste dokázal úspěšnost své metody, musíte také implementovat konkureční metody. Co se týče např. multiaxiálních metod, jakákoli komerční implementace se týká nanejvýš metod z počátku 90. let. Pak už je mrtvo a prázdno. Takže je to na vás.

A to není všechno. Únava je jev, který silně podléhá statistice. Abyste ověřil funkčnost své metody, budete muset pravděpodobně provést testování na velkém množství vzorků a různých zátěžných podmínkách. Já ověřoval 129 testů a ačkoli jsem se snažil tento bod optimalizovat, jak to jen šlo, stejně to byla hrůzostrašně únavná práce.

Dovedu si docela dobře představit, že lidí s vlastním softwarem řešícím podobný problém je po světě více. Přesto jsem neslyšel o nikom, kdo by svou práci nabídl ostatním. Nemáte také pocit, že všechna ta námaha je trochu zbytečná?

up

Konstruktérům a výpočtářům

Přiznávám, že v této oblasti jsem poněkud napřed před reálnými možnostmi PragTicu. Nicméně můj pohled na situaci následuje.

Únavářský software je poměrně drahá záležitost. Když jsem dohledával ceny na jaře 2005, byla běžná cena zahrnující zhruba svarový a teplotní modul zhruba na 1,5 milionu Kč a výš. Jedinou výjimkou byl WinLife, kde je kompletní cena cca na 300 tisících Kč (v poměru k výkonu to celkem odpovídá). Uvedené ceny překračují ceny MKP balíků.

Uživatel k tomu platí roční poplatek za tzv. maintenance, který leží někde mezi patnácti a pětadvaceti procenty nákupní ceny. Ten samozřejmě platit nemusíte a software stejně zůstane majetkem vaší společnosti. To ale v tomto případě není ideální volba, protože všechny únavové postprocesory MKP řešení jsou relativně mladé a stále se dosti aktivně rozvíjejí. Předpoklad, že vynecháte maintenance a za 3 roky vás prodejce pustí zpět, je, domnívám se, lichý - pokud tedy nemáte nějaké velmi dobré kontakty. V ostatních případech budete buď nuceni doplatit ušlý maintenance anebo si software koupit znovu.

Takže sláva, máte před sebou ten krásný, nový, drahý software. Hezky to načítá MKP data (no, mohou se tu vyskytnout problémy, jako se to stalo nám) a po výpočtu zobrazuje krásné barevné mapy únavového poškození dané virtuální součástky. Zkrátka úžasné! Možná ale máte dost zkušeností s MKP a jste trochu skeptičtí: "Udělal jsem opravdu vše správně?" Víte, že např. špatné okrajové podmínky mohou v MKP vést k velmi zavádějícím výsledkům a to přesto, že samotná metoda konečných prvků je fyzikálně i matematicky dostatečně zpracována.

A tak začnete číst znovu a znovu manuály, hledáte informace po knihovnách a na internetu. Nepříjemná pravda se pomaličku, polehoučku zjevuje. Jakkoli se výzkumníci snaží zlepšit řešení, stále disponuje příliš mnoha stupni volnosti. To znamená, že jednotlivé části řešení mohou být řešeny tak anebo jinak. Protože těchto nejistot je více, může se vám stát, že se špatnými předpoklady se dostanete k poměrně dobrému výsledku. Mnohem pravděpodobnější však je, že se od něj spíše vzdálíte.

V takové situaci by člověk čekal, že bude mít možnost plně ovládat výpočetní proces. Že bude mít přístup k detailnímu popisu pozadí výpočetní metody i k tomu za jakých okolností je plně ověřeno, že je metoda funkční a kdy si naopak dát pozor. Nemám pocit, že by něco takového existovalo. Automatizace výpočtu je úžasná věc a velmi zkracuje výpočet, ale vyhodnocení kvality výsledků je velmi obtížné.

Manuály jsou příliš často velmi stručné. Co byste řekli případu stručně načrtnuté metody doprovázené ujištěním že byla úspěšně testována na mnoha případech (nic víc neuvedeno), pokud posléze zjistíte, že v odborných periodikách existuje o ní jediný článek, který je zaměřen především na proces automatizace výpočtu?

Je docela běžné, že se výrobce softwaru zříká odpovědnosti za případné problémy vzniklé kvůli používání softwaru. To znamená, že jedinou garancí, kterou máte, je jméno dané společnosti a ona poměrně vysoká nákupní cena. Hm, asi by to neprodávali tak draho, kdyby to nebylo správně, že? Nebudeme přece paranoidní...

Takže ve zkratce:

  1. Koupě únavového postprocesoru je poměrně finančně náročná záležitost.
  2. Stejně jako každoroční platba maintenance.
  3. K výsledkům výpočtu je potřeba přistupovat nanejvýš opatrně.
  4. Počet osob mezi zaměstnanci, které jsou schopny se ponořit pod povrch výpočtu a říct co ty výsledky znamenají, je velmi nízký.

Je jasné, že možnými uživateli takového softwaru mohou být jen velké koncerny, popřípadě firmy na ně navázané.

Nebylo by zajímavé mít alternativu v nezávislém výpočetním systému s ne tak propracovaným prostředím, náčtem dat a vyžadujícím více uživatelských zásahů? Co kdyby to bylo zdarma - alespoň v základní variantě? Co kdyby byl kladen větší důraz na dokumentaci problému? Nebyla by to zajímavá aplikace i pro menší výpočtářské firmy?

up

Pokračování příště... Omlouvám se, stránky jsou dosud ve výstavbě.


papuga@pragtic.com

Fatigue Data Repository

Databases

Weld Data

Bike in-service record

Fatigue Strength estimation via Machine Learning methods

 

 

FABER Project

 

 

pyLife workshop 2023

 

Events, Lectures

Workshops on Computational Fatigue Analysis

Workshops on Computational Fatigue Analysis 2023 - FKM Guideline Non-Linear

1st Workshop on Thermodynamics of Fatigue Process

Recorded Lectures

D&DT for Aircraft Engineers

Subscribe to our mail list


 
 
 
Development in 2011-2014 supported by:
 
TACR
 
Alfa programme