Difference: ObslugaGangi (1 vs. 2)

Revision 22010-10-28 - SzymonKukulak

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

Obsluga Gangi

Wymagania wstepne

Zanim bedziemy mogli skorzystac z Gangi, musimy wiedziec (przynajmniej) dwie rzeczy: co chcemy zrobic i na czym. Odpowiedzi twierdzacej na oba pytania wolno udzielic dopiero wtedy, kiedy posiadamy dwie opcje (niekoniecznie w osobnych plikach): z selekcja DaVinci oraz z nazwami plikow (LFN/PFN) zawierajacych dane, na ktorych chcemy te selekcje przeprowadzic. Jako szablon do stworzenia opcji z selekcja moze posluzyc opcja do DaVinci Tutorial 8, ktora wystarczy odpowiedno zmodyfikowac. Natomiast opcje z LFN-ami najwygodniej jest wygenerowac przy pomocy LHCb BookKeeping.

Konfiguracja Gangi

Konfiguracja Gangi sprowadza sie do modyfikacji pliku "DaVinci_Ganga.py", ktory znajdziemy w podkatalogu "job" po zainstalowaniu najnowszej wersji DaVinci. Zazwyczaj musimy zmodyfikowac w nim nastepujace linie (w kodzie sa w roznych miejscach):

j = Job( application = DaVinci( version = 'v26r2p1' ) )
j.application.optsfile = [ File ( appOpts+'DaVinci.py' ), File(appOpts+'DC06_stripped_bbincl_lumi2.py') ]
j.splitter = SplitByFiles ( filesPerJob = 5, maxFiles = 25 )
#j.outputdata = ["stdout"]
j.merger = SmartMerger( files = ['DVNtuples.root','DVHistos.root'], ignorefailed = True )

W pierwszej podanej linii musi byc numer aktualnej wersji DaVinci (jezeli przenosimy plik ze starszej wersji do nowszej, warto pamietac o koniecznosci zmiany). W drugiej deklarujemy uzywane opcje ("DaVinci.py" mozemy zastapic jakakolwiek selekcja; potrzebna jest tez opcja z LFN-ami plikow z danymi, o ile nie zostaly zdefiniowane w poprzednim pliku; "DC06_stripped_bbincl_lumi2.py" to oczywiscie przyklad do wyrzucenia). W trzeciej podanej linii konfigurujemy splitter, ktory podzieli nasze zadanie na pewna ilosc subjobow w zaleznosci od ilosci plikow DST (oraz czynnikow losowych): ustawiamy tutaj maksymalna ilosc plikow do przeanalizowania w ogole, oraz w jednym subjobie (uwaga: rachunek, ze limit plikow rowny 50 oraz ustawienie 10 plikow na 1 subjob spowoduje podzielenie zadania na 5 subjobow, nie znajduje niestety pokrycia w faktach - w praktyce nie jestesmy w stanie okreslic, ile ich bedzie, ale zazwyczaj nie wiecej, niz dwa razy tyle, niz mialo byc). W czwartej linii specyfikujemy, czy tworzymy jakies "specjalne" pliki (np. ntuple); jezeli tak, odkomentowujemy linie i wpisujemy jego/ich nazwe/nazwy (UWAGA: trzeba USUNAC plik "stdout" z tej listy!). W piatej linii konfigurujemy mergera, ktory pliki wyjsciowe poszczegolnych subjobow (jakie pojawia sie w folderach odpowiadajacych im) poskleja w jeden: specyfikujemy, ktore pliki nas interesuja (dla powyzszego przykladu: podajemy znow nazwe pliku z ntuplem). UWAGA: Ganga moze pracowac albo w trybie lokalnym, albo na gridzie, co rowniez specyfikujemy tutaj. Wiecej o tym dwa akapity dalej.

Obsluga zadan

Kiedy mamy gotowy plik konfiguracyjny, musimy zainicjowac nasz certyfikat gridowy (o ile nie zrobilismy tego wczesniej) i uruchomic Gange:

lhcb-proxy-init
SetupProject ganga
ganga

Nastepnie w linii komend Gangi wpisujemy:

ganga DaVinci_Ganga.py

Zostaniemy poinformowani o wyslaniu zadania na grid (status "submitted") oraz ewentualnym podzieleniu na subjoby. Sprawdzac status wszystkich naszych zadan (oraz zadany dla nich backend) mozemy poprzez komende:

jobs

Aby wyswietlic szczegoly jednego z zadan (status poszczegolnych subjobow, fizyczne miejsce ich wyliczania, wszystkie ustawienia itd.), korzystamy z komendy:

jobs(nr_zadania)

Jezeli jakies zadanie wykonalo sie juz dawno temu i nie chcemy, aby nadal zasmiecalo nam liste, albo jezeli pomylilismy sie i nie ma sensu, aby wyslane/uruchomione zadanie nadal sie liczylo, wowczas mozemy je usunac komenda:

jobs(nr_zadania).remove()

UWAGA: Ta ostatnia opcja usuwa WSZYSTKIE slady pracy nad danym zadaniem, w szczegolnosci w trybie lokalnym (patrz nizej) powoduje usuniecie odpowiedniego podkatalogu w katalogu "gangadir" w naszym homie! Jezeli z jakiegos powodu pracowalismy wlasnie tam nad owocami danego zadania (ntuplami, plikami dst), albo jeszcze sie nimi nie zainteresowalismy, trzeba je stamtad koniecznie przeniesc w bezpieczne miejsce przed usunieciem danego zadania w powyzszy sposob - inaczej beda stracone!

Gdzie szukac outputu i co z nim zrobic?

