Prometheus:Basics

Logging in

Access to the Prometheus cluster is facilitated by the access host at:

prometheus.cyfronet.pl

eg.

ssh <plgtestowy>@prometheus.cyfronet.pl

You can also use the short alias pro.cyfronet.pl.

An SSH client is required for login.

Available software

A list of available software can be found here.

Access to software is provided through the Lmod tool.

Partitions

SLURM replaces PBS queues with the concept of partitions. The following paritions are currently available for Prometheus users:

Parition name	Max task duration	Description
plgrid	72:00:00	Default partition
plgrid-testing	1:00:00	For testing and preparing computations (e.g. building applications, copying files etc.)
plgrid-short	1:00:00	For short tasks (walltime shorter than 1h); provides an increased likelihood that tasks will be rapidly scheduled for execution
plgrid-long	168:00:00	For long-duration tasks (as specified in the relevant grant)
plgrid-large	24:00:00	For tasks requiring at least 432 cores (18 full nodes); contains additional resources not available through the plgrid partition
plgrid-gpu	72:00:00	For tasks requiring GPGPU computations (note that access to GPGPU must be allowed under the relevant grant)

Further information regarding any specific partition may be obtained by running the following command:

scontrol show partition [<partition_name>]

Notes:

• Selecting the right partition and specifying the expected execution time greatly increase the chances that your task will be quickly scheduled for execution. We recommend that tasks be preferentially submitted to partitions with short maximum execution times (e.g. plgrid-short where feasible).
• Failing to specify a partition will cause your task to be submitted to the default partition, i.e. plgrid.
• Tasks submitted to plgrid (or submitted without specifying a partition) may be automatically transferred to plgrid-large or plgrid-short by the queue manager, if this will cause them to be executed faster.
• Currently, all users may access plgrid, plgrid-testing, plgrid-short and plgrid-large. Access to other partitions is regulated by grants and provided on a case-by-case basis in the course of evaluating proposed grants.
• If you wish to access plgrid-long, this must be clearly expressed in your grant application.
• Access to plgrid-gpu requires applying for a separate grant which is wholly dedicated to GPGPU computations.
• plgrid-testing must not be used for large-scale computations. This partition is specifically meant for tests and other maintenance tasks (e.g. building applications, interactively copying data etc.)

Disk storage

Location	Volume quota	Files quota	Purpose	Access	Throughput	Available space	Backups	Support for intensive writes and/or reads	Availability	Remarks
$HOME	40 GB	1 000 000	user home directory	NFS	1 GB/s	∞	yes	no	global
$SCRATCH	100 TB	1 000 000	storage for temporary task data	Lustre	120 GB/s	5 PB	no	yes	global	data older than 30 days will be automatically deleted
$PLG_GROUPS_STORAGE/<team_name>	grant total		Storage for PL-Grid team datasets	Lustre	30 GB/s	2.5 PB	no	no	global
$SCRATCH_LOCAL	512 GB	∞	local scratch storage	Lustre	120 GB/s	-	no	yes	limited to single node	unavailable following completion of task; requires -C localfs

Environmental variables

Personal:

• $HOME, $PLG_USER_STORAGE, eg. '/people/plgtestowy' - points to your home directory
• $PLG_USER_SCRATCH_SHARED, $SCRATCH eg. '/net/scratch/people/plgtestowy/' - points to your private scratch storage - this is where data should be stored during computations

Team-wide (append team name to each variable):

• PLG_GROUPS_STORAGE, PLG_GROUPS_SHARED, eg. '/net/archive/groups' - points to where teams are expected to deposit their data (including input data, output data and data shared between team members)

Local scratch storage

For computations which require a large quantity of metadata operations (open/close/create/remove) it is possible to set up dedicated scratch storage. To do so, please supply the -C localfs parameter when submitting your tasks (i.e. at the resource allocation stage, before the task ID is assigned).

For example, when submitting tasks in batch mode, use the following directive: #SBATCH -C localfs

Any task submitted in this fashion will be assigned a separate scratch volume, available on the computational nodes and referenced by the $SCRATCH_LOCAL environmental variable (using the /localfs/<task_id> naming convention). $SCRATCH_LOCAL space is optimized for processing small files. Each computational node possesses a separate $SCRATCH_LOCAL volume, available only during execution of the given task.

The size of $SCRATCH_LOCAL is 512GiB per computational node assigned to your task. Please contact the administrators if you require more scratch space.

Caution: The $SCRATCH_LOCAL volume is available only on those computational nodes which have been allocated to your task, and only while the task is executing. Furthermore, it is not shared across nodes (i.e. each node possesses a separate volume). Following completion of your task, you will lose any data saved in $SCRATCH_LOCAL - if this data is relevant, it must first be copied to your team storage ($PLG_GROUPS_STORAGE/<team_name>) or to your home directory ($HOME).

MEMFS RAM storage

In order to allocate RAM for storage of temporary files, please add the "-C memfs” parameter to your task specification. For example, use the following directive in your batch script: #SBATCH -C memfs

A storage volume will be set up for your task, referenced by the $MEMFS environmental variable. Please note that memory allocated to MEMFS storage counts towards the total memory allocated for your task and declared through "--mem" or "--mem-per-cpu".

Caution: When using MEMFS for file storage, be aware of the following limitations:

• this method is only available for single-node tasks
• the total amount of memory consumed by your task, including any MEMFS storage, must not exceed the value declared through "--mem" or "--mem-per-cpu".
• this method may only be used if the total memory requirements of your task (including MEMFS storage) do not exceed the memory available on a single node (120 GB per standard Prometheus node).
• when using MEMFS, it is recommended to request allocation of a full node for your task.

Running jobs

The SLURM scheduling system is used to manage jobs on the Prometheus cluster.

A job may be executed in batch or interactive mode.

Before running any jobs, please familiarize yourself with the grant system

Batch mode

To run a job in batch mode, use the sbatch command. Usage: sbatch script.sh.
All scheduler options should be preceded by the #SBATCH keyword (do not forget the #!).
For more information see: man sbatch and sbatch --help.

Sample script:

CAUTION! This sample script is provided as a reference and SHOULD NOT be executed as is. Before running any jobs, make sure that the scheduler options accurately reflect your requirements e.g. with regard to grant ID, partition name, execution time etc.

#!/bin/bash -l
## Job name
#SBATCH -J ADFtestjob
## Number of allocated nodes
#SBATCH -N 1
## Number of tasks per node (by default this corresponds to the number of cores allocated per node)
#SBATCH --ntasks-per-node=1
## Memory allocated per core (default is 5GB)
#SBATCH --mem-per-cpu=1GB
## Max task execution time (format is HH:MM:SS)
#SBATCH --time=01:00:00 
## Name of grant to which resource usage will be charged
#SBATCH -A <grant_id>
## Name of partition
#SBATCH -p plgrid-testing
## Name of file to which standard output will be redirected
#SBATCH --output="output.out"
## Name of file to which the standard error stream will be redirected
#SBATCH --error="error.err"

## change to sbatch working directory
cd $SLURM_SUBMIT_DIR

srun /bin/hostname
module load plgrid/apps/adf/2014.07 
adf input.adf

MPI jobs

Uruchamianie zadań MPI na Prometheuszu wygląda podobnie jak uruchamianie takich zadań na innych klastrach wyposażonych w system kolejkowy SLURM integrujący się z bibliotekami MPI. W przypadku Prometheusa dostępne są różne wersje bibliotek MPI (najczęściej OpenMPI i IntelMPI) dla większości dostępnych kompilatorów. Podczas uruchamiania aplikacji proszę nie podawać explicite parametru -n lub -np system dobierze odpowiednie wartości na podstawie parametrów alokacji (umieszczonych w skrypcie startowym) i zostaną one zastosowane. W uzasadnionych przypadkach, gdzie aplikacja wymaga specyficznej konfiguracji (np. lokalne wątkowanie), można podać wspomniane parametry.

UWAGA! To jest przykładowy skrypt, którego NIE NALEŻY uruchamiać. Przed jego uruchomieniem należy przeglądnąć podane opcje i dostosować je do własnych potrzeb, zmieniając m.i. nazwę grantu, nazwę partycji, czas trwania zadania, itp.

#!/bin/bash -l
## Nazwa zlecenia
#SBATCH -J MPITest
## Liczba alokowanych węzłów
#SBATCH -N 2
## Liczba zadań per węzeł (domyślnie jest to liczba alokowanych rdzeni na węźle)
#SBATCH --ntasks-per-node=24
## Ilość pamięci przypadającej na jeden rdzeń obliczeniowy (domyślnie 5GB na rdzeń)
#SBATCH --mem-per-cpu=5GB
## Maksymalny czas trwania zlecenia (format HH:MM:SS)
#SBATCH --time=01:00:00 
## Nazwa grantu do rozliczenia zużycia zasobów
#SBATCH -A <grant_id>
## Specyfikacja partycji
#SBATCH -p plgrid-testing
## Plik ze standardowym wyjściem
#SBATCH --output="output.out"
## Plik ze standardowym wyjściem błędów
#SBATCH --error="error.err"

srun /bin/hostname

## Zaladowanie modulu IntelMPI
module add plgrid/tools/impi

## przejscie do katalogu z ktorego wywolany zostal sbatch
cd $SLURM_SUBMIT_DIR

mpiexec ./calcDiff 100 50

Dobrą praktyką jest kompilowanie i uruchamianie aplikacji przy pomocy środowiska budowanego tym samym zestawem modułów. Zalecamy korzystanie z wrappera mpiexec. Wielkość alokacji, w tym przypadku 2 węzły po 24 rdzenie, przekłada się bezpośrednio na 48 tasków dostępnych dla aplikacji korzystającej z MPI. Dopuszczalne jest uruchomienie serii aplikacji MPI w jednym skrypcie, ale najczęściej, ze względu na długi czas wykonania, nie jest to optymalny sposób prowadzenia obliczeń. Niedopuszczalne jest jednoczesne uruchomienie wielu aplikacji MPI w ramach jednej alokacji, taka praktyka prowadzi do kłopotówzwiązanych z alokacją zasobów na wyłączność dla danej aplikacji.

Proste zrównoleglenie wielu niezależnych zadań

Dość częstym przypadkiem użycia klastra jest przetworzenie wielu paczek danych, gdzie każda paczka jest przetwarzana niezależnie. Dobrym przykładem takich zadań jest przetwarzanie wielu obrazów w ten sam sposób. SLURM umożliwia proste zrównoleglenie takiego przetwarzania poprzez użycie komendy srun. Przykładowy skrypt, który zrównolegli uruchomienie wielu instancji obliczeń, gdzie stopień równoległości jest ustalany na podstawie parametrów zadania, znajduje się poniżej:

UWAGA! To jest przykładowy skrypt, którego NIE NALEŻY uruchamiać. Przed jego uruchomieniem należy przeglądnąć podane opcje i dostosować je do własnych potrzeb, zmieniając m.i. nazwę grantu, nazwę partycji, czas trwania zadania, itp.

#!/bin/bash -l
## Nazwa zlecenia
#SBATCH -J testjob
## Liczba alokowanych węzłów
#SBATCH -N 2
## Liczba zadań per węzeł (domyślnie jest to liczba alokowanych rdzeni na węźle)
#SBATCH --ntasks-per-node=24
## Ilość pamięci przypadającej na jeden rdzeń obliczeniowy (domyślnie 5GB na rdzeń)
#SBATCH --mem-per-cpu=5GB
## Maksymalny czas trwania zlecenia (format HH:MM:SS)
#SBATCH --time=01:00:00 
## Nazwa grantu do rozliczenia zużycia zasobów
#SBATCH -A <grant_id>
## Specyfikacja partycji
#SBATCH -p plgrid-testing
## Plik ze standardowym wyjściem
#SBATCH --output="output.out"
## Plik ze standardowym wyjściem błędów
#SBATCH --error="error.err"

module load plgrid/tools/imagemagick

## przejscie do katalogu z ktorego wywolany zostal sbatch
cd $SLURM_SUBMIT_DIR

ls *.tif | xargs -t -d "\n" -P ${SLURM_NTASKS} -n 1 srun -n 1 -N 1 --mem=5gb mogrify -format png

Powyższy skrypt dla każdego pliku *tif w katalogu uruchomi aplikację mogrify, tak aby skonwertować obraz do pliku png. Pierwszą czynnością jest wylistowanie plików wejściowych, następnie wynik jest przekazywany do komendy xargs, która przez parametr -P zapewnia równoległe uruchomienie dalszego polecania srun. Do każdej instancji srun zostanie przekazany jeden parametr, maksymalna równoległość wyniesie ${SLURM_NTASKS}. Każdy srun uruchomi aplikację mogrify na jednym rdzeniu z przydzielonym 5GB pamięci.

Tryb interaktywny

Do zlecania zadań w trybie interaktywnym z powłoką służy komenda (przykład): srun -p plgrid-testing -N 1 --ntasks-per-node=1 -n 1 -A <grant_id> --pty /bin/bash -l Powyższa komenda uruchomi zadanie w partycji plgrid-testing na 1 węźle z alokacją 1 rdzenia.

Samo polecenie srun odpowiada za uruchomienie komendy w ramach zaalokowanych zasobów.
Jednak w przypadku, gdy zasoby nie zostały wcześniej zaalokowane, komenda ta uprzednio dokonuje ich rezerwacji tuż przed uruchomieniem obliczeń.

UWAGA: Tryb graficzny (poprzez protokół X11) dostępny jest jedynie na maszynie dostępowej klastra Prometheus.

Zadania tablicowe

Zadania tablicowe to mechanizm pozwalający na zlecanie dużej ilości zadań wsadowych, które są do siebie podobne. Zadania tablicowe posiadają swój indeks, dostępny jako zmienną środowiskowa $SLURM_ARRAY_TASK_ID wewnątrz zadania, dzięki któremu można odpowiednio parametryzować uruchamianą aplikację. Sposób zlecania zadania jest analogiczny jak w przypadku zwykłych zadań wsadowych, a przykładowy skrypt zawierający parametr --array -a, definiujący zakres indeksów, wygląda następująco:

UWAGA! To jest przykładowy skrypt, którego NIE NALEŻY uruchamiać. Przed jego uruchomieniem należy przeglądnąć podane opcje i dostosować je do własnych potrzeb, zmieniając m.i. nazwę grantu, nazwę partycji, czas trwania zadania, itp.

#!/bin/bash -l
## Nazwa zlecenia
#SBATCH -J testjob
## Liczba alokowanych węzłów
#SBATCH -N 1
## Liczba zadań per węzeł (domyślnie jest to liczba alokowanych rdzeni na węźle)
#SBATCH --ntasks-per-node=1
## Ilość pamięci przypadającej na jeden rdzeń obliczeniowy (domyślnie 5GB na rdzeń)
#SBATCH --mem-per-cpu=1GB
## Maksymalny czas trwania zlecenia (format HH:MM:SS)
#SBATCH --time=01:00:00 
## Nazwa grantu do rozliczenia zużycia zasobów
#SBATCH -A <grant_id>
## Specyfikacja partycji
#SBATCH -p plgrid-testing
## Plik ze standardowym wyjściem
#SBATCH --output="output.out"
## Plik ze standardowym wyjściem błędów
#SBATCH --error="error.err"
## Parametr wyznaczający indeksy zadania tablicowego
#SBATCH --array=0-100

## przejscie do katalogu z ktorego wywolany zostal sbatch
cd $SLURM_SUBMIT_DIR

myCalculations $SLURM_ARRAY_TASK_ID

Zadania wykorzystujące GPGPU

Dostęp do węzłów z GPGPU

Dla zadań korzystających w obliczeniach z kart GPGPU przeznaczona została specjalna partycja - plgrid-gpu. Aby móc przeprowadzać obliczenia z wykorzystaniem GPGPU konieczne jest złożenie wniosku o grant właściwy, który przeznaczony zostanie w całości wyłącznie na obliczenia z wykorzystaniem kart GPGPU. Grant taki nie powinien być używany do przeprowadzania obliczeń w partycjach innych niż plgrid-gpu. We wniosku o grant należy wyraźnie zaznaczyć, że wymagany jest dostęp do partycji plgrid-gpu. Zalecane jest także (ale nie jest to konieczne), aby grant taki posiadał w nazwie wyraz gpu (np. obliczeniagpu) - ułatwia to identyfikację grantów. Każdy wniosek o dostęp do partycji plgrid-gpu jest rozpatrywany indywidualnie przez dostawcę zasobów.

Informacje ogólne

Karty GPU w systemie kolejkowym SLURM są rodzajem tzw. generic resources (GRES), a ich identyfikatorem jest "gpu".
Informację o tym na których węzłach/partycjach znajdują się karty GPU można otrzymać np. przy pomocy komendy sinfo:

sinfo -o '%P || %N || %G'

Zlecanie zadań odbywa się poprzez podanie opcji --partition=plgrid-gpu --gres=gpu[:count] systemu kolejkowego.
W przypadku gdy nie ma podanej opcji count, system kolejkowy domyślnie alokuje jedną kartę na węźle obliczeniowym.

Po zleceniu zadania system kolejkowy automatycznie ustawia zmienną środowiskową $CUDA_VISIBLE_DEVICES oraz zezwala na dostęp do zaalokowanych do kart.

Zadania interaktywne

Przykładowo, gdy chcemy uruchomić zadanie interaktywne na jednym serwerze i zażądać 2 kart GPU:

srun -p plgrid-gpu -N 1 -n 24 -A <grant_id> --gres=gpu:2 --pty /bin/bash -l

Zadania interaktywne MPI

Uwaga! Wyjątkiem jest uruchamianie interaktywnych aplikacji MPI (np. w celach testów). Z powodu nieco innej obsługi kart GPU niż zwykłych procesorów przez system SLURM, uruchomienie zadania interaktywnego wymaga niestandardowej procedury.

Przykładowo, gdy chcemy uruchomić zadanie interaktywne na dwóch serwerach i zażądać 2 kart GPU na każdym z nich (łącznie 4 karty GPU) na czas 1 godziny:

salloc -p plgrid-gpu -N 2 --ntasks-per-node 24 -n 48 -A <grant_id> --gres=gpu:2 --time 1:00:00

Polecenie salloc zaalokowało nasze zadanie i zwróciło jego numer, przykładowo 1234.

Następnie uruchamiamy srun wymagając 0 kart GPU w zadaniu o numerze zwróconym przez salloc:

srun --jobid=1234 --gres=gpu:0 -O --pty /bin/bash -l

Otrzymaliśmy dostęp do powłoki na jednym z węzłów, teraz po załadowaniu odpowiedniego modułu MPI można już uruchomić własną aplikację za pomocą mpirun lub mpiexec. Isotne jest aby podczas uruchamiania aplikacji nie przekazywać zmiennych środowiska, czyli w przypadku IntelMPI należy dodać parametr -genvnoneAplikacja będzie miała dostęp do wszystkich kart GPU zaalokowanych w komendzie salloc, niezależnie od wymagania gpu:0 użytego w srun.

Po zakończeniu testów należy usunąć alokację za pomocą:

scancel 1234

Zadania wsadowe

Dla skryptu wsadowego dodatkowe zmiany nie są potrzebne, przykładowo gdy żądamy po jednej karcie na węzeł obliczeniowy, wystarczy dopisać do skryptu:

#SBATCH --partition=plgrid-gpu
#SBATCH --gres=gpu

Uwaga: Wszelkie informacje na temat komend SLURMa można znaleźć w manualu, np.: man sbatch

Monitorowanie kolejek, partycji, węzłów, zadań i zasobów

• Sktypty specyficzne dla Prometheusa

  • pro-jobs - statystyki dla zakolejkowanych lub już uruchomionych zadań użytkownika
  • pro-jobs-history - statystyki dla zakończonych zadań użytkownika
  • pro-fs - statystyki użycia zasobów dyskowych przez użytkownika
  • pro-groupdir-fix - korekcja uprawnień danych w katalogu zespołu
  • pro-grant-jobs - lista zadań w ramach grantów użytkownika (zawiera także zadania innych członków grup grantowych użytkownika)

• Narzędzia systemu SLURM

  • squeue - lista aktualnie zakolejkowanych/uruchomionych zadań
  • scontrol show job [<ID_zadania>] - szczegóły zadania
  • sstat -a -j <ID_zadania>/<ID_zadania.batch> - zużycie zasobów w ramach kroków (step) działającego zadania
  • scancel <ID_zadania> - usunięcie zadania (działającego lub zakolejkowanego)
  • sacct - zużycie zasobów zakończonego już zadania/kroku
  • scontrol show partition [<nazwa_partycji>] - właściwości partycji
  • sinfo - lista węzłów
  • scontrol show node [<nazwa_węzła>] - właściwości węzła

Przenoszenie danych z klastra Zeus

Klastry Zeus i Prometheus nie współdzielą żadnych zasobów dyskowych, w związku z tym, aby korzystać z danych zgromadzonych na Zeusie, należy je najpierw skopiować. W tym celu możemy posłużyć się komendami:

• scp - w przypadku małych plików (używa loginu i hasła),
• globus-url-copy - w przypadku dużych plików (używa loginu i hasła LUB grid proxy),
• uberftp - w przypadku dużych plików, interaktywnie (używa grid proxy).

Podstawowe informacje o komendzie globus-url-copy:

• składnia: globus-url-copy ŻRÓDŁO CEL, gdzie źródło i cel poprzedzone są nazwą protokołu: np. file://,
• aby pobrać pliki z zeusa używamy 2 protokołów:
  • gsiftp - gsiftp://zeus.cyfronet.pl/ - uwierzytelnianie za pomocą proxy (musimy najpierw stworzyć grid proxy komendą grid-proxy-init),
  • sshftp - sshftp://zeus.cyfronet.pl/ - uwierzytelnianie hasłem PLGrid,
• uwierzytelnianie proxy pozwala uruchamiać wiele transferów bez podawania hasła za każdym razem,
• protokół docelowy to file:// czyli plik/katalog lokalny,
• dla ŻRÓDŁA i CELU musimy podać pełną ścieżkę pliku lub możemy użyć skrótu w postaci ~plgLOGIN do naszego katalogu domowego,
• dla CELU (czyli protokołu file://) możemy podać też zmienne środowiskowe np. $PWD - bieżący katalog,
• w przypadku CELU gdy podamy nazwę pliku np. $PWD/nazwa.txt, plik zapisze się pod daną nazwą, a gdy podamy tylko katalog, to plik zapisze się pod taką samą nazwą jak źródłowy,
• aby przesyłać całe katalogi, należy je najpierw spakować komendą tar -czf archiwum.tar katalog,
• w przypadku gdy nasz login na klastrze Prometheus różni się od tego na klastrze Zeus możemy użyć wyłącznie protokołu "sshftp://" a do ŹRÓDŁA należy dodać login na klastrze Zeus np. sshftp://MOJ_USERNAME@zeus.cyfronet.pl/.

Przykład użycia komendy globus-url-copy:

• skopiuj z katalogu domowego użytkownika plgLOGIN na klastrze Zeus, do bieżącego katalogu plik "bigfile.txt" i nadaj mu tą samą nazwę:

globus-url-copy sshftp://zeus.cyfronet.pl/~plgLOGIN/bigfile.txt file://$PWD/

• skopiuj plik "/mnt/gpfs/work/plgrid/groups/plggGROUP_NAME/bigfile.txt" z klastara Zeus do bieżącego katalogu:

globus-url-copy sshftp://zeus.cyfronet.pl//mnt/gpfs/work/plgrid/groups/plggGROUP_NAME/bigfile.txt file://$PWD/

• j.w. ale z podanym loginem z klastra Zeus (domyślnie używany jest taki sam użytkownik na jakiego jesteśmy zalogowani)

globus-url-copy sshftp://MOJ_USERNAME@zeus.cyfronet.pl//mnt/gpfs/work/plgrid/groups/plggGROUP_NAME/bigfile.txt file://$PWD/

Odnośniki do dodatkowych pomocy/dokumentacji:

• scp:
  • http://linux.die.net/man/1/scp
• globus-url-copy:
  • http://linux.die.net/man/1/globus-url-copy
  • http://toolkit.globus.org/toolkit/docs/4.0/data/gridftp/rn01re01.html
• uberftp:
  • http://linux.die.net/man/1/uberftp
  • https://twiki.opensciencegrid.org/bin/view/Documentation/StorageUberFtp
• grid-proxy-init
  • http://linux.die.net/man/1/grid-proxy-init
  • http://toolkit.globus.org/toolkit/docs/4.0/security/prewsaa/rn01re05.html

Zasady obowiązujące na klastrze Prometheus

• Obliczenia wykonywane na maszynie dostępowej będą usuwane bez ostrzeżenia. Maszyna dostępowa powinna służyć wyłącznie do przygotowywania plików wejściowych obliczeń i do ich zlecania na klaster za pośrednictwem systemu kolejkowego. Kopiowanie dużych ilości danych również może w znacznym stopniu obciążać maszynę dostępową, dlatego też zaleca się, aby kopiowanie przeprowadzać na węźle obliczeniowym (w zadaniu interaktywnym, np. srun -p plgrid -A grant_id -n 1 --pty /bin/bash -l). Podobnie jest z kompilacją programów - ją również należy wykonywać na węźle obliczeniowym, a nie bezpośrednio na maszynie dostępowej.
• Obliczenia wykraczające poza zakres deklarowanego tematu badań zużywające znaczną część zasobów klastra będą usuwane bez ostrzeżenia.
• Dane obliczeniowe należy składować i przetwarzać na systemie plików Lustre pod lokalizacją $SCRATCH.
• W obliczeniach nie należy korzystać z katalogu /tmp, do przechowywania plików tymczasowych należy wykorzystywać katalogi znajdujące się pod zmiennymi $SCRATCH, $SCRATCHDIR lub $TMPDIR.
• Na maszynie dostępowej ustawiony jest limit pamięciowy 6 GiB dla sumy wszystkich procesów danego użytkownika. Próba przekroczenia limitu powoduje automatyczne zabicie procesu próbującego przekroczyć ustalony limit.

Kontakt

Pomoc dla użytkowników PL-Grid: Helpdesk PL-Grid
Kontakt z administratorami: prometheus@cyfronet.pl, +48 12 632 33 55 w. 603