procesor do obliczen MES

Ulf pisze:

Zapomnij. Kto taki test miałby opublikować? Producenci softu? Dostawcy sprzętu? Niezależne pismo? W każdym przypadku narobiliby sobie wrogów, a po co? Konrad PS jakie analizy masz na myśli?

Dnia 2009-01-10 22:15, Użytkownik Ulf napisał:

Nawet gdyby coś takiego było to wynik będzie reprezentatywny tylko dla danego rodzaju obliczeń. Są sytuacje w których o wydajności decyduje procesor a są takie kiedy decydują inne podzespoły (pamięć, dysk). W pierwszym przypadku dostaniesz solidne przyspieszenie na szybszym procku, w drugim nie (bo wąskie gardło będzie gdzie indziej).

Przykład: Jeżeli obliczenia idą w dużej ilości kroków czasowych a każdy krok czasowy liczy się dosłownie w paru iteracjach to decydować o wydajności może dysk (zapis wyników w każdym kroku) I odwrotnie - jeżeli kolejne kroki czasowe liczą się jak krew z nosa zanim się doiterują to decydujący będzie raczej procesor.

Michał Grodecki pisze:

IMHO krytycznym moze byc ilosc pamieci RAM

Do autora watku:

- pracujemy na stacjach roboczych - w srodku po dwa dwu korowe lub czterokorowe procesory Intel Xeon - poprzednio AMD Opteron (pamiec RAM od 16 GB w gore)

Ni powiedziales w jakim programie pracujesz. Ale moze w orientacji problemu pomoze ci to:

stronach Intela znajdziesz porownanie m.in. dla MES - kliknij na linki to ci sie rozwina. Co prawda sa to dla HPC (rozproszone/rownolegle) - ale znajdziesz tez tam inne testy

Dnia 2009-01-11 00:17, Użytkownik AL napisał:

Bywa i tak. Ale to też zależy od tego czy liczymy zadanie o dużej liczbie stopni swobody raz (wtedy RAM-u trzeba od metra) czy mniejsze zadanie w wielu krokach czasowych (wtedy pamięci idzie zdecydowanie mniej).

Michał Grodecki pisze:

Jak solver jest mądrze napisany, to też bez większego znaczenia. Ileś tam lat temu zbudowałem maszynę do bardzo ciężkich obliczeń w Proe, bardzo niskim kosztem. Otóż Promechanica wszystko dzieli sobie na małe ilości danych, zapisuje je w swoich plikach (a nie w systemowej pamięci wirtualnej) bardzo elegancko tym zarządzając. Wystarczyło te pliki zapisywać na szybkim RAID0, i proszę: bardzo duża geometria wygenerowała

300 GB danych bez przerwy mielonych, ale solver leciał cały czas na 100% mocy procesora dwa tygodnie bez przerwy. I to był Barton, bez cachu 3L. Dlatego ja bym powiedział, że wszystko zależy najbardziej od softwaru- to pod konkretny program trzeba kupować sprzęt. Tylko, że w Polsce rzadko się zdarza dealer z taką wiedzą, żeby doradzić optymalne środowisko do zadania. Konrad

Konrad Anikiel pisze:

to teraz jeszcze posc to samo zadanie bez uzywania tej pamieci dyskowej (mielenia dyskiem) Dopiero wowczas porownaj rezultat i wyciagaj wnioski, gdyz czesc mocy procesora szla na obsluge tych strumieni IO na/z dysku, a to jest najwolniejsze gardlo w Twoim rozwiazaniu.

Z doswiadczenia powiem, ze dla zadan rownoleglych (na wielu komputerach jednoczesnie - cluster), zadanie tez jest dzielone przez master-node na wiele mniejszych i dystrybuowane na inne nody w clustrze. Tutaj krytycznym waskim gardlem jest predkosc sieci. Jesli to samo zadanie pozscsz jako rozproszone na jednej maszynie wieloprocesorowej - to czas obliczen drastycznie spada (nie ma potrzeby transferu zadan przez siec - krytyczne gardlo). W jednym i drugim przypadku obciazenie procesorow jest niemal caly czas maksymalne.

Powyzszy przyklad podalem jako analalogie do podanego przez Ciebie przykladu - dla Ciebie waskim gardlem bedzie wlasnie transfer z/na dysk.

