Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Poniższy szablon należy odpowiednio uzupełnić.

  • Układ należy zachować (z dopuszczeniem minimalnych modyfikacji).
  • Opis nie powinien przekraczać 10 stron przeciętnego ekranu laptopa.
  • W razie potrzeby należy założyć podstrony (na końcu z rozdziałem "Co dalej?" i odnośnikiem do kolejnego rozdziału dokumentacji).
  • Język opisu - polski. W sytuacji, gdy zasadnicza dokumentacja usługi ma być po angielsku, w tym rozdziale powinny znaleźć się podstawowe informacje pozwalające zorientować się w zaletach usługi i zgrubnie w wymaganych krokach do jej uruchomienia.
  • Uprawnienia do odczytu strony (Tools/Restrictions) mogą byś ustawione na "Confluence-users" w pisania dokumentacji, inaczej będzie widoczna od razu dla osób niezalogowanych.
  • Pytania dotyczące systemu dokumentacji: Hubert Siejkowski,
  • Pytania dotyczące Podręcznika Użytkownika: Maciej Filocha.

Krótki opis usługi

Usługa Proof on Demand (PoD) przeznaczona jest do prowadzenia końcowych analiz fizycznych HEP. Pozwala na równoległe przetwarzanie danych w środowisku ROOT wykorzystując podział danych wejściowych i ich przetwarzanie przez niezależne procesy oraz zapewnia scalanie wyjściowych wyników. W ten sposób czas przetwarzania dużych ilości danych może być skrócony o czynnik 1/n gdzie n oznacza liczbę uruchomionych procesów roboczych PoD. Aplikacja PoD składa się z serwera oraz z procesów roboczych. Podstawową metodą jest wykorzystanie procesów uruchamianych w systemie zadań wsadowych. Procesy robocze zgłaszają swoją gotowość do serwera PoD i od tego momentu mogą być wykorzystane do analizy danych.

Aktywowanie usługi

Aby móc korzystać z usługi PoD należy mieć założone konto w Portalu PL-Grid i aktywować usługi:

  1. Dostęp do klastra w ośrodku obliczeniowym (np. REEF, ZEUS)
  2. Dostęp do UI w ośrodku obliczeniowym (np. Cyfronet, ICM, PCSS)
  3. Platforma dziedzinowa HEPGrid: usługa Proof on Demand

Usługi aktywuje się w Portalu Użytkownika, zgodnie z przykładem.

Ograniczenia w korzystaniu (podsekcja opcjonalna)

Tutaj wpisujemy specjalne zasady korzystania z usługi jeśli takowe są np. konieczność ustawienia grantu domyślnego, zakaz uruchamiania intensywnych zadań na UI itp. Jeśli takowych nie ma to należy tę podsekcję usunąć.

Pierwsze kroki

Przykład dla klastra Zeus

Należy zalogować się na UI a następnie uruchomić sesję interakcyjną za pomocą komendy

qsub –I –X –l nodes=1:sl6  

Inicjalizacja PoD polega na wykonaniu skryptu konfiguracyjnego przygotowanego dla powłoki bash:

source $PLG_GROUPS_SHARED/podsoft/scripts/podini.sh

Server PoD jest uruchamiany za pomoca komendy

pod-server start

a procesy robocze uruchamiane sa za pomocą polecenia:

pod-submit -r pbs -q l_short -n 5

gdzie –n 5 oznacza żądaną liczbe procesów roboczych.Sprawdzenie aktywnych procesów roboczych pozwala polecenie:

pod-info –n

Należy pamiętać że procesy robocze uruchmiane sa jako zadania systemu PBS. Szybkość ich pojawienia się zależy od dostępności wyspecyfikowanej kolejki PBS. Status zadania można zbadac za pomocą standardowej komendy PBS „qstat –u username” (zadania PoD maja przypisana nazwe pod).

Pakiet ROOT zawiera klasę do testów pakietu PROOF. Należy uruchomić aplikacje ROOT za pomocą polecenia

root

A następnie zadeklarować obiekt do testów PROOF i uruchomić test

root[] TProofBench pb(gSystem->GetFromPipe("pod-info -c"))
root[] pb.RunCPU()

Pomyślne wykonanie testu świadczy o poprawnym działaniu PoD

Zaawansowane użycie

Uruchomienie roota
root
Powiadomienie root'a o PoD i podlaczenie PROOFA do analiz wielowatkowych:
 
