Konrad Anikiel pisze:
> AL 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.
>
> 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ł.
>
ale RAID tez ma swoja granice i nawet najszybszy kontroler nie mozna
porownywac do wydajnosci z pamiecia RAM

(...)
>>
>> Powyzszy przyklad podalem jako analalogie do podanego przez Ciebie
>> przykladu - dla Ciebie waskim gardlem bedzie wlasnie transfer z/na dysk.
>
> 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...
>

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.

>> (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).
>
> 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.
>
no i p zanika


--
pozdr
Adam (AL)
TG

do góry

On 12 Jan, 11:26, AL <a...@s...tam> wrote:
> Konrad Anikiel pisze:> AL 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.
>
> > 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ł.
>
> ale RAID tez ma swoja granice i nawet najszybszy kontroler nie mozna
> porownywac do wydajnosci z pamiecia RAM

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.

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

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.

>
> 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.

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ć.

> > 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.
>
> no i p zanika

Że co? Ktoś ostanio zrezygnował?
Konrad

do góry

Konrad Anikiel pisze:
> On 12 Jan, 11:26, AL <a...@s...tam> wrote:
>> Konrad Anikiel pisze:> AL 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.
>>> 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ł.
>> ale RAID tez ma swoja granice i nawet najszybszy kontroler nie mozna
>> porownywac do wydajnosci z pamiecia RAM
>
> Napisałem że w tamtym modelu solver wygenerował sobie 300 GB danych.
> Ile razy w życiu widziałeś komputer z taka ilością RAMu?

ani razu :)

> 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?

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:
http://www1.ansys.com//cgi-bin/HardwareSupport/recom
mended/recommended.html


> 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.
>
no i OK, ale po co sie rzucasz ;)

>> podobnie jak Ty nie zakladalem co autor watku chce robic.
>> Podales jeden, jedyny przyklad, maszyny ktora zkonfigurowales pod jedno
>> zadanie.
>
> 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.
>
ale zakladamy, ze autor watku szuka rozwiazan optymalnych do wielu
zastosowan - a nie tylko do konkretnego.

>> 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.
>
> 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ć.
>
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.

>>> 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.
>> no i p zanika
>
> Że co? Ktoś ostanio zrezygnował?

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).


--
pozdr
Adam (AL)
TG

do góry

On 12 Jan, 16:03, AL <a...@s...tam> wrote:

> > 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?
>
> Pytanie - co zawieraja te dane - gdyz program moze tworzyc sobie pewne
> wyniki czastkowe na dysku - na przyklad zapisuje kazdy z przeliczonych
> krokow czasowych, etc.

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ę.

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

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.

> > 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.
>
> no i OK, ale po co sie rzucasz ;)

Nie rzucam się.

>
> >> podobnie jak Ty nie zakladalem co autor watku chce robic.
> >> Podales jeden, jedyny przyklad, maszyny ktora zkonfigurowales pod jedno
> >> zadanie.
>
> > 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.
>
> ale zakladamy, ze autor watku szuka rozwiazan optymalnych do wielu
> zastosowan - a nie tylko do konkretnego.

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.

> 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.

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

>
> >>> 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.
> >> no i p zanika
>
> > Że co? Ktoś ostanio zrezygnował?
>
> a jakie systemy procz Pro-Mechanica aktywnie z tego korzystaja
> (czynnie jako podstawowy typ elementow) ?

Jest trochę, nie mam czasu szukać. NAFEMS ma listę gdzieś na stronie.
A widziałeś to? http://en.wikipedia.org/wiki/Hp-FEM
Konrad
PS a propos: Zienkiewicz zmarł 2 stycznia...

do góry

Konrad Anikiel pisze:

> PS a propos: Zienkiewicz zmarł 2 stycznia...

ten Zienkiewicz ?
[']

--
pozdr
Adam (AL)
TG

do góry

On 12 Sty, 17:55, AL <a...@s...tam> wrote:
> Konrad Anikiel pisze:
>
> > PS a propos: Zienkiewicz zmarł 2 stycznia...
>
> ten Zienkiewicz ?
> [']
>

Niestety, ten.

Konrad

do góry