Istotny jest tryb, w jakim chcemy korzystac z Gangi. Specyfikujemy go poprzez ustawienie jednej z linii w DaVinci_Ganga.py, ktora domyslnie wyglada tak:

j.backend    = Local()

Jezeli zostawimy ja w powyzszej postaci, zadania beda liczone lokalnie, zas jakikolwiek output (standardowo: log, niestandardowo: co sobie zazyczymy) zostanie zrzucony do odpowiedniego katalogu na maszynie, skad uruchomilismy Gange (szukac go nalezy w otchlaniach katalogu "gangadir" w naszym homie; logi dla pojedynczych subjobow oraz "czastkowe" pliki outputowe znajduja sie w podkatalogach oznaczonych numerami tych subjobow, natomiast output zmergowany znajduje sie pietro wyzej). Jezeli chcemy, zeby zadanie (oraz output) zamiast tego powedrowalo na grid, wowczas zmieniamy te linie na:

j.backend    = Dirac()

O ile nie popelnilismy bledu w konfiguracji (kluczowe z jakiegos powodu wydaje sie wyrzucenie "stdout" z listy outputdata) i wszystko poszlo dobrze, po policzeniu sie wszystkich subjobow zostaniemy co prawda poinformowani o bledzie mergera, ale pliki wygenerowane dla kazdego subjobu (np. ntuple) odnajdziemy na naszej przestrzeni gridowej na Castorze (o ile taka posiadamy). Dla uzytkownika "jan kowalski" mozemy tam zajrzyc z lxplusa poprzez:

nsls /castor/cern.ch/grid/lhcb/user/j/jkowalski

Kiedy znajdziemy potrzebny nam plik w drzewie katalogow (output poszczegolnych jobow oznaczony jest dlugimi numerami, ale w orientacji mozna sie wspomoc wskazowka: ilosc podkatalogow we wlasciwym katalogu odpowiada ilosci subjobow, na jakie rozbililismy dane zadanie), skopiowac go mozemy gdzies indziej poprzez komende typu:

rfcp /castr/cern.ch/grid/lhcb/user/j/jkowalski/XXXX/XXXXYY/plik.root .

Poniewaz pliki dla poszczegolnych subjobow nie sa niestety mergowane (prawdopodobnie jest to wykonalne wylacznie dla pracy w trybie lokalnym), trzeba najpierw skopiowac je wszystkie w jedno miejsce, a nastepnie zmergowac je recznie (jak to zrobic, opisuje artykul AnalizaNtuple). Jezeli mielismy np. 20 subjobow, robienie tego recznie nie ma wiele sensu - wowczas oplaca sie wspomoc skryptem shellowym:

cd#/bin/csh

setenv CASTOR_LOCATION    /castor/cern.ch/grid/lhcb/user/j/jkowalski/2010_10/12228
setenv FILE_NAME          moj_ntuple.root
setenv OUTPUT_LOCATION    /tmp/jkowalski

setenv SUBDIRS `nsls $CASTOR_LOCATION`
echo $SUBDIRS

Changed:
<
<
set itf=1
>
>
set itf=0
 foreach f ( $SUBDIRS ) setenv fin ${CASTOR_LOCATION}/${f}/$FILE_NAME
Changed:
<
<
setenv fout $OUTPUT_LOCATION/file_${itf}_${FILE_NAME}
>
>
setenv fout ${OUTPUT_LOCATION}/file_${itf}_${FILE_NAME}
  echo $fin $fout
Changed:
<
<
# rfcp $fin $fout
>
>
rfcp $fin $fout
  @ itf+=1 end

echo koniec

Uruchamiamy go w nastepujacy sposob:

source plik.csh

UWAGA: duzych plikow NIE ma sensu kopiowac na swoje konto na lxplusie, bo najpewniej przekroczymy w ten sposob astronomiczna quote 500 MB (wlasciwie: nie przekroczymy, bo nie damy rady, ale nic nie osiagniemy i niepotrzebnie utrudnimy sobie zycie). W razie braku alternatyw, najlepiej kopiowac je na przestrzen tymczasowa dostepna na lxplusie, gdzie po zalogowaniu sie tamze wchodzimy (a pozniej normalnie pracujemy) przez:

cd /tmp/jkowalski

UWAGA: Dane tam umieszczone maja tendencje do rozplywania sie w powietrzu po jakims czasie, stad najlepiej zabrac je gdzies indziej zaraz po zakonczeniu analizy. Mniejsze pliki (histogramy) mozna przeslac z powrotem na lxplusa, wieksze (ntuple) mozna archiwizowac na "zwyklej" (nie-gridowej) czesci Castora, gdzie z lxplusa mozna zajrzec na dwa sposoby:

nsls $CASTOR_HOME
nsls /castor/cern.ch/user/j/jkowalski

Kopiowanie stamtad do miejsca analizy i z powrotem przeprowadzamy w sposob analogiczny do powyzszego. Najbezpieczniej jednak pracowac w "normalnej" przestrzeni na lxplusie (zapewniajac komfort psychiczny naszym histogramom), umiesciwszy tam jedynie link do kolosa, ktory fizycznie przechowujemy w przestrzeni tymczasowej. Tworzy sie go tak (najlepiej z miejsca, gdzie chcemy, aby byl):

ln -s /tmp/jkowalski/plik.root LINK.root

Program, ktory bedzie chcial "zajrzec" do linku (np. ROOT) automatycznie siegnie tam, gdzie trzeba. Taka "podmiana" jest wygodna zwlaszcza w przypadku, jezeli wygenerowalismy cala klase do analizy okreslonego ntupla (patrz: AnalizaNtuple) i nie chcemy niepotrzebnie w niej grzebac.

-- SzymonKukulak - 27 Oct 2010

 
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