TProof *p = TProof::Open("pod://")

 

Przygotowanie zadan do analizy rownoleglej

Tworzenie zadania

Aby uruchomic zadanie obslugiwane przez PROOF klasa wykonywalna musi dzedziczyc po bazowej klasie TSelector. Aby uzyskac pliki (naglowkowy i z cialem klasy) sluzace do analizy, w tym celu najprosciej skorzystac z predefinowanej komendy root'a, ktora dla danego drzewa tworzy potrzebne pliki. Jest to metoda MakeSelector.

W przykladzie ponizej otwieramy plik o nazwie 'kr_r015577_f000.root' znajdujacy sie w katalogu, w ktorym otworzylismy root'a (linia 1). Nastepnie uzyskujemy dostep do drzewa w nim zapisanego o nazwie 'ClusterKr' (linia 2). Dla danego drzewa tworzymy pliki z zadaniem o nazwie 'MySelector' (linia 3); sa to pliki MySelector.h oraz MySelector.C utworzone w katalogu, w ktorym sie znajdowalismy uruchamiajac root'a. W lini 4 listujemy te pliki.

 

TFile *f=TFile::Open(""/mnt/lustre/scratch/groups/plggheplhcao/matyja/przyklad/kr_r015577_f000.root")
TTree *t =(TTree*)f->Get("ClusterKr")
t->MakeSelector("MySelector")
.!ls MySelector*

 

Wspolpraca z plikami

Istnieje kilka sposobów uruchamiania zadania z wykorzystaniem danych lub tez bez. a) Zadanie, które nie wykorzystuje danych zewnętrznych lecz należy daną czynność wykonać n razy np.: n=1000. Wówczas uruchamiamy:

 
p->Load("MySelector.C+") 
MySelector *mysel = new MySelector(arg1, arg2)
p->Process(mysel, 1000)

lub bezposrednio:

p->Process("MySelector.C+", 1000);

b) Procesowanie na lancuchu danych (uwaga: nazwe pliku nalezy podac ze sciezka bezwzgledna aby pliki byly widoczne przez nody robocze!)

TChain chain("ClusterKr")
chain.Add("/people/plgamatyja/test_Kr/data/kr_r015577_f000.root");
chain.Add("/people/plgamatyja/test_Kr/data/kr_r015577_f001.root");
chain.Add("/people/plgamatyja/test_Kr/data/kr_r015577_f002.root");
chain.Add("/people/plgamatyja/test_Kr/data/kr_r015577_f003.root");
chain.SetProof();
chain.Process("MySelector.C+")

c) Procesowanie na kolekcji danych. Aby utworzyc kolekcje danych mamy dwa wyjscia. Albo tworzymy plik tekstowy ze sciezkami do plikow uzytych do utworzenia kolekcji przed uruchomieniem roota, albo dodajemy pliki recznie juz w root'cie. Pierwsze rozwiazanie wyglada nastepujaco:

ls `pwd`/kr*root>kr_r015577.list
root
TFileCollection *mycollection = new TFileCollection("nazwa", "tytul","kr_r015577.list")

gdzie kolekcja występuje pod nazwa nazwa, tytulem tytul, i jest utworzona z plikow znajdujacych sie pliku 'kr_r015577.list' w biezacym katalogu. Musimy jeszcze ustawić nazwę drzewa, z którego będziemy korzystać w analizie. Robimy to metoda

mycollection->SetDefaultTreeName("ClusterKr");

gdzie jako drzewa użyliśmy 'ClusterKr'.

Drugie rozwiązanie wygląda następująco (uwaga: nazwę pliku należy podać ze ścieżką bezwzględną aby pliki były widoczne przez nody robocze!):

 
TFileCollection *krypton = new TFileCollection("nazwa","tytul");
krypton->Add("/people/plgamatyja/test_Kr/data/kr_r015577_f000.root");
krypton->Add("/people/plgamatyja/test_Kr/data/kr_r015577_f001.root");
krypton->Add("/people/plgamatyja/test_Kr/data/kr_r015577_f002.root");
krypton->Add("/people/plgamatyja/test_Kr/data/kr_r015577_f003.root");

Tutaj dodajemy do kolekcji kolejne pliki metoda Add(). Pola nazy i tytulu moga byc lancuchami pustymi, tj.: "".

Procesowanie w PROOF'ie uruchamiamy podajac nazwe kolekcji lub wskaznik do niej.

p->Process("nazwa","MySelector.C+")

lub

p->Process(mycollection ,"MySelector.C+")

d) Procesowanie na zarejestrowanym zestawie danych. Aby sprawdzic jakie zestawy danych sa juz udostepnione w sesji PROOFa wpisujemy polecenie:

 
p->ShowDataSets()

W naszym przypadku dostajemy np.:

Dataset repository: /people/plgamatyja/.proof/datasets
Dataset URI                               | # Files | Default tree | # Events |   Disk   | Staged
/default/plgamatyja/krypton               |      13 | /ClusterKr   | 2.64e+07 |   681 MB |  100 %
/default/plgamatyja/new_kr                |       4 | /ClusterKr   | 8.205e+06|   210 MB |  100 %

Aby zarejestrowac zestaw danych nalezy uzyc metody RegisterDataSet("nazwa_zestawu_danych_w_PROOF",kolekcja), np.:

p->RegisterDataSet("nowa",krypton)

Taka kolekcja nie posiada jednak zarejestrowanej nazwy drzewa i liczby przypadkow. To co dostaniemy po wyswietleniu dostepnych zbiorow danych to:

Dataset repository: /people/plgamatyja/.proof/datasets
Dataset URI                               | # Files | Default tree | # Events |   Disk   | Staged
/default/plgamatyja/krypton               |      13 | /ClusterKr   | 2.64e+07 |   681 MB |  100 %
/default/plgamatyja/new_kr                |       4 | /ClusterKr   | 8.205e+06|   210 MB |  100 %
/default/plgamatyja/nowa                  |       2 |        N/A              |    95 MB |    0 %

W celu weryfikacji zbioru danych nalezy

p->VerifyDataSet("nowa")

Aby dokladnie zapoznac sie z zestawem danych uzywamy metody ShowDataSet(), np.:

p->ShowDataSet("nowa","MF")

Do usuwania predefiniowanych zestawow danych dostepnych w PROOFie sluzy:

p->RemoveDataSet("nowa")

W koncu, aby procesowac zestaw danych selektorem uruchamiamy, np.:

p->Process("nowa","MySelector.C+")

Jezeli chcemy procesowac zestaw danych, ktory jest zarejestrowany lecz nie zweryfikowany musimy ustawic opcje:

 p->SetParameter("PROOF_LookupOpt", "all")

 

Konczenie pracy

Aby zakonczyc prace wydajemy komende:

pod-server stop

po której zamykane są; wszystkie WN-y i serwer PoD. Zamknięcie sesji odbywa się także w przypadku braku aktywności interakcyjnej w czasie 0.5 h serwera.

 

Przyklad selektora oraz pliki z danymi znajduja sie w katalogu:

$PLG_GROUPS_SHARED/podsoft/example/

 

Kolejnosc uruchamiania metod w marko opartym na klasie bazowej TSelector.

Dostepne sa dwa sposoby uruchamiania makr opartych na klasie bazowej TSelector. Pierwszy jest tzw. sposobem lokalntm (standardowym, liniowym), gdzie zapytanie wykonywane jest sekwencyjnie. Kolejnosc wywolywania metod jest pokazana na grafie ponizej:

 

Begin()
SlaveBegin()
Init()
   Notify()
      Process()
      ...
      Process()
   ...
   Notify()
      Process()
      ...
      Process()
SlaveTerminate()
Terminate()

Drogi sposob to dzialania rozproszone, uwzgledniajace obliczenia rownolegle, w ktoreych uzywany jest PROOF. Na grafie ponizej pokazano, ktore metody sa wykonywane na nodzie glownym, a ktore na roboczych.

 

+++ CLIENT Session +++       +++ (n) WORKERS +++
Begin()
                             SlaveBegin()
                             Init()
                                 Notify()
                                 Process()
                                 ...
                                 Process()
                                 ...
                             Init()
                                 Notify()
                                 Process()
                                 ...
                                 Process()
                                 ...
                             SlaveTerminate()
Terminate()

Ponizej przedstawiono opis i znaczenie poszczegolnych funkcji.

 

Begin(), SlaveBegin()

