queue

• queue - wybrana kolejka systemu kolejkowego.

  #QCG queue=plgrid
  

note

• note - krótka informacja o zadaniu.

  #QCG note=moje pierwsze zadanie QCG
  

name

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

  #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.

  #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.

  #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.

  #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.

  #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.

  #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

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ą.

  #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.

  #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

grant

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

  #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

  #QCG argument=arg1
  #QCG argument=arg2
  

environment

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

  #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ą.

  #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.

  #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.

  #QCG persistent
  

procs

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

  #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.

  #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.

  #QCG walltime=P3DT12H

memory

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

  #QCG memory=1024
  

properties

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

  #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.

  #QCG preprocess=mkdir outputs
  

  #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.

  #QCG postprocess=tar cvf wynik.tar *
  

  #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.

  #QCG monitor=monitor-script.sh
  

Przykładowe opisy

• Uruchomienie na klastrze galera aplikacji „gaussian”.

  #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ę.

  #!/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),

  <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.

  <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>

topology - topologia grup procesów

Element topology służy do opisu zadań rozproszonych składających się z potencjalnie wielu grup procesów o odmiennych wymaganiach zasobowych.
W przypadku zadań z wieloma grupami procesów, lub przy podziale grupy pomiędzy wiele zasobów, QCG-Broker dokonuje koalokacji zasobów dla wszystkich grup.
Element topology zawiera nie mniej niż jeden element processes definiujący pojedynczą grupę procesów.
Element processes ma następujące atrybuty:

• processesId - identyfikator grupy procesów (opcjonalny, typ: tekst),
• masterGroup - atrybut ten pozwala określić, do której grupy należeć ma proces master rozproszonej aplikacji (opcjonalny, typ: logiczny, domyślnie false). W przypadku, gdy żadna grupa nie jest wybrana proces master wybierany jest niedeterministycznie,
• divisible - atrybut określający czy dana grupa może być dzielona pomiędzy wiele zasobów (opcjonalny, typ: logiczny, domyślna wartość: true),
  Każdy element processes może zawierać następujące elementy:
• processesCount - liczność grupy procesów,
• processesMap - mapa alokacji procesów dla zadań hybrydowych (określa liczbę węzłów obliczeniowych dla zadania oraz procesów na każdym z węzłów),
• candidateHosts - lista potencjalnych maszyn, na których może być wykonana grupa procesów,
• reservation - rezerwacja, w ramach której ma być uruchomiona grupa procesów. Element ten wymaga jednoznacznego wyboru maszyny poprzez candidateHosts,

• resourceRequirements - opis wymagań zasobowych dla grupy procesów,

       <topology>
          <processes processesId="SMC:collector:distributor:Blob:voxelizer:thrombusMapper" masterGroup="true">
            <processesCount>
              <value>1</value>
            </processesCount>
            <candidateHosts>
              <hostName>reef.man.poznan.pl</hostName>
            </candidateHosts>
          </processes>
          <processes processesId="BF">
            <processesCount>
              <value>32</value>
            </processesCount>
            <candidateHosts>
              <hostName>huygens.sara.nl</hostName>
            </candidateHosts>
            <reservation type="LOCAL">p6012.huygens.sara.nl.537.r</reservation>
          </processes>
          <processes processesId="DD">
            <processesCount>
              <value>4</value>
            </processesCount>
            <candidateHosts>
              <hostName>zeus.cyfronet.pl</hostName>
            </candidateHosts>
          </processes>
        </topology>
  

  W poniższym przykładzie zadanie uruchomione zostanie na 3 węzłach (liczba elementów processesPerNode), na każdym węźle do zadania przydzielone zostanie 8 slotów obliczeniowych (atrybut slotsPerNode). Na węzłach uruchomione zostaną odpowiednio 1, 8, 8 procesów (wartości elementu processesPerNode).

        <topology>
           <processes processesId="process">
              <processesMap slotsPerNode="8">
                 <processesPerNode>1</processesPerNode>
                 <processesPerNode>8</processesPerNode>
                 <processesPerNode>8</processesPerNode>
               </processesMap>
               <candidateHosts>
                  <hostName>grass1.man.poznan.pl</hostName>
               </candidateHosts>
            </processes>
        </topology>
  

execution - deklaracja typu zadania

Element execution opisuje uruchomienie pojedynczego zadania. Zawiera informację jaki jest jego typ, plik wykonywalny, argumenty, strumienie wejścia, wyjścia i błędów, pliki i katalogi z danymi wejściowymi i wynikami oraz zmienne środowiskowe. Atrybut type określa rodzaj zadania oraz sposób w jaki będzie wykonywane. Wspierane są następujące typy:

• single - aplikacja będąca pojedynczym procesem,
• open_mpi, mpi_mp - zadanie rozproszone MPI. Zadanie może składać się z wielu alokacji, a stan zadania zależy od stanu wszystkich alokacji. Jeżeli element stdout/etderr wskazuje na katalog, to standardowe wyjścia zgrywane są ze wszystkich alokacji. Jeżeli element stdout/etderr wskazuje na plik, to standardowe wyjścia zgrywane jest tylko z procesu mastera. Pliki wyjściowe kopiowane są tylko z głównej alokacji (proces master). W przypadku, gdy jedna z alokacji zakończy się niepowodzeniem, wykonywanie pozostałych jest automatycznie anulowane. Ustawiane są następujące zmienne środowiskowe:
  • OMPI_SESSION_ID - unikalny identyfikator sesji,
  • OMPI_PROCESSES_ID - identyfikator grupy procesów,
  • OMPI_MASTER_GROUP - informacja czy dana alokacja zawiera proces master,
  • OMPI_PROCESSES - łaczna liczba procesów,
  • OMPI_COLORS - opis kolorów dla zadania (procesy o tym samym kolorze znajdują się na tym samym zasobie),
  • QCG_MACHINEFILE - lokalizacja pliku machinefile,
• mapper - zadanie rozproszone. Różni się od typu open_mpi tym, że pliki wyjściowe przegrywane są ze wszystkich alokacji. Dla tego typu zadnia przekazywane są następujące zmienne środowiskowe: OMPI_PROCESSES_ID, OMPI_MASTER_GROUP, OMPI_PROCESSES,
• proactive - zadanie rozproszone środowiska PROACTIVE. Różni się od zadania open_mpi tym, że do głównej alokacji kopiowany jest tworzony automatycznie plik proactive description. Do zadania przekazywane są następujące zmienne środowiskowe:
  • PROACITIVE_SESSION_ID - identyfikator sesji, mający postać '{JOBID}:{TASKID}'
  • PROACTIVE_PROCESSES_ID - identyfikator grupy procesów
  • PROACTIVE_MASTER_GROUP - informacja czy dana alokacja zawiera proces master,
  • PROACTIVE_PROCESSES - łączna liczba procesów.

<execution type="single">
...
</execution>