Views

Biuletyn nr 4

From KDMwiki

Jump to: navigation, search
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
31 | 32
Lista biuletynów

Biuletyn nr 4 (23 września 2005).

Spis treści

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:

Parser nie umiał rozpoznać (Missing texvc executable; please see math/README to configure.): \pi = 4 \int_0^1 \frac{1}{1+x^2}


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:


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.

Schemat działania systemu kolejkowego

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.