Funkcja Begin() jest wolana na samym poczatku. Zawsze dziala w sesji kilenta ROOT. Funkcja SlaveBegin() jest wywolywana w sesji klienta (opcja pierwsza liniowa) lub, w przypadku analizy wielowatkowej z udzialem PROOF na kazdym z wezlow (WN). Wszystkie inicjalizacje, ktore sa potrzebne dla funkcji Process() nalezy zatem umiescic w SlaveBegin(). Kod, który potrzebuje dostępu do lokalnego środowiska klienta, np. grafiki lub systemu plików należy umieścić w Begin (). Podczas pracy z PROOFem lista wejsciowa (fInput) jest rozprowadzana do WN-ow po zakonczeniu funkcji Begin(), a przed wywolaniem SlaveBegin(). W ten sposób obiekty z kilenta staja sie dostepne dla instancji TSelector'a na nodach roboczych (WN). Argument tree jest przestarzaly. (W przypadku PROOF'a argument tree jest niedostepny na kliencie i przekazywane jest 0. Funkcja Init() powinna byc uzywana aby zaimplementowac operacje zalezne od argumentu tree.)

Sygnatura:

virtual void Begin(TTree *tree); virtual void SlaveBegin(TTree *tree);

 

Init()

Funkcja Init() jest wywolywana kiedy selektor potrzebuje inicjalizowac nowe drzewo (tree) lub lancuch (chain). Zwykle zostaja tu ustawione adresy galezi drzewa (branch addresses). Zwykle nie jest konieczne wprowadzanie zmian do automatycznie wygenerowanego kodu, lecz funkcja moze zostac rozszerzona przez uzytkownika jezeli zachodzi taka potrzeba. Funkcja Init() bedzie wywolywana wiele razy podczas pracy z PROOF'em.

Sygnatura:

virtual void Init(TTree *tree);

 

Notify()

Funkcja Notify() jest wywolywana za kazdym razem kiedy otwierany jest nowy plik. Moze to nastapic dla nowego drzewa TTree w lancuchu TChain lub kiedy nowe drzewo TTree jest wczytywane na poczatku pracy z PROOF'em. Zwykle w tym miejscu zostaja zwrocone wskazniki do galezi (branch pointers). Zwykle nie jest konieczne wprowadzanie zmian do automatycznie wygenerowanego kodu, lecz funkcja moze zostac rozszerzona przez uzytkownika jezeli zachodzi taka potrzeba.

Sygnatura:

virtual Bool_t Notify();

 

Process()

Funkcja Process() jest uruchamiana dla kazdego przypadka (entry) zapisanego w drzewie (tree) (lub mozliwego obiektu kluczowego w przypadku PROOF'a), ktore jest procesowane. Argument 'entry' tejze funcji specyfikuje, ktory przypadek w obecnie zaladowanym drzewie bedzie przeprocesowany. Moze on zostac przekazany albo TTree::GetEntry(), albo TBranch::GetEntry() aby wczytac odpowiednio wszystkie czesci danych albo tylko wymagane czesci danych. Kiedy procesowany jest obiekt kluczowy w PROOF'ie obiekt ten jest juz zaladowany i jest dostepny przez wskaznik fObject. Funkcja Process() pownna zawirac cialo calej analizy. Moze zawierac proste lub bardziej wysublimowane kryteria selekcji, algorytmy dzialania dla danego przypadku i typowo zawiera wypelnianie histogramow.

Sygnatura:

virtual Bool_t Process(Int_t entry);

 

SlaveTerminate(), Terminate()

Funkcja SlaveTerminate() zostaje wywolywana kiedy wszystkie przypadki lub obiekty zostaly przeprocesowane. Kiedy pracujemy z PROOF'em jest wykonywana przez kazdy WN. Moze zostac uzyta do post-processingu zanim czesciowe rezultaty z kazdego WN zostana polaczone (mergowane). Po zakonczeniu SlaveTerminate() obiekty z list 'fOutput' na WN'ach sa laczone przez system PROOF i zwracane do sesji klienta ROOT. Funkcja Terminate() jest ostania z uruchamianych w calym zadaniu. Zawsze jest uruchamina na kliencie ROOT'a. Moze zostac uzyta do przezentacji graficznej rezultatow lub do zapisania ich do pliku.

Sygnatura:

virtual void SlaveTerminate(); virtual void Terminate();

Ewentualnie jako osobny podrozdział.

Gdzie szukać dalszych informacji?

Strony zewnętrzne (jeśli są), odnośnik do helpdesku lub strony dokumentacji o pomocy.

Można też dodać sekcję "Co dalej?" ze wskazaniem (odnośnikiem) do dalszej części dokumentacji, o ile jest wymagana.
  • No labels