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
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.
#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
#QCG monitor=monitor-script.sh
#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
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
#QCG watch-output=mailto:piontek@man.poznan.pl,20,ENERGY
#QCG stage-in-file=nft_expr_file #QCG watch-output=mailto:piontek@man.poznan.pl,30,ntf_expr_file
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:
{
user}
- opcjonalna nazwa użytkownika,{
pwd
}
- opcjonalna hasło użytkownika,{
host
}
- adres maszyny na której znajduje się serwer FTP,{
port
}
- opcjonalny numer portu (domyślnie 22),{
path
}
- ś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:
{
host}
- adres maszyny na której znajduje się serwer http/https{
port
}
- opcjonalny numer portu (domyślnie 80 dla http, oraz 443 dla https),{
path
}
- 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:
user{
}
- nazwa użytkownika w systemie iRods,
pwd{
}
- hasło do konta w systemie iRods,
host{
}
- adres maszyny na której znajduje się serwer iRods,
port{
}
- opcjonalny numer portu (domyślnie 1247)
zone{
}
- parametr zone w systemie iRods,
path{
}
- scieżka bezwzględna do pliku
Przykłady
irods://pkopta:haslo@elder12/testZone/home/pkopta/plik.txt