(dodatkowo wspomniana przez ciebie ProMechanica wykorzystuje elementy z funkcjami ksztaltu wyzszych rzedow - model jest mniejszy przy zachowaniu tej samej dokladnosci odwzorowania geometrii (nie wiem, czy tak to mozna napisac) - sa to tzw p-elemnety (o ile dobrze pamietam). Inne systemy MES uzywaja h-elementow z funkcjami ksztaltu nizszego rzedu (czyli dla tego samego modelu bedzie ich znacznie wiecej) - a to tez ma wplyw na wilkosc modelu (zwieksza sie DOF dla modelu).

Michał Grodecki pisze:

autor nie wspomnial jak wielkie modele bedzie chce liczyc (o ileu DOF), jakich solverow bedzie chcial uzywac (iteracyjnych, czy bezposrednich), etc

a wczesniej nikt nie wspomnial o parametrze ilosci RAM - w wielu sytuacjach moze byc on bardziej krytycznym parametrem niz predkosc procesora.

AL pisze:

Ale przecież ja wiem co i po co zrobiłem. Na pojedynczym dysku kolejka IO była w perfmonie 100%, procesor 5%. Po włożeniu kontrolera RAID i kilku dysków- system się radykalnie odkorkował.

O ile software to potrafi. Pytający nie napisał co i czym chce robić, więc nie ma się co wymądrzać.

O ile to się w tym komputerze zmieści. Skąd wiesz, czy on chce robić gwoździe papiaki, czy okręty podwodne?

Jeden przypadek jest dla jednych zadań,drugi dla innych. Jak dysponujesz softem klasy Cosmos, to budujesz do niego mocną windowsową maszynę, a jak masz Comsola (żeby też było na C)- masz dużo więcej możliwości, można sobie optymalizować maszynę dla konkretnego zastosowania.

Dla tamtego komputera wąskim gardłem był procesor. Po wymianie na 30% szybszy- analiza była 30% szybsza. Skąd Ty Sherlocku wywróżyłeś że ja dokładając RAID nagle miałem problem z transferem- nie wiem...

W h-codzie masz ilość DOF-ów, w p-codzie rząd równań. Jeden grzyb, jakby któryś z nich był dużo lepszy to drugi by dawno zniknął z powierzchni ziemi.

Konrad

Konrad Anikiel pisze:

ale RAID tez ma swoja granice i nawet najszybszy kontroler nie mozna porownywac do wydajnosci z pamiecia RAM

(...)

podobnie jak Ty nie zakladalem co autor watku chce robic. Podales jeden, jedyny przyklad, maszyny ktora zkonfigurowales pod jedno zadanie.

W wiekszosci analiz bardziej krytycznym jest transport informacji z/do procesora i tutaj czas tego transportu bedzie najnizszy, jesli model "zmiesci sie" w pamieci RAM.

no i p zanika

Napisałem że w tamtym modelu solver wygenerował sobie 300 GB danych. Ile razy w życiu widziałeś komputer z taka ilością RAMu? Wyobrażasz sobie jakiś system operacyjny na codzień używany do zwyczajnych zadań będący w stanie skutecznie sobie poradzić z taką ilością danych jako ciągły kloc w pamięci? Przecież napisałem: to było tanie, specjalistyczne rozwiązanie do konkretnego zadania. I działało wyłącznie dlatego, że dobrze wiedziałem jak promechanica te dane obrabia.

To był przykład po to, żeby pokazać jak znajomość problemu może pomóc w jego realizacji. W ogólnym przypadku dowolnego programu, przy 300GB danych, musiałbyś kupować maszynę za setki tysięcy euro. Ja to zrobiłem za jakieś 1500.

Oczywiście, zgadzam się. Dlatego przy ograniczonym budżecie (a w realnym świecie budżet zawsze jest ograniczony) trzeba zacząć od dobrania najbardziej cwanego programu który sobie poradzi z zadaniem, a potem przejść do budowania sprzętu tak, żeby ten program był w stanie swobodnie swoją robotę robić. Każdy wie, że dysk jest 1000 razy wolniejszy od RAMu i jeśli system jest zbudowany niewłaściwie, to analiza będzie się rachować 1000 razy wolniej niż powinna. Natomiast jak wszystko zrobić tak, żeby szło płynnie- trzeba wiedzieć co ma być liczone. I tylko tyle chciałem powiedzieć.

Że co? Ktoś ostanio zrezygnował? Konrad

ani razu :)

