|
|
|
Zlecany plik jest plikiem tekstowym, który może zawierać dyrektywy infrastruktury QCG.
Dyrektywą jest każda linia zaczynająca się od ”#QCG”.
Jeżeli w pliku nie zdefiniowano dyrektywy ”executable” ani ”application” uruchamiany jest zlecany plik z opisem zadania.
#QCG application=namd |
#QCG application=gromacs/4.6.3 |
#QCG argument=arg1 #QCG argument=arg2 |
assistant - dyrektywa umożliwiająca uruchomienie równolegle z podstawowym programem skryptu pomocniczego. Skrypt ten zakończony zostanie automatycznie z końcem zadnia.
Dyrektywa wprowadzona została w wersji 3.4 i zastąpiła dyrektywę #QCG monitor, która zmieniła znaczenie. |
Składnia:
#QCG assistant=skrypt #QCG assistant=script->skrypt |
Parametry:
script - obligatoryjny, domyślny parametr definiujący skrypt, który ma być uruchomiony. W przypadku korzystania ze skryptu musi być on przegrany dyrektywą #QCG stage-in-file.
#QCG stage-in-file=script.sh |
WAŻNE: Skrypt uruchamiany jest jednokrotnie na początku zadania. Jeżeli akcja zdefiniowana wewnątrz skryptu ma być wywoływana cyklicznie użytkownik jest odpowiedzialny za implementacje takiej funkcjonalności. |
W przypadku nie podania dyrektywy „not_before” system próbuje dokonać rezerwacji zasobów od aktualnej chwili. Dyrektywa wyklucza równoczesne użycie „not_after”.
#QCG deadline=P3DT12H |
#QCG not-before=2012.07.25 #QCG deadline=P3DT12H |
#QCG environment=name -> piontek #QCG environment=location -> poznan |
error - lokalizacja gdzie ma być przegrany standardowe wyjście błędów zadnia (stderr). Jeśli nie jest to zdalna lokalizacja zakłada się, że jest ustalana względem katalogu, z którego zlecono zadanie
#QCG error=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/errors/${JOB_ID}.error
#QCG error=error.txt
|
#QCG executable=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/executables/exec1 #QCG executable=executables/exec1 #QCG executable=executables/exec1 -> exec-file |
#QCG grant=plgpiontek_grant |
host - nazwa maszyny na której może być uruchomione zadanie, lub dokonana rezerwacja zasobów. Może być wiele takich dyrektyw dla alternatywnych maszyn.
Lista zasobów infrastruktury PL-Grid dostępnych z usług QCG. |
#QCG host=reef.man.poznan.pl #QCG host=zeus.cyfronet.pl |
#QCG include=includes/application.qcg #QCG include=/home/piontek/includes/notifications.qcg |
#QCG input=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/inputs/experiment.input #QCG input=input.txt |
#QCG memory=1024 |
#QCG memory-per-slot=512 |
#QCG module=nwchem/6.0 #QCG module=namd |
monitor - dyrektywa umożliwiająca monitorowanie stanu i postępu wykonania zadania w infrastrukturze QCG z wykorzytaniem usługi QCG-monitoring.
Dyrektywa #QCG monitor od wersji QCG 3.4 zmieniła znaczenie. Poprzednia funkcjonalność dostępna jest poprzez dyrektywę #QCG assistant. |
Składnia:
#QCG monitor[=skrypt] #QCG monitor=script->skrypt[,delay->N] |
Dla aplikacji posiadających jeden predefiniowany schemat monitorowania dyrektywa może być bezparametrowa:
#QCG monitor |
W przypadku, gdy chcemy zdefiniować konkretny schemat, lub użyć własnego skryptu monitorującego konieczne jest przekazanie parametru. Domyślnym parametrem jest parametr "script".
W przypadku korzystania z własnego skryptu monitorującego należy go zdefiniować jako plik wejściowy aplikacji dyrektywą #QCG stage-in-file. |
#QCG monitor=gaussian #QCG monitor=skrypt_monitorujący.sh #QCG stage-in-file=skrypt_monitorujący.sh |
Częstotliwość uruchamiania skryptu monitorującego definiuje parametr delay, którego wartości jest okres czasu w sekundach co jaki będzie uruchamiany skrypt. Powiadomienie wysyłane jest tylko w przypadku wykrycia zmiany od poprzedniego wysłania.
#QCG monitor=gaussian,delay->60 #QCG monitor=script->gaussian,delay->60 |
mount - dyrektywa umożliwiając automatyczne zamontowanie dla zadania określonej usługi składowania danych.
Aktualnie jedynym wspieranym systemem jest veilFS.
#QCG mount=veilfs[->katalog] |
Opcjonalny parametr katalog pozwala zdefiniować nazwę katalogu w którym ma być zamontowany system. Domyślą wartością jest "mount".
#QCG mount=veilfs->veilFS_dir |
#QCG name=nobel-experiment |
Przykład dla PBSa oznaczający dane zadanie jako wznawialne.
(-r y|n Declares whether the job is rerunable.)
#QCG native=-r n |
#QCG nodes=10:5:1 #QCG nodes=12:12 |
#QCG not-after=2012.08.25 #QCG walltime=PT2H |
#QCG not-after=2012.08.25 13:20 #QCG walltime=PT2H |
#QCG not-before=2012.07.25 #QCG walltime=PT2H |
#QCG not-before=2012.07.25 15:20 #QCG walltime=PT2H |
#QCG note=moje pierwsze zadanie QCG |
#QCG notify=mailto:piontek@man.poznan.pl #QCG notify=xmpp:tomasz.piontek@gmail.com |
W przypadku chęci otrzymywania powiadomień protokołem xmpp konieczne jest dodanie do kontaktów nadawcy: qcg-notification@plgrid.pl
#QCG output=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/outputs/${JOB_ID}.output
#QCG output=output.txt
|
parameter-sweep -dyrektywa umożliwiająca zdefiniowanie przestrzeni parametrów dla zadania. Dyrektywa może być użyta wielokrotnie definiując wielowymiarową przestrzeń parametrów. Dla każdego zestawu parametrów uruchamiane jest osobne zadanie. Dyrektywa skład się z nazwy zmiennej, która będzie przyjmować kolejne wartości oraz z definicji zmienności parametru.
#QCG parameter-sweep=VAR->PARAMETER_SPACE |
Dyrektywa dopuszcza następujące sposoby definiowania zmienności parametru:
list - wartości podane są jako lista oddzielona przecinkami
#QCG parameter-sweep=var->list:mon,tue,wed,thu,fri,sat,sun #QCG parameter-sweep=var->list:1,2,3,4,5,6 |
for - wartość wyznaczane są od wartości początkowej (start) do końcowej (end) z opcjonalnie definiowalnym krokiem (step) (domyślnie 1). Liczba miejsc po przecinku wyznaczana jest jako największa liczba cyfr po przecinku dla parametrów start, end, step.
#QCG parameter-sweep=var->for:start..end #QCG parameter-sweep=var->for:start..end..step #QCG parameter-sweep=var->for:0..10 #QCG parameter-sweep=var->for:0..10..2 #QCG parameter-sweep=var->for:1.0..2.0..0.5 |
pattern - kolejne wartości przyjmują nazwy plików zgodnych z podanym wzorcem wyszukiwanych względem katalogu, z którego zlecono zadanie.
#QCG parameter-sweep=var->pattern->*.input |
file - kolejnymi wartościami są kolejne linie pobierane z pliku
#QCG parameter-sweep=var->file:file_with_values.txt |
persistent - dyrektywa określająca że po zakończeniu zadania system ma pozostawić katalog roboczy, w którym wykonywane było zadanie.
Dyrektywa ta powinna być używana tylko na etapie testowania. Przy normalnym trybie wykonywania aplikacji dyrektywa ta nie powinna być ustawiona, gdyż powoduje, że katalog roboczy zadania nie jest usuwany i zajmuje miejsce na zasobach. Zadania zlecone jako "persistent" mogą być po zakończeniu "wyczyszczone" poleceniem qcg-clean. |
#QCG persistent |
#QCG postprocess=tar cvf wynik.tar * |
#QCG postprocess=postprocess-script.sh |
#QCG preprocess=mkdir outputs |
#QCG preprocess=preprocess-script.sh |
#QCG procs=32 |
#QCG properties=mpi,ib,lustre |
#QCG queue=plgrid |
#QCG host=reef.man.poznan.pl #QCG reservation=R1366398248299__4039 |
#QCG host=reef.man.poznan.pl #QCG reservation=piontek.0 local |
#QCG stage-in-dir=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/inputs -> inputs #QCG stage-in-dir=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/inputs #QCG stage-in-dir=input_dir -> inputs #QCG stage-in-dir=input_dir |
Skopiowanie całego katalogu w którym uruchomiony został klient odbywa się poprzez podanie ”.” (kropki) jako nazwy katalogu źródłowego i ewentualnie docelowego |
#QCG stage-in-dir=. -> . #QCG stage-in-dir=. #QCG stage-in-dir=. -> input |
W przypadku braku drugiego parametru plik kopiowany jest pod nazwę źródłową.
#QCG stage-in-file=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/inputs/input.txt -> input.txt #QCG stage-in-file=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/inputs/input.txt #QCG stage-in-file=input_file.txt -> input.txt #QCG stage-in-file=input_file.txt |
#QCG stage-out-dir=results -> gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/results/${JOB_ID}
#QCG stage-out-dir=results -> gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/results/${JOB_ID}
#QCG stage-out-dir=results -> result
#QCG stage-out-dir=results
|
Skopiowanie całego katalogu w którym wykonane było zadanie odbywa się poprzez podanie ”.” (kropki) jako nazwy katalogu źródłowego. |
#QCG stage-out-dir=. -> . #QCG stage-out-dir=. #QCG stage-out-dir=. -> output |
#QCG stage-out-file=results.txt -> gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/results/result.1
#QCG stage-out-file=results.txt
#QCG stage-out-file=result.txt -> ${JOB_ID}.result
#QCG stage-out-file=result.txt
|
#QCG use-reservation #QCG walltime=PT2H |
#QCG use-scratch |
#QCG walltime=P3DT12H |
watch-output - dyrektywa umożliwiająca monitorowanie pliku wyjściowego aplikacji i przesyłanie powiadomień z informacją.
Od wersji QCG 3.4 składnia dyrektywy #QCG watch-output uległa zmianie. |
Składnia:
#QCG watch-output=consumer->konsument,[pattern->wyrazenie | script->skrypt ,delay->N] #QCG watch-output=konsument |
Dyrektywa ma następujące parametry:
#QCG watch-output=mailto:piontek@man.poznan.pl,pattern->ENERGY,dalay->60 #QCG watch-output=consumer->mailto:piontek@man.poznan.pl,script->skrypt_monitorujacy.sh,dalay->60 #QCG stage-in-file=skrypt_monitorujacy.sh |
variable - dyrektywa pozwalająca zdefiniować zmienne w obrębie opisu zadania.
Zmienne podmienione zostaną TYLKO w obrębie dyrektyw QCG. Prosze nie mylić dyrektywy variable ze zmiennymi "systemowymi" QCG podmienianymi przez system. |
#QCG variable=PROCESSES->10
#QCG procs=${PROCESSES} |
W opisie zadania możliwe jest użycie następujących zmiennych "systemowych":
#QCG output={JOB_ID}.output
#QCG stage-out-file=file.output->file.${NOTE} |
Pliki wejściowe jak i wyjściowe dla zadań zlecanych w systemie QCG mogą znajdować się na zdalnych zasobach. Broker infrastruktury QCG zadba o ich skopiowanie na odpowiedni zasób na którym będzie wykonywane nasze zadanie, a następnie skopiuje pliki wyjściowe do wskazanych lokalizacji.
Pliki wejściowe zadania definiowane są następującymi dyrektywami:
natomiast pliki wyjściowe dyrektywami:
W obu przypadkach, jako lokalizację takich plików można podać zdalny zasób. Obsługiwane są następujące protokoły przesyłania danych:
Tak jak w przypadku plików lokalnych, definiując zdalną lokalizację plików możemy używać zmiennych opisu zadania.
W chwili obecnej obsługa protokołu HTTP/HTTPS nie wspiera katalogów oraz plików wyjściowych. |
Przy kopiowaniu plików z użycie protokołu HTTPS nie następuje autoryzacja zdalnego serwera, tzn. transmisja danych następuję szyfrowanym kanałem danych, natomiast QCG-Broker nie sprawdza i nie waliduje certyfikatu jakim posługuje się zdalny serwer. |
gridftp
gsiftp://{host}[:{port}]/{path}
gridftp://{host}[:{port}]/{path} |
gdzie:
{host} - adres maszyny na której znajduje się serwer GridFTP,
{port} - opcjonalny numer portu (domyślnie 2811),{path} - ścieżka do pliku; jeśli pierwszym znakiem ścieżki nie będzie "/" (slash), tzn. adres maszyny od ścieżki będzie oddzielał tylko jeden znak "/", wówczas ścieżka jest traktowana jako względna (względem katalogu domowego)Przykłady
gsiftp://qcg.man.poznan.pl/plik.txt gsiftp://qcg.man.poznan.pl:2811///home/plgrid/plgkopta/reef/plik.txt |
ftp
ftp://[{user}[:{pwd}]@]{host}[:{port}]/{path} |
gdzie:
{}{} - opcjonalna hasło użytkownika,{} - adres maszyny na której znajduje się serwer FTP,{} - opcjonalny numer portu (domyślnie 22),{} - ścieżka do plikuPrzykłady
ftp://ftp.kernel.org/pub/linux/kernel/v3.x/patch-3.9.gz ftp://pkopta:haslo@serwer.ftp.man.poznan.pl:22/plik.txt |
http/https
http://{host}[:{port}]/{path}
https://{host}[:{port}]/{path} |
gdzie:
{}{} - opcjonalny numer portu (domyślnie 80 dla http, oraz 443 dla https),{} - scieżka do plikuPrzykłady
https://www.kernel.org/pub/linux/kernel/v3.x/patch-3.9.gz |
irods
irods://{user}:{pwd}@{host}[:{port}]/{zone}/{path} |
gdzie:
{} - nazwa użytkownika w systemie iRods,
{} - hasło do konta w systemie iRods,
{} - adres maszyny na której znajduje się serwer iRods,
{} - opcjonalny numer portu (domyślnie 1247)
{}- parametr zone w systemie iRods,
{} - scieżka bezwzględna do pliku
Przykłady
irods://pkopta:haslo@elder12/testZone/home/pkopta/plik.txt |