Biuletyn nr 4
From KDMwiki
| Biuletyn KDM |
|---|
| 1 | 2 | 3 | 4 | 5 |
| 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 |
| Lista biuletynów |
Biuletyn nr 4 (23 września 2005).
Aktualności: nowa lista dyskusyjna eFlash.Accelrys.pl
Autorzy: Magdalena Gruziel, Jacek Piechota
W czwartek, 15.09 rozpoczęła działalność nowa lista dyskusyjna eFlash.Accelrys.pl.
Lista stanowi forum wymiany informacji dla użytkowników licencji krajowej oprogramowania Accelrys. Za jej pośrednictwem dystrybuowana jest polskojęzyczna wersja biuletynu eFlash, zawierającego najnowsze informacje o produktach, szkoleniach stacjonarnych i webinariach, warsztatach itp.
Chęć otrzymania pierwszego numeru biuletynu eFlash, badź przyłączenia się do listy można wyrazić poprzez mail na adres accelrys@icm.edu.pl.
Zapraszamy!
Warsztaty "Atomistic Polymer Modeling with Materials Studio 3.2"
Autor: Jacek Piechota
W dniach 7-8 września br. odbyły się w ICM UW warsztaty: "Atomistic Polymer Modeling with Materials Studio". Celem warsztatów było zapoznanie uczestników z modelowaniem atomowym polimerów przy użyciu oprogramowania Materials Studio. Prezentowane zagadnienia dotyczyły budowania modeli polimerów i obliczania ich różnorodnych własności.
Wykłady teoretyczne były przeplatane zajęciami praktycznymi z oprogramowaniem. W warsztatach uczestniczyło w sumie 17 osob.
Wiecej informacji: http://www.icm.edu.pl/kdm/programy/ACCELRYS/polymers_2005.php
Porady: screen
Autor: Konrad Wawruch
Wstęp
Czy mieli Państwo kiedyś problem, kiedy po uruchomieniu jakiegoś programu chcieli jednocześnie podejrzeć zawartość pliku z wynikami częściowymi? Albo, w trakcie kompilacji programu, poczytać na tym samym komputerze dalszą instrukcję instalacji, w międzyczasie mając uruchomiony program pocztowy? Zapewne tak. Istnieje trywialne rozwiązanie tego problemu -- uruchomienie kolejnego okna z kolejnym połączeniem ssh z komputerem, na którym zdalnie pracujemy.
A co w sytuacji kompilacji dużego pakietu oprogramowania, kiedy łącze
sieciowe, z którym pracujemy, zrywa często połączenie, przerywając
kompilację oraz powodując konieczność ponownego ustawiania zmiennych
środowiskowych? Ponownie można szukać obejść problemu, na przykład
poprzez użycie programu nohup oraz zapamiętywanie
ustawień środowiska, ale komfort pracy na tym ucierpi. Nawet w
przypadku mało awaryjnego łącza, chcąc kontynuować pracę następnego
dnia, możemy stracić czas na ponowne logowanie się, konfigurację
środowiska itp.
Innym i często wygodniejszym rozwiązaniem wszystkich tych problemów
(oraz wielu innych) jest program screen, pozwalający na
zwielokrotnienie terminali w jednym oknie.
Zastrzeżenia
Program screen jest potężnym narzędziem. Niewłaściwie
używany, może doprowadzić do problemów. Przykładowo, jeśli uruchomimy
pod screen program mający wycieki pamięci (np. program
pocztowy z błędami), program taki uruchomiony przez wiele tygodni czy
wręcz miesięcy może doprowadzić do problemów z wolną pamięcią na
serwerze.
Z tego powodu prosimy o rozważne używanie programu. Jego użycie bezpośrednio na Cray X1 (tornado) jest zabronione (można oczywiście mieć go uruchomionego np. na delcie z wieloma utrzymywanymi połączeniami z tornado).
Podstawowe użycie
Aby użyć programu screen wystarczy w linii komend wydać
polecenie:
# screen
W jego rezultacie stanie się... nic. To znaczy, na pierwszy rzut oka
nic. Ponownie mamy dostępny znak zachęty i możemy kontynuować pracę
dokładnie tak samo, jak poprzednio (na niektórych komputerach pojawi
się najpierw ekran powitalny screen, wystarczy nacisnąć
spację lub enter, aby zniknął). Czy na pewno dokładnie tak samo jak poprzednio?
Spróbujmy napisać w linii komend cokolwiek, a następnie przenieść
kursor na początek napisu (jednoczesne naciśnięcie Control-a, dalej
będziemy używać skrótu C-a). Efekt? Nie dzieje się niestety nic.
Standardowo sekwencja C-a jest sekwencją wywołującą polecenia
programu screen. Z tego powodu standardowe działanie C-a
zostało anulowane. Chcąc mimo wszystko, zamiast umożliwić wywoływanie
poleceń screen, przejść na początek wiersza, trzeba po
sekwencji C-a nacisnąć ponownie a (taka sekwencja jest zapisywana jako
C-a a).
Czyli możemy pracować prawie tak jak poprzednio. Gdzie zatem są zalety?
Wydajmy jakiekolwiek polecenie, na przykład ls -l.
Zamknijmy okno w którym uruchomiliśmy screen. Otwórzmy
nowe okno oraz, jeśli pracowaliśmy na zdalnym komputerze, zalogujmy
się ponownie na niego. Wydajmy polecenie screen -D
-R. Efekt? otrzymaliśmy zawartość terminala w stanie dokładnie
takim samym, jak przed jego zamknięciem. Parametr -R (jak
Reattach) powoduje ponowne podłączenie się do już wcześniej
uruchomionej instancji programu screen. Parametr
-D (jak Detach) powoduje, w przypadku gdyby komputer
zdalny nadal myślał, że nie zamknęliśmy poprzedniego połączenia,
wymuszenie jego odłączenia.
Do eleganckiego rozłączania się, kiedy chcemy przerwać pracę, służy sekwencja C-a d, jak detach.
Jesteśmy zatem w stanie wyeliminować użycie programu
nohup oraz zapamiętywanie stanu środowiska w celu
zapewnienia wygodnej pracy z przerwami.
Ale co z wieloma terminalami?
W pierwszym akapicie artykułu napisałem, że screen
umożliwia zwielokratnianie terminali. Jak to zrobić?
Mając uruchomiony program screen, naciśnijmy sekwencję
klawiszy C-a c. Zawartość ekranu zostanie zastąpiona nowym terminalem,
identycznym jak byśmy uzyskali otwierając nowe okno terminala.
Jak się poruszać między poszczególnymi terminalami? Najprościej używać sekwencji C-a n (jak next) oraz C-a p (jak previous). Możemy też się odwoływać do numerów terminali poprzez sekwencję C-a i, gdzie i jest cyfrą z zakresu od 0 do 9.
W jaki sposób zamknąć jeden z terminali? Można to zrobić standardowo,
pisząc logout lub naciskając C-d. Jeśli w danym terminalu
zablokował się jakiś program, możemy zabić dany terminal zaciskając
sekwencję C-a k oraz potwierdzając nasz zamiar (klawisz y).
Uruchommy kilka dodatkowych terminali i wywołajmy następnie sekwencję C-a ". Na ekranie powinniśmy uzyskać coś podobnego do poniższego zrzutu:
Num Name Flags 0 tcsh 1 tcsh 3 tcsh
Jest to spis wszystkich okien, po którym możemy się poruszać klawiszami kursora (wybór zatwierdzamy klawiszem enter). Niestety nazwy, jak widać, nie są znaczące (standardowo jest to nazwa głównego procesu, czyli powłoki). Możemy te nazwy zmieniać -- będąc w danym terminalu, wystarczy nacisnąć C-a A, zmienić nazwę okna i zatwierdzić zmianę naciskając enter.
Jeśli mamy uruchomionych jednocześnie kilka instancji
screen, przy próbie podłączenia możemy uzyskać ekran:
[kwaw@localhost ~]> screen -r -d
There are screens on:
243.pts-0.localhost (Attached)
1325.pts-14.localhost (Attached)
1332.pts-2.localhost (Attached)
18160.pts-46.localhost (Attached)
Type "screen [-d] -r [pid.]tty.host" to resume one of them.
Zgodnie z napisem, musimy wybrać identyfikator instancji
screen.
Czy to już wszystko?
Strona pomocy do screen ma kilkadziesiąt stron -- program
ten ma olbrzymie możliwości.
Można, na przykład, przy wywołaniu screen, uruchomić od
razu konkretne programy. Można przedefiniować sekwencję dającą dostęp
do poleceń screen -- ja na przykład używam sekwencji C-v
(uruchomienie programu poprzez screen -e^vv).
Poniżej wymieniono opcje, które mogą być najszybciej
przydatne. Szczegółowy ich opis znajduje się w pomocy (man screen):
- C-a w -- pokazanie miniaturowej listy terminali;
- C-a [, C-a ] -- wejście do trybu kopiowania, wklejenie tekstu;
- C-a h -- zapisanie zrzutu ekranu do katalogu
hardcopy.N, gdzie N to numer terminala; - C-a H -- włączanie/wyłączanie logowania terminala do pliku
screen-log.N, gdzie N to numer terminala; - C-a _, C-a M -- rozpoczęcie i zakończenie monitorowania bezczynności w danym terminalu (bezczynność to brak zmian przez 30s), użyteczne jeśli np. czekamy
na zakończenie kompilacji.
Często zadawane pytania
Q1: Czy mogę personalizować konfigurację screen tak, abym nie musiał podawać wielu opcji przy każdorazowym uruchomieniu programu?
A1: Tak. Służy do tego plik ~/.screenrc.
Q2: Po restarcie komputera na którym miałem uruchomiony screen nie mogę podłączyć się do pozostawionych terminali.
A2: Niestety screen nie jest w stanie zachować pracy programów i terminali po restarcie. Co więcej, często trzeba posprzątać poprzez w
ywołanie screen -wipe.
Q3: Czym się różnią opcje -r oraz -R?
A3: Jeśli mamy wiele instancji screen, przy użyciu opcji -R podłączymy się do pierwszej dostępnej instancji (w przypadku jej braku, tworzy
nową instancję), -r wymaga podania w takiej sytuacji o którą konkretnie instancję nam chodzi.
Q4: Czym się różnią opcje -d oraz -D?
A4: Znaczenie tych opcji jest różne dopiero w połączeniu z opcjami -r oraz -R (istnieje też opcja -RR, występująca tylko w połączeniu z -d lub -D). Dokł adny opis znajduje się w pomocy, generalnie im więcej dużych liter, tym bardziej wymuszamy sukces działania.
Programowanie: Co-Array Fortran
Autor: Michał Łopuszyński
Wstęp
Co-Array Fortran (CAF) jest jednym z prostszych i efektywniejszych narzędzi do zrównoleglania kodu. Jest to niewielkie, a dzięki temu również łatwe do opanowania, rozszerzenie standardu F95. Mimo stosunkowo małej liczby nowych cech, CAF pozwala na bardzo intuicyjne i łatwe tworzenie wydajnych programów. Dlatego też dokładniejszą prezentację technik zrównoleglania kodu rozpoczynamy właśnie od tego narzędzia.
Do podziału pracy między różne CPU służy w CAF kilka nowych w porównaniu ze standardem F95 funkcji wbudowanych (tzw. intrinsic) i możliwość deklarowania tzw. co-arrays (współtablic). Najważniejsze elementy niezbędne do pisania/zrównoleglania prostych programów zostaną dokładniej opisane poniżej.
Który mamy procesor? Funkcje THIS_IMAGE() i NUM_IMAGES()
Aby zrozumieć działanie funkcji THIS_IMAGE() i NUM_IMAGES()
należy uświadomić sobie, że w filozofii CAF każdy z wykorzystanych procesorów wykonuje kopię dokładnie tego samego
programu. Jeżeli więc mamy w jakiś sposób podzielić pracę między różne CPU musimy mieć możliwość
odczytania, numeru procesora na którym nasz program pracuje.
Służą do tego właśnie funkcje THIS_IMAGE() i NUM_IMAGES().
Zwracają one liczbę typu INTEGER odpowiednio z numerem CPU
(lub inaczej numerem obrazu, jak to się przyjęło nazywać w terminologii CAF) i
liczbą wszystkich dostępnych obrazów.
Np. prosty programik przykładowy:
PROGRAM WITAJ
WRITE (*,*) 'Witaj swiecie od procesora ', THIS_IMAGE(), ' z ', NUM_IMAGES(),'!'
END
po uruchomieniu na trzech procesorach da w wyniku:
Witaj swiecie od procesora 1 z 3 ! Witaj swiecie od procesora 3 z 3 ! Witaj swiecie od procesora 2 z 3 !
Warto zauważyć, że kolejność pojawiania się napisów jest losowa i może być inna dla każdego uruchomienia programu.
Co to są współtablice (co-arrays)? Komunikacja
Możliwość wykorzystania różnych procesorów do różnych celów
w zależności od wartości zwróconej przez funkcję THIS_IMAGE()
to jeszcze nie wszystko. Do efektywnego pisania równoległych
programów potrzebujemy dodatkowo możliwości wymiany danych między
obrazami.
W CAF każdy procesor ma do dyspozycji własne "prywatne kopie" wszystkich
zmiennych. Znaczy to, że zmiana wartości pewnej zmiennej A na
jednym z procesorów NIE będzie widoczna dla pozostałych CPU.
Zmienne, których wartości chcemy udostępnić innym procesorom w CAF
powinny być deklarowane jako tzw. współtablice (co-arrays).
Robi się to w następujący sposób:
INTEGER A[*]
Po takiej deklaracji umieszczenie w programie linijki:
I=A[5]
spowoduje, że I otrzyma wartość zmiennej
A z piątego procesora. Naturalnie opuszczenie nawiasów tzn.
I=A
oznacza, że każdy CPU przypisze I swoją własną wartość
zmiennej A (inaczej można to też zapisać jako
I=A[THIS_IMAGE()]).
Przy pomocy współtablic możemy zarówno odczytywać dane z innych procesorów, jak i wpisywać nowe wartości do nich.
Synchronizacja działań - klucz do sukcesu
Wydawałoby się, że możliwość ustalenia numeru procesora w połączeniu z mechanizmem wymiany informacji to już wszystkie składniki potrzebne do napisania sprawnego programu równoległego. Tak jednak nie jest...
Należy pamiętać, że na każdym CPU program wykonuje się zupełnie niezależnie, w szczególności nie ma gwarancji, że instrukcje przetwarzane są we wszystkich obrazach z idealnie taką samą szybkością. Tak nie jest nawet w przypadku fizycznie identycznych procesorów (w grę wchodzą tu różne czynniki od sprzętowych po programowe związane np. z funkcjonowaniem systemu operacyjnego).
Przykładowo pisząc:
I=A[5]
powinniśmy być pewni, że procesor 5 już obliczył wartość zmiennej
A, o którą nam chodzi. To, że w kodzie naszego programu obliczenie
to znajduje się wcześniej niż powyższe przypisanie
wcale niczego nie gwarantuje! Procesor numer 5 mógł z jakichś
przyczyn utknąć we wcześniejszych partiach kodu i jeszcze w ogóle
do obliczania A nie dotrzeć!!!
Najprostszym sposobem zabezpieczenia się przed takimi
sytuacjami jest wywołanie SYNC_ALL().
Procedura ta gwarantuje, że powrót z niej nastąpi dopiero,
gdy wszystkie obrazy zakończą swoje operacje na współtablicach,
występujące w kodzie źródłowym programu przed jej wywołaniem.
Dodatkowo jako argument możemy podać numer obrazu (lub nawet całą tablicę takich numerów), co ograniczy oczekiwanie tylko do wymienionych procesorów. I tak np.
CALL SYNC_ALL(5) I=A[5]
gwarantuje, że zmienna I we wszystkich obrazach otrzyma
wartość obliczoną wcześniej przez procesor 5.
No dobrze, ale jak to wszystko wykorzystać? Prosty przykład
Oczywiście zebrane powyżej informacje nie wyczerpują całości standardu CAF, jednak w zupełności wystarczają do tworzenia własnych programów równoległych. Aby się o tym przekonać artykuł zakończymy prostym przykładem.
Nasz program będzie obliczał przybliżenie liczby pi korzystając ze wzoru:
i całkowania numerycznego metodą prostokątów. Wersja szeregowa programu może wyglądać na przykład tak (pi_serial.f90):
PROGRAM COMPUTE_PI_SERIAL
DOUBLE PRECISION :: PI, SUM, X, W
WRITE(6,*) 'Enter nuber of intervals';
READ(5,*) N
WRITE(6,*) 'Number of intervals = ',N
W = 1.D0/N;
SUM = 0.D0
DO I= 1,N ! Główna pętla.
X = W * (I - 0.5D0); ! Tę część pracy trzeba podzielić między procesory.
SUM = SUM + 4.D0/(1.D0+X*X) !
ENDDO
PI = W * SUM
WRITE(6,*) 'COMPUTED PI = ', PI
END
A jak przygotować wersję równoległą? Zasadnicza część pracy programu
znajduje się w pętli obliczającej wartość zmiennej SUM.
Najprostszym spospobem zrównoleglenia jest podzielenie sumowania na części
i obliczenie każdej z nich na innym CPU. Potem pozostaje już tylko
połączenie zebranych wyników. Oto przykładowa realizacja tego pomysłu
w CAF (pi_parallel.f90):
PROGRAM COMPUTE_PI_PARALLEL
DOUBLE PRECISION :: MYPI[*], PI,PSUM,X,W
INTEGER :: N[*], ME,NIMG,I
NIMG = NUM_IMAGES()
ME = THIS_IMAGE()
IF (ME==1) THEN ! Tylko procesor 1 realizuje:
WRITE(6,*) 'Enter number of intervals' !
READ(5,*) N ! * wczytanie danych wejściowych,
WRITE(6,*) 'Number of intervals= ',N !
DO I=2,NIMG ! * rozesłanie ich to wszystkich obrazów.
N[I] = N !
ENDDO !
ENDIF
CALL SYNC_ALL(1) ! Tu trzeba poczekać aż procesor 1 skończy
! przygotowywać dane wejściowe.
W = 1.D0/N ! Wszystkie procesory obliczają
PSUM = 0.D0 ! swoje sumy częściowe.
DO I= ME,N,NIMG !
X = W * (I - 0.5D0); !
PSUM = PSUM + 4.D0/(1.D0+X*X) !
ENDDO !
MYPI = W * PSUM
CALL SYNC_ALL() ! Znowu trzeba poczekać aż wszystkie CPU skończą
! obliczenia, wtedy będzie można zebrać wyniki.
IF (ME==1) THEN ! Tylko procesor 1 realizuje:
PI = 0.D0 !
DO I=1,NIMG ! * połączenie sum częściowych,
PI = PI + MYPI[I] !
ENDDO !
WRITE(6,*) 'COMPUTED PI = ',PI ! * wypisanie wyniku.
ENDIF !
END
Jak i gdzie mogę uruchomić mój program w CAF? Technikalia
W ICM w CAF można programować na komputerze tornado (Cray X1). Poniżej podamy kilka wskazówek, jak kompilować i uruchamiać programy właśnie na tej maszynie. Oczywiście za przykład posłuży nam programik pi_parallel.f90 z poprzedniego paragrafu.
Na początku na pewno będziemy chcieli zacząć od kompilacji. Ze względu na specyfikę Cray'a X1 kompilacja jest możliwa tylko w specjalnie do tego przeznaczonym katalogu /cpes/. Należy tam utworzyć swój własny podkatalog, gdzie zostanie nagrany program pi_parallel.f90. Kompilację uruchamiamy przez:
ftn -Z -Ossp -opi_parallel pi_parallel.f90
Otrzymany plik binarny pi_parallel należy przenieść w jakieś sensowne miejsce np. do katalogu domowego lub katalogu /tmp1/. Trzymanie niewykorzystywanych plików na /cpes/ nie jest mile widziane, gdyż zajmują one niepotrzebne miejsce na tym systemie plików.
Następnie uruchamiamy (dla przykładu na trzech procesorach):
aprun -n3 ./pi_parallel
w wyniku powinniśmy dostać:
Enter number of intervals 10 Number of intervals= 10 COMPUTED PI = 3.1424259850010983
Jeśli tornado jest akurat obciążone (lub kiedy zażądamy dużej liczby procesorów) może okazać się, że nasze zadanie musi poczekać na wolne zasoby. Nie należy się więc niepokoić jeśli po wpisaniu komendy aprun przez jakiś czas nic się nie będzie działo. Oczywiście duże programy obliczeniowe napisane w CAF należy uruchamiać jedynie za pośrednictwem systemu kolejkowego.
Zamiast podsumowania
W powyższym artykule zostały opisane podstawy programowania równoległego w Co-Array Fortranie. Oczywiście na pewno nie udało nam się wyczerpać tego obszernego tematu. Czytelników zainteresowanych dodatkowymi informacjami zachęcamy do zapoznania się z następującymi odnośnikami:
- Strona standardu Co-Array Fortran
- Artykuł o CAF w biuletynie AHPCRC, str. 3-12
- Konkurencyjny tutorial o CAF (po polsku)
- Dokumentacja do kompilatora Fortranu na X1 z dokładnym opisem CAF na str. 143-159
- Artykuł opisujący standard CAF
Porady: systemy kolejkowe w ICM
Autor: Maciek Cytowski
Wstęp
Na komputerach obliczeniowych w ICM istnieje obowiązek korzystania z systemów kolejkowych.
Z jednej strony obowiązek taki może wydawać się uciążliwy i niemiły: przed każdym uruchomieniem
aplikacji musimy zadeklarować liczbę procesorów, czas obliczeń, niezbędne zasoby pamięci. Ponadto
niekiedy musimy odczekać trochę czasu (lub trochę więcej) zanim system kolejkowy udostępni nam wymagane
zasoby, a przy naszym zadaniu po wydaniu polecenia qstat ujrzymy długo oczekiwaną literkę R (co oznacza, że nasze zadanie zostało już uruchomione).
Z drugiej jednak strony dobrze skonfigurowany system kolejkowy jest narzędziem, które potrafi sprawiedliwie rozdzielać zasoby obliczeniowe pomiędzy użytkownikami komputerów. Systemy kolejkowe są również przyjaznym narzędziem: po wstawieniu zadania obliczeniowego do kolejki możemy zająć się innymi pracami, a o zakończeniu obliczeń system kolejkowy powiadomi nas e-mail'em.
Schemat działania systemu kolejkowego
Umowny schemat działania systemu kolejkowego zaprezentowano na Rys.1. Menedżer zasobów wydaje polecenia do uruchomienia obliczeń po konsultacji ze "scheduler'em". Scheduler to program, który gromadzi informacje o aktualnej zajętości zasobów obliczeniowych i na podstawie zdefiniowanych przez użytkownika wymagań ustala plan obliczeń. Dlatego właśnie niezmiernie istotne dla poprawności działania systemu kolejkowego jest możliwie jak najdokładniejsze określanie zasobów, których używają uruchamiane przez nas aplikacje.
Na przykład na klastrze halo dostępna jest kolejka halo_1n_24h. Załóżmy, że wiemy, iż nasze
zadanie będzie liczyło się krócej niż 24h. Czy opłaca się zatem dokładnie określić czas obliczeń jeśli
nasze zadanie i tak trafi do tej samej kolejki halo_1n_24h?
Oczywiście, że tak. Scheduler wyznacza plan obliczeń na podstawie wymagań przez nas
określonych. Im dokładniejszą informację na temat zajętości zasobów w najbliższym czasie posiada scheduler, tym jakość planu obliczeń jest lepsza. Należy również pamiętać, iż plan obliczeń dotyczy nie tylko nas, ale również innych użytkowników.
Komendy systemów kolejkowych - wstęp
Jednym z najpopularniejszych systemów kolejkowych jest PBS (Portable Batch System). W ICM jest on w róznych wersjach zainstalowany na komputerach tornado, halo oraz latimeria. Jedynie komputer tajfun obsługiwany jest przez inny system, NQE firmy Cray. Na szczęscie zarówno z systemem PBS, jak i NQE komunikujemy się za pomocą tych samych poleceń. Najważniejsze z nich to:
- qsub - wstawianie zadania do kolejki
- qstat - sprawdzanie statusu zadania wstawionego do kolejki
- qdel - usuwanie zadania z kolejki
- qalter - zmiana parametrów zadania
Opcje i użycie komend qstat, qdel oraz qalter jest bardzo podobne w systemach PBS i NQE. Opcje polecenia qsub różnią się jednak w zależności od systemu, a przede wszystkim architektury używanego komputera.
Wstawianie zadań do kolejki - polecenie qsub
Polecenie qsub służy do wstawiania zadań do systemu kolejkowego. Wszystkie flagi, które można wyspecyfikować w tym poleceniu, alternatywnie podaje się w pierwszym bloku komentarza skryptu kolejkowego w liniach zaczynających się od "#PBS" w przypadku systemu PBS lub "#QSUB" w przypadku NQE. Niektóre opcje tego polecenia są specyficzne dla danego komputera. Chodzi tu głównie o opcje określające zasoby niezbędne do wykonania zadania. Istnieją również opcje wspólne dla wszystkich komputerów. Najważniejsze z nich zostaną zaprezentowane w tabeli:
| Opcja | Znaczenie |
|---|---|
| -l walltime | Maksymalna długość działania zadania od momentu jego uruchomienia. |
| -a date_time | Deklaruje czas, przed którym zadanie nie może zostać uruchomione. Format argumentu - [[[[CC]YY]MM]DD]hhmm[.SS], np. qsub -a 02011200 oznacza drugiego lutego w południe. |
| -h | Wprowadza zadanie w stan 'hold' (uruchomienie wstrzymane na życzenie użytkownika). |
| -I | Wykonuje zadanie interaktywnie, tzn. stdin, out i err pozostają skierowane na konsolę użytkownika w celu umożliwienia interakcji. |
| -m mail_options | Definiuje, w jakich przypadkach wysyłany jest mail do właściciela zadania. Możliwe argumenty: e - zadanie skończyło się wykonywać, b - zadanie zaczęło się wykonywać, a - wykonywanie zadania zostało przerwane przez system kolejkowania. |
| -M user_list | Lista użytkowników, do których ewenetualne maile będą wysyłane. Format argumentu: user[@host][,user[@host],...]. Default - właściciel zadania. |
| -n name | Ustawia identyfikator zadania (max. 15 znaków), Default - nazwa skryptu dostarczonego komendzie qsub. Pod taką nazwą będzie widziane zadanie w systemie (np. qstat) oraz taki początek będą też miały pliki wynikowe, tj. test.eXXX oraz test.oXXX, gdzie XXX to numer zadania jaki przydzielił system kolejkowy. |
| -S path_list | Specyfikuje powłokę, która zostanie użyta do uruchomienia zadania. |
| -q destination | Definiuje kolejkę, do której skierowane zostanie zadanie. |
Określanie zasobów na halo
Poniższy przykładowy skrypt prezentuje sposób określania zasobów na komputerze halo:
#PBS -l cput=5:00 #PBS -l mem=128mb #PBS -l file=32mb #PBS -l nodes=2:ppn=2 cd /tmp1/user/ mpiexec -transform-hostname=s/^n/a/ ./program arg1 arg2
Objaśnienie opcji użytych w powyższym przykładzie:
- -l cput=5:00 (5 min) limit czasu cpu, czyli czas zegarowy * liczba zajętych procesorów.
- -l mem=128mb limit pamięci operacyjnej.
- -l file=32mb limit pamięci dyskowej. Tyle pamięci system kolejkowy zarezerwuje nam na
dyskach tmp.
- -l nodes=2:ppn=2 dla zadań równoległych określa się na ilu węzłach i procesorach zadanie może się wykonywać. W tym wypadku chcemy uruchomić zadanie na 4 procesorach (tzn. rezerwujemy sobie 2 węzły poleceniem nodes=2, a na każdym z nich po 2 procesory poleceniem ppn=2)
Przekroczenie któregokolwiek limitu określonego opcją -l powoduje zatrzymanie zadania.
W skryptach kolejkowych do uruchamiania zadań wieloprocesorowych na halo powinno się używać programu mpiexec (np. tak jak w przykładowym skrypcie). Program mpiexec uruchamia procesy informując o tym system kolejkowania, który jest w stanie je monitorować i raportować o wszelkich problemach. Jeżeli zadanie działa uruchomione za pomocą mpirun, a przekracza wyspecyfikowane zasoby przy mpiexec, oznacza to, że w obydwu przypadkach zadanie je przekracza, tylko przy mpirun system kolejkowy nie jest w stanie tego stwierdzić. Więcej wyjaśnień dotyczących celowości podmiany mpirun na mpiexec można znaleźć na stronie FAQ.
Określanie zasobów na tornado
Ze względu na architekturę systemu możliwe jest specyfikowanie zasobów na dwa sposoby: albo pod względem ilości wymaganych MSPs (czyli SSPs razy cztery z gwarancją otrzymania w całości wolnych MSPs), albo pod względem wymaganych SSPs (czyli pojedynczych SSPs rozproszonych pomiędzy dostępnymi MSPs). W obu przypadkach kluczową rolę odgrywa parametr cput okreslający całkowity czas wykonywania zadania. Przy jego kalkulacji waga procesu w trybie MSP jest cztery razy większa niż waga zadania w trybie SSP, czyli kalkulacja przebiega według wzoru: 4*(suma czasów dla każdego wykorzystywanego MSP)+(suma czasów dla każdego wykorzystywanego SSP). Oznacza to, że X godzin cput może oznaczać zarówno X/4 sumy czasów cpu MSPs lub X sumy czasów SSPs. Z powyższego wynikają następujące wnioski:
- przydzielenie jednego MSP z punktu widzenia systemu kolejkowania oznacza przydzielenie 4 SSPs na jednym MSP
- przydzielenie czterech SSPs z punktu widzenia kolejkowania nie oznacza przydzielenia jednego MSP, gdyż SSPs
znajdują się w rożnych MSP's (choć oczywiście możliwe jest, że przypadkowo będą w obrębie jednego MSP)
- całkowity czas zadania (cput) liczony jest według wzoru 4*(suma czasów procesów w trybie MSP)+(suma czasów
procesów w trybie SSP)
Poniżej zamieszczone są dwa przykłady określania zasobów na komputerze tornado. Pierwszy z nich prezentuje jak zadeklarować chęć użycia kilku procesorów SSP:
#!/bin/csh #PBS -l mppssp=8 #PBS -l cput=24:00:00 cd /tmpx/workdir echo "Starting program at " `date` mpirun -n 8 ./program arg1 arg2 echo "Finished at " `date`
Oznacza to, że zadanie to może użyć maksymalnie 8 procesów SSP (-l mppssp=8), a suma czasu wszystkich procesów w zadaniu może wynieść maksimum 24 godziny (-l cput=24:00:00), gdzie czas wykorzystany to suma czasów procesów w trybie SSP.
Drugi przykład prezentuje sposób zadeklarowania chęci użycia kilku procesorów MSP:
#!/bin/csh #PBS -l mppe=2 #PBS -l cput=24:00:00 cd /tmpx/workdir echo "Starting program at " `date` mpirun -n 2 ./program echo "Finished at " `date`
Oznacza to, że zadanie o nazwie test_msp (-N test_msp) może użyć maksymalnie dwa procesory MSP (-l mppe=2), a suma czasu wszystkich procesów w zadaniu może wynieść maksimum 24 godziny (-l cput=24:00:00), gdzie czas wykorzystany to 4*(suma czasu procesów w trybie MSP).
Należy unikać łączenia limitów -l mppe oraz -l mppssp w jednym skrypcie. System kolejkowy PBS Pro na tornado nie potrafi skutecznie kontrolować tak określanych zadań.
Określanie zasobów na latimerii
Na komputerze latimeria konieczne jest określanie limitów na pamięć, czas oraz liczbę procesorów, których nie przekroczy nasze zadanie. Zadania równoległe mogą korzystać maksymalnie z 4 procesorów. Oto przykładowy skrypt wstawiający zadanie do kolejki na komputerze latimeria:
#!/bin/csh #PBS -l cput=5:00 #PBS -l mem=128mb #PBS -l ncpus=1 cd /tmp1/user/ ./program arg1 arg2
Powyższy skrypt deklaruje systemowi kolejkowemu, że ./program nie wykorzysta więcej niż 1 procesora i 128 megabajtów pamięci i że będzie się liczył nie więcej niż 5 minut. Dodatkowo program prezentuje jeszcze jedną istotną cechę obliczeń na komputerze latimeria. Istnieje bowiem zakaz uruchamiania obliczeń z katalogu domowego ze względu na stosunkowo wolny protokół NFS. Dlatego przed uruchomieniem zadania przechodzimy do katalogu /tmp1/user/.
Określanie zasobów na tajfunie
Przede wszystkim należy pamiętać o istotnej różnicy związanej z dyrektywami systemów kolejkowych wpisywanych w skryptach. W przypadku systemu NQE, w każdej linii poprzedzającej opcje przekazywane do programu qsub należy wpisać #QSUB, a nie #PBS tak jak w systemach PBS. Na komputerze tajfun konieczne jest określanie limitów pamięci oraz czasu, których nie przekroczy nasze zadanie. Limit procesorów obowiązujący wszystkie zadania to 4. Istnieje jednak możliwość uruchomienia krótkiego zadania testowego (do 2h) użuwającego 8 procesorów. Informację o zasobach używanych przez zadanie zwraca program ja. Oto przykładowy skrypt wstawiający zadanie do kolejki na komputerze tajfun:
#!/bin/csh #QSUB -lT 5:00 #QSUB -lM 20mb cd /tmp1/user/ ja ./program arg1 arg2 ja -st
W skrypcie tym pokazujemy, iż nasz ./program napewno nie przekroczy limitu 20mb pamięci i 5 minut czasu. Powyższe limity dotyczą całego zadania. Można również określać analogiczne limity dla procesów (-lt oraz -lm).
Przed i po uruchomieniu zadania, wypisywane są statystyki systemu kolejkowego dotyczące zasobów i sposobu ich wykorzystania (polecenie ja).
Inne polecenia systemów kolejkowych
Polecenie qstat
Polecenie qstat ma kilka zastosowań:
- sprawdzanie statusu zadania oraz danych dotyczących zarezerwowanych dla niego zasobów
- sprawdzanie zajętości komputera
- sprawdzanie limitów kolejek dostępnych w systemie (pełna lista kolejek)
Poniżej zaprezentowana jest krótka lista opcji polecenia qstat wraz z objaśnieniami działania:
- -a wypisuje skolejkowane zadania
- -f podaje pełną informację o skolejkowanych zadaniach
- -q podaje informacje o limitach kolejek
- -Q podaje informacje o zajętości kolejek
- -B podaje informacje o serwerze kolejkowania
Po wstawieniu zadania do kolejki poleceniem qsub system kolejkowy powiadamia nas o przyznanym numerze zadania (JOBID). Wykonanie polecenia:
qstat -f JOBID
zwraca nam informacje o wszystkich parametrach, które system kolejkowy przyznał naszemu zadaniu. Jeśli polecenie to wykonamy gdy nasz program został już uruchomiony, możemy między innymi sprawdzić na których węzłach/procesorach wykonywane są nasze obliczenia.
Polecenie qdel
Polecenie qdel służy do usuwania zadania z systemu kolejkowego (np. gdy zorientowaliśmy się o popełnionym w skrypcie błędzie). Składnia polecenia qdel:
qdel [-W delay] JOBID
Opcja -W pozwala ustawić przerwę pomiędzy wysłaniem sygnału SIGTERM a SIGKILL do kończonego zadania.
Polecenie qalter
Polecenie qalter służy do zmieniania parametrów skolejkowanego zadania. Oczywiście są takie zmiany parametrów , które nie są dozwolone. Jeśli próbujemy dokonać zmiany limitu zasobów potrzebnych do wykonania zadania, nie możemy przekroczyć limitów kolejki, w której aktualnie się znajdujemy. Zakazana oczywiście jest również zamiana kolejki w której znajduje się nasze zadanie. Składnia polecenia qalter jest identyczna jak w przypadku qsub, należy jedynie dodatkowo podać nazwę zadania jako ostatni argument.
Ciekawostki
Kolejka test na halo
Proszę zwrócić uwagę, że na halo dostępna jest kolejka test, która służy do uruchamiania krótkich zadań testowych (bardzo przydatna np. przy testowaniu własnego kodu). Polecenie qstat -q test zwróciło mi następującą informację o tej kolejce:
Queue Memory CPU Time Walltime Node Run Que Lm State ---------------- ------ -------- -------- ---- --- --- -- ----- test -- -- 00:15:00 2 1 0 -- E R
Oznacza to, że do tej kolejki test możemy wstawiać conajwyżej 15 minutowe zadania używające conajwyżej 2 węzłów (4 procesorów). W rzeczywistości kolejka ta ma wydzielone dla siebie dwa osobne węzły, więc czas oczekiwania na wynik testu będzie zapewne dużo mniejszy niż w innych kolejkach. Aby wstawić zadanie do kolejki test należy upewnić się, że nasze limity nie prekraczają limitów kolejki i wydać komendę:
qsub -q test ./skrypt
Wysyłanie wiadomości e-mail, czyli przyjazny system kolejkowania
Aby system kolejkowy wysłał nam wiadomość e-mail musimy powiedzieć mu kiedy ma to zrobić i na jaki adres pocztowy. W poleceniu qsub odpowiadają za to dwie opcje:
- -m mail_options - Definiuje, w jakich przypadkach wysylany jest mail do właściciela zadania. Możliwe argumenty: e - zadanie skończyło się wykonywać, b - zadanie zaczęło się wykonywać, a - wykonywanie zadania zostało przerwane przez system kolejkowania.
- -M user_list - Lista użytkowników, do których ewnetualne maile będą wysyłane. Format argumentu: user[@host][,user[@host],...]. Default - właściciel zadania.
Jeśli chcemy być poinformowani zarówno o rozpoczęciu obliczeń jak i o ich zakończeniu (szczęśliwym lub nie), a ponadto przyzwyczajeni jesteśmy do odbierania w domu wiadomości e-mail z innego serwera niż ICM-owy, to w skrypcie wstawiającym zadanie do kolejki możemy wstawić następujące linijki:
-m abe -M inne_konto@inny_serwer
O ile nasze zadanie nie będzie czekało w kolejce w nieskończoność (sprawdź popdowiedź w FAQ), to możemy się wówczas spodziewać dwóch wiadomości e-mail.
Gdzie szukać pomocy?
Systemy kolejkowe sprawiają bardzo dużo kłopotów użytkownikom komputerów ICM. Aby rozwiązać zaistaniały kłopot można korzystać z następujących pomocy:
- Użytkownicy ICM mogą korzystać z generatora skryptów kolejkowych.
- Na stronach Poradnika KDM znaleźć można dużo informacji na temat opcji poleceń qsub, qstat, qdel, qalter oraz tracejob.
- Wiele cennych porad odnaleźć można na stronach Najczęściej zadawanych pytań.
- W katalogach /opt/examples/pbs/ na maszynach obliczeniowych znaleźć można przykładowe skrypty wstawiające do kolejki obliczenia niektórych z zainstalownych w ICM oprogramowań.
- Dostępny jest adres: pomoc@icm.edu.pl, pod który można kierować wszelkie pytania związane z obliczeniami na komputerach ICM.