Pytanie - co zawieraja te dane - gdyz program moze tworzyc sobie pewne wyniki czastkowe na dysku - na przyklad zapisuje kazdy z przeliczonych krokow czasowych, etc.

Jaki duzy byl to model, jesli "zwyczajowo" (*) mozna by przyjac, ze 1mln DOF powinien zmiescic sie w 1GB RAM (solver iteracyjny)

Przy czym kazdy solver generuje dodatkowe informacje na dysku

- przykladowo, ANSYS zaklada ze ok 10GB na 1DOF Czyli oprocz tych 1GB pamieci - tworzy sie dodatkowy plik (niezaleznie) z dodatkowymi informacjami (pominmy co dokladnie tam tworzy).

<cytat> 1) The most general guideline for ANSYS solver memory is *1 GB* per million degrees of freedom. This is true for the iterative (PCG) solvers as well as the direct sparse solver. Solver memory is the high water memory usage for ANSYS so the 1 GB per million DOFs is a good starting estimate for total ANSYS memory usage for most runs. Blocky 3-D models *using higher order elements require more memory (2x to 3X more* in the case of the sparse solver) ......

2) *I/O requirements* are the same as memory requirements for iterative solver jobs except that some analyses with multiple load steps

*may generate very large results files*. Sparse solver runs require 10 GB per million DOFs for files. This number may also grow by 2x to 3X for dense 3-D models using higher order elements. Block Lanczos analyses are among the most demanding runs in ANSYS, requiring a combination of CPU and I/O operations. ... </cytat>

dane za:

no i OK, ale po co sie rzucasz ;)

ale zakladamy, ze autor watku szuka rozwiazan optymalnych do wielu zastosowan - a nie tylko do konkretnego.

OK - racja Przy obecnej cenie RAMu i pazernosci OS (zakladam - moze blednie - ze autor bedzie korzystal z najnowszych rozwiazan (np.Vista) - co nie zawsze jest najlepsze) - nie nalezy zapominac, by procz szybkiej jednostki liczacej miec rowniez w zanadrzu odpowiedni potencjal pamieci.

a jakie systemy procz Pro-Mechanica aktywnie z tego korzystaja (czynnie jako podstawowy typ elementow) ? Przykladowo w ANSYS jest tego "az" 5 typow p-elementow (przy ilosci ok 200 typow elementow)

Mniej wiecej wiem czy sie jedne i drugie roznia (pare lat temu robilem porownanie ANSYS - ProMechanica, wiec porownania jednej i drugiej strony (w tym producentow) sa mi mniej wiecej znane).

A ja wiem co tam jest? Zrzuca w kółko na dysk pliki o wielkości porównywalnej z wielkością RAMu, ale ciągle po nich jeździ, nie tylko po ostatnim. Tamto było już jakieś 2 lata temu i w firmie dla której juz nie pracuję- nie sprawdzę.

Nie pamiętam. W p-codzie wielkości modelu nie określa się milionami DOFów, tylko ilością równań każdego rzędu.

Nie rzucam się.

Pewnie tak, ale uniwersalność może kosztować pieniądze i/lub czas. W skrajnym przypadku (co nie znaczy że odosobnionym) konstruktor zrezygnuje z jakiejś analizy lub ją zbytnio uprości, tracąc pewność że rozwiązanie jest bezpieczne.

Zgoda, wkłada się tyle ile OS/płyta da radę połknąć.

Jest trochę, nie mam czasu szukać. NAFEMS ma listę gdzieś na stronie. A widziałeś to?

a propos: Zienkiewicz zmarł 2 stycznia...

Konrad Anikiel pisze:

ten Zienkiewicz ? [']

OneiroO napisał(a):

Klasa 5.8 to nie klasa GieeSu. Jak GS to raczej 3.6. Wg PN-80/B03200 : Kl. 3.6 - wytrzymałość obliczeniowa śruby (obciążenie statyczne) 155 MPa. Kl. 5.8 - wytrzymałość obliczeniowa śruby ( obciążenie statyczne) 330 MPa.

Niestety, ten.

Konrad

snipped-for-privacy@gmail.com pisze:

Ktoś produkuje i stosuje takie badziewie ? W meblach widuje się 5.8.

Też się zdziwiłem. Ja najniższą klasę widziałem w śrubach do drewna - 4,8 i w chińskich wiertarkach stołowych - też 4,8.

Pozdrawiam

Jacek

A popatrz tu: