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