queue

• queue - wybrana kolejka systemu kolejkowego.

  Code Block
  #QCG queue=plgrid

note

• note - krótka informacja o zadaniu.

  Code Block
  #QCG note=moje pierwsze zadanie QCG

name

• name - dyrektywa określająca nazwę zadania. Nazwa zadania pojawi się jako końcówka identyfikatora zadania.

  Code Block
  #QCG name=nobel-experiment

output

• output - lokalizacja gdzie ma być przegrane standardowe wyjście zadnia (stdout). Jeśli nie jest to lokalizacja gsiftp zakłada się, że jest ustalana względem katalogu, z którego zlecono zadanie.

  Code Block
  #QCG output=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/outputs/${JOB_ID}.output #QCG output=output.txt

error

• error - lokalizacja gdzie ma być przegrany standardowe wyjście błędów zadnia (stderr). Jeśli nie jest to lokalizacja gsiftp zakłada się, że jest ustalana względem katalogu, z którego zlecono zadanie.

  Code Block
  #QCG error=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/errors/${JOB_ID}.error #QCG error=error.txt

input

• input - lokalizacja skąd ma być wzięte standardowe wejście dla aplikacji (stdin). Jeśli nie jest to lokalizacja gsiftp zakłada się, że jest ustalana względem katalogu, z którego zlecono zadanie.

  Code Block
  #QCG input=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/inputs/experiment.input #QCG input=input.txt

host

• host - nazwa maszyny na której może być uruchomione zadanie. Może być wiele takich dyrektyw dla alternatywnych maszyn.

  Code Block
  #QCG host=reef.man.poznan.pl #QCG host=zeus.cyfronet.pl

stage-in-file

• stage-in-file - dyrektywa kopiowania pliku wejściowego. Składnia „lokalizacja_źródłowa → nazwa_docelowa_pliku”. Lokalizacja źródłowa może być lokalizacją gsiftp lub ścieżką do pliku. W tym drugim przypadku zakłada się, że jest ustalana względem katalogu, z którego zlecono zadanie.

W przypadku braku drugiego parametru plik kopiowany jest pod nazwę źródlową.

#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

stage-in-dir

• stage-in-dir - dyrektywa kopiowania katalogu wejściowego. Funkcjonalność i składnia analogiczna jak dla dyrektywy „stage-in-file” tyle, że kopiowany jest katalog.

  Code Block
  #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

  Info
  Skopiowanie całego katalogu w którym uruchomiony został klient odbywa się poprzez podanie ”.” (kropki) jako nazwy katalogu źródłowego i ewentualnie docelowego

  Code Block
  #QCG stage-in-dir=. -> . #QCG stage-in-dir=. #QCG stage-in-dir=. -> input

stage-out-file

• stage-out-file - dyrektywa kopiowania pliku wyjściowego. Składnia „nazwa_pliku_źródłowego → lokalizacja docelowa pliku”. Lokalizacja docelowa może być lokalizacją gsiftp lub ścieżką do pliku. W tym drugim przypadku zakłada się, że jest ustalana względem katalogu, z którego zlecono zadanie. W przypadku braku drugiego parametry plik przegrywany jest pod nazwę źródłową.

  Code Block
  #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

stage-out-dir

• stage-out-dir - dyrektywa kopiowania katalogu wyjściowego. Funkcjonalność i składnia analogiczna jak dla dyrektywy „stage-out-file” tyle, że kopiowany jest katalog.

  Code Block
  #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

  Info
  Skopiowanie całego katalogu w którym wykonane było zadanie odbywa się poprzez podanie ”.” (kropki) jako nazwy katalogu źródłowego.

  Code Block
  #QCG stage-out-dir=. -> . #QCG stage-out-dir=. #QCG stage-out-dir=. -> output

grant

• grant - nazwa grantu, w ramach którego ma być wykonane zadanie.

  Code Block
  #QCG grant=plgpiontek_grant

argument

• argument - argument aplikacji w przypadku użycia dyrektywy „executable” lub „application”. Argument może wystąpić wielokrotnie. Każdy argument powinien być przekazany w osobnej dyrektywie. Argumenty do aplikacji przekazywane są w kolejności ich wystąpienia w pliku opisu

  Code Block
  #QCG argument=arg1 #QCG argument=arg2

environment

• environment - ustawianie zmiennych środowiskowych. Składnia „nazwa → wartość”. Każda zmienna musli być ustawiana w osobnej linii.

  Code Block
  #QCG environment=name -> piontek #QCG environment=location -> poznan

executable

• executable - lokalizacja pliku do uruchomienia. Lokalizacja może być lokalizacją gsiftp lub ścieżką do pliku. W tym drugim przypadku przyjmuje się, że jest ustalana względem katalogu, z którego zlecone zostało zadanie. Opcjonalnie możliwe jest podanie nazwy pod jaką ma być zapisany plik wykonywalny. W przypadku braku nazwy zapisywany jest pod oryginalna nazwą.

  Code Block
  #QCG executable=gsiftp://qcg.man.poznan.pl//home/plgrid/plgpiontek/reef/executables/exec1 #QCG executable=executables/exec1 #QCG executable=executables/exec1 -> exec-file

application

• application - nazwa aplikacji do uruchomienia.

  Code Block
  #QCG application=namd

persistent

• persistent - dyrektywa określająca czy po zakończeniu zadania system ma pozostawić katalog roboczy, w którym wykonywane było zadanie.

  Code Block
  #QCG persistent

procs

• procs - liczba rdzeni obliczeniowych, na których ma być wykonane zadanie. (Stosowane dla zadań MPI.)

  Code Block
  #QCG procs=32

nodes

• nodes - dyrektywa pozwalająca zdefiniować na ilu węzłach i rdzeniach w ramach węzła ma być uruchomione zadanie. Opcjonalnie można podać ile procesów ma być uruchomione na węzłach. Domyślnie, jeżeli nie zostanie podane inaczej, liczna procesów równa jest liczbie rdzeni przydzielonych w ramach węzła. Składnia liczna_węzłów:liczba_rdzeni_na_węźleliczba_procesów.

  Code Block
  #QCG nodes=10:5:1 #QCG nodes=12:12

walltime

• walltime - dyrektywa definiująca deklarowany przez użytkownika czas wykonania zadania w formacie PnYnMnDTnHnMnS, w formacie ISO 8601 gdzie:
  
  • P - obowiązkowy znak rozpoczynający definicję okresu,
  • nY - liczba lat,
  • nM - liczba miesięcy,
  • nD - liczba dni,
  • T - separator czasu (musi być obecny, jeśli zdefiniowane są poniższe wartości)
  • nH - liczba godzin,
  • nM - liczba minut,
  • nS - liczba sekund.

  Code Block
  #QCG walltime=P3DT12H

memory

• memory - dyrektywa definiująca deklarowane maksymalne zapotrzebowanie aplikacji na pamięć operacyjną. Podana wartość jest w MB.

  Code Block
  #QCG memory=1024

properties

• properties - dyrektywa definiująca właściwości węzłów na których ma być uruchomione zadanie.

  Code Block
  #QCG properties=mpi,ib,lustre

preprocess

• preprocess - dyrektywa umożliwiająca wykonanie polecenia/skryptu przed uruchomieniem właściwego zadania. Wartością dyrektywy może być polecenie lub ścieżka do pliku, który ma być wykonany.

  Code Block
  #QCG preprocess=mkdir outputs

  Code Block
  #QCG preprocess=preprocess-script.sh

postprocess

• postprocess - dyrektywa umożliwiająca wykonanie polecenia/skryptu po zakończeniu się właściwego zadania. Wartością dyrektywy może być polecenie lub ścieżka do pliku, który ma być wykonany.

  Code Block
  #QCG postprocess=tar cvf wynik.tar *

  Code Block
  #QCG preprocess=postprocess-script.sh

monitor

• monitor - dyrektywa umożliwiająca zdefiniowanie skryptu, który zostanie uruchomiony przed uruchomieniem właściwego zadania i zabity po zakończeniu zadania. Funkcjonalność ta umożliwia w prosty sposób zaimplementowanie monitoringu aplikacji. Uruchomiony skrypt może cyklicznie wyszukiwać w wyniku aplikacji zadanych wzorców i przesyłać je w dowony sposób do użytkownika.

  Code Block
  #QCG monitor=monitor-script.sh

Przykładowe opisy

• Uruchomienie na klastrze galera aplikacji „gaussian”.

  Code Block

  #QCG queue=plgrid-long #QCG name=etanal #QCG note=etanal Gaussian #QCG output=${JOB_ID}.output #QCG error=${JOB_ID}.error #QCG stage-in-file=etanal.gjf -> etanal.gjf #QCG stage-out-file=wynik.tar -> ${JOB_ID}.tar #QCG nodes=1:12 #QCG host=galera.task.gda.pl #QCG persistent #QCG walltime=P7D #QCG notify=mailto:piontek@man.poznan.pl #QCG memory=15360 #QCG preprocess=echo START #QCG application=g09 #QCG argument=etanal.gjf #QCG postprocess=tar cvf wynik.tar *

• Eksperyment polegający na:
  
  • przegraniu z katalogu, z którego wykonano polecenie qcg-sub podkatalogu inputs na klaster na docelowy klaster (reef).
  • zleceniu do wykonania na klastrze reef w kolejce plgrid polecenia /bin/tar pakującego przegrany wczesnej katalog inputs do pliku output.tgz.

  • przesłaniu pliku output.tgz do katalogu, z którego wykonano polecenie qcg-sub pod tę samą nazwę.

  Code Block
  #!/bin/bash #QCG queue=plgrid #QCG persistent #QCG host=reef.man.poznan.pl #QCG output=output #QCG error=error #QCG stage-in-dir=inputs -> inputs /bin/tar -czf output.tgz inputs/input.* #QCG stage-out-file=output.tgz -> output.tgz

WOROKING

qcgJob - definicja eksperymentu

Opis każdego eksperymentu obliczeniowego QCG rozpoczyna się elementem qcgJob W elemencie tym można podać następujące atrybuty:

• appId - definiowany przez użytkownika element, który pojawi się jako część identyfikatora eksperymentu. Dozwolone są znaki dopuszczalne w nazwach katalogów w systemie Linux (obowiązkowy, typ: tekst),
• project - identyfikator grantu, w ramach którego zlecany jest eksperyment (opcjonalny, typ: tekst),

• commitWait- atrybut określający czy przetwarzanie eksperymentu ma być wstrzymane do czasu aż użytkownik wywoła polecenie commit_job (opcjonalny, dopuszczalne wartości: true,false, wartość domyślna: false),

  Code Block
  <qcgJob appId="moj_eksperyment" project="grant123" commitWait="true"> ... </qcgJob>

  Każdy eksperyment obliczeniowy składa się z minimum jednego zadania - elementu task o unikalnym identyfikatorze.

  Code Block
  <qcgJob appId="moj_eksperyment" project="grant123" commitWait="true"> <task taskId="zadanie_1"> ... </task> <task taskId="zadanie_2"> ... </task> </qcgJob>

description - opis eksperymentu

Eksperyment może zawierać opisujący go opcjonalny element description.

<qcgJob appId="moj_eksperyment">
   <description>Najważniejszy eksperyment w PL-Grid<description>
</qcgJob>

task - definicja zadania

Element task odpowiada pojedynczemu zadaniu obliczeniowemu wchodzącemu w skład eksperymentu (qcgJob).
Task może/musi zawierać następujące atrybuty:

• taskId - unikalny identyfikator zadania w ramach eksperymentu. Dozwolone są znaki dopuszczalne w nazwach katalogów w systemie Linux (obowiązkowy, typ: tekst)
• persistent - określa czy po zakończeniu zadania system ma automatycznie usunąć czy pozostawić katalog, w którym wykonywało się zadanie (opcjonalny, dopuszczalne wartości: true,false, wartość domyślna: false),
• crucial - określa czy poprawne zakończenie zadania jest istotne dla pomyślnego zakończenia całego eksperymentu (opcjonalny, dopuszczalne wartości: true,false, wartość domyślna: true),
• commitWait - atrybut określający czy przetwarzanie zadania ma być wstrzymane do czasu aż użytkownik wywoła polecenie commit_task (opcjonalny, dopuszczalne wartości: true,false, wartość domyślna: false),

<qcgJob appId="moj_eksperyment">
 ...  
   <task taskId="zadanie_2" persistent="true" commitWait="false">
   ...
   </task>

description - opis zadania

Zadanie może zawierać opisujący go opcjonalny element description.

<task taskId="zadanie_2" persistent="true" commitWait="false">
   <description>Zadanie wyznaczające ...</description>
</task>

candidateHosts - lista potencjalnych zasobów obliczeniowych

Zlecając eksperyment do wykonania można dla każdego zadnia zdefiniować listę potencjalnych maszyn, spośród których QCG-Broker będzie dokonywał wyboru. W przypadku braku elementu candidateHosts Broker wybiera spośród wszystkich dostępnych maszyn, na których użytkownik ma prawo wykonywać zadania.

<candidateHosts>
    <hostName>reef.man.poznan.pl</hostName>
    <hostName>zeus.cyfronet.pl</hostName>
</candidateHosts>

requirements - definicja wymagań zasobowych dla zadania

Element ten pozwala na wyrażenie wymagań zasobowych dotyczących zleconego zadania. Możliwe jest zdefiniowanie prostych wymagań opisujące tylko parametry węzłów obliczeniowych (element resourceRequirements) lub, w przypadku zadań rozproszonych, topologii i wymagań dla poszczególnych grup procesów (element topology).

resourceRequirements - opis wymagań zasobowych

Element zawierający opis wymagań zasobowych dotyczący parametrów maszyny obliczeniowej. Element ten może zawierać jeden lub więcej elementów computingResource ze zdefiniowaną listą parametrów - elementy hostParameter. Element hostParameter ma atrybut computingParameterName określający po nazwie definiowany parametr. Wartość parametru może być liczbowa, przekazywana w elemencie value, lub tekstowa w elemencie stringValue.
Lista możliwych parametrów:

• osname - nazwa systemu operacyjnego,
• ostype - typ systemu operacyjnego,
• cpuarch - architektura procesora
• cpucount - liczba procesorów
• gpucount - liczba akceleratorów graficznych
• application - dostępne aplikacje
• queue - nazwa kolejki, do której ma być zlecone zadanie

<requirements>
   <resourceRequirements>
      <computingResource>
         <hostParameter name="gcpucount">
            <value>3</value>
         </hostParameter>
      </computingResource>
   </resourceRequirements>
</requirements>

<requirements>
   <resourceRequirements>
      <computingResource>
         <hostParameter name="queue">
            <stringValue value="plgrid-long"/>
         </hostParameter>
      </computingResource>
   </resourceRequirements>
</requirements>

<requirements>
   <resourceRequirements>
      <computingResource>
         <hostParameter name="application">
            <stringValue value="abinit"/>
         </hostParameter>
      </computingResource>
   </resourceRequirements>
</requirements>