Tags:
create new tag
, view all tags

Podrecznik uzytkownika Proof on Demand

Uruchomienie PoD

Ustawienie srodowiska

Nalezy uruchomic skrypt bashowy inicjalizacji PoD (mozna je dodac np. do .bashrc):

source /mnt/lustre/scratch/groups/plggheplhcao/PoD/pod_ini.sh

Uruchomienie serwera PoD

UWAGA: na klastrze Zeus nalezy wystartowac PoD z sesji interakcyjnej PBS "qsub -I -X -A nazwa_grantu" aby nie obciazac UI

pod-server start

Status mozna sprawdzic komenda

pod-server status

Definiowanie liczby 'worker nodow' (WN).

Submitujemy tyle razy job z nazwa kolejki (tu l_short) ile chcemy WN miec podlaczonych do serwera PoD. Dla 4 WN i kolejki l_short uruchamiamy 4 razy

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

Czekamy az wszystkie wyslane zadania zaczna sie wykonywac. Liczbe aktywnych WN podaje komenda

pod-info -n

W zasadzie mozemy zaczac prace bez oczekiwania na uruchomienie wszystkich procesow WN. Kolejno uruchamiane WNy beda rejestrowane automatycznie na serwerze i wlaczane do procesowania danych.

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 sposobow uruchamiania zadania z wykorzystaniem danych lub tez bez. a) Zadanie, ktore nie wykorzystuje danych zewnetrznych lecz nalezy dana czynnosc wykonac 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 wystepuje pod nazwa nazwa, tytulem tytul, i jest utworzona z plikow znajdujacych sie pliku 'kr_r015577.list' w biezacym katalogu. Musimy jeszcze ustawic nazwe drzewa, z ktorego bedziemy korzystac w analizie. Robimy to metoda

mycollection->SetDefaultTreeName("ClusterKr");

gdzie jako drzewa uzylismy 'ClusterKr'.

Drugie rozwiazanie wyglad nastepujaco (uwaga: nazwe pliku nalezy podac ze sciezka bezwzgledna aby pliki byly 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 ktorej zamykane sa; wszystkie WN-y i serwer PoD. Zamkniecie sesji odbywa sie takze w przypadku braku aktywnosci interakcyjnej w czasie 0.5 h serwer.

Przyklad selektora oraz pliki z danymi znajduja sie w katalogu:

/mnt/lustre/scratch/groups/plggheplhcao/matyja/przyklad/

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();

-- MariuszWitek - 2012-10-01 -- Adam Matyja - 2012-11-04

Topic revision: r7 - 2013-09-11 - AndrzejOlszewski
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback