ВНИМАНИЕ: c 16.03.2022 запуск задач должен осуществляться в подкаталогах ~/_scratch и ~/_scratch2. Запись данных в другие подкаталоги домашнего каталога на вычислительных узлах будет заблокирована.
Каталоги ~/_scratch и ~/_scratch2расположены в отдельных системах хранения: _scratch — на параллельной файловой системе Lustre, _scratch2 — на SSD-дисках. Эти файловые системы также могут быть видны под именами /misc/home1/uXXXX — _scratch и /misc/home6/uXXXX — _scratch2, где uXXXX — логин пользователя.
При запуске задачи пользователя на счет
Запуск программ осуществляется в системе SLURM. Основные команды SLURM приведены в инструкциях ниже. Полная информация выдаётся с помощью команды man.
В результате запуска задача помещается в очередь заданий и ей присваивается уникальный идентификатор (JOBID). Его можно узнать командами mqinfo, mps или squeue, sacct.
На основе команд SLURM (которые начинаются с буквы s) для удобства пользователей (в частности, обеспечения преемственности при переходе на SLURM) были реализованы упрощённые команды запуска MPI-, MATLAB-, ANSYS-программ и информационные команды (начинающиеся с буквы m).
mqrun, замена mpirun, — запуск программы на кластере, аналог команды sbatch.
mqinfo — выдача информации об узлах и очереди заданий с помощью команд sinfo и squeue ( Пример выдачи sinfo из команд mqinfo и mps).mps или mqinfo -u $USER -l — выдача информации об узлах и задачах только самого пользователя.mqdel, mkill — отмена выполнения задачи (ожидающей старта или уже стартовавшей), действуют как команда scancel.
Команда mqrun (замена mpirun, аналог sbatch ) запускает в пакетном режиме успешно откомпилированную С- или Fortran-программу, например
mqrun -np 8 -maxtime 20 -stdin in.txt mytestгде для mytest затребовано формирование 8 процессов (опция -np или -n) с выделением каждому по умолчанию 1950 MB (т.е. -m 1950) и установкой входного файла (-stdin) при ограничении времени счета 20-ю минутами (–maxtime или –t). Так как не указаны опции -stdout и -stderr, то стандартными выходными файлами будут автоматически созданные mytest.1/output, mytest.1/error.
В ответ в строке вида Submitted batch job 1475 выдаётся уникальный идентификатор (JOBID) задачи в очереди заданий, здесь 1475. Уникальный идентификатор используется в командах отмены выполнения задания, например
mqdel 1475 #или mkill 1475Внимание!
1. В каталогах вида имя_программы.номер номера возрастают, начиная с 1. Пользователь должен сам удалять ненужные каталоги.
2. Для выдачи опций mqrun следует набрать
mqrun -help3. При необходимости можно указать опции команды sbatch в качестве значения параметра --slurm-opts команды mqrun, например:
mqrun -n 6 -nh 2 --slurm-opts '--ntasks-per-node=3 --gres=gpu:3 -x tesla[49,52]' ./testСистема SLURM позволяет с помощью команд sbatch и srun работать соответственно в пакетном и интерактивном режимах. Пакетный режим является основным в работе с кластером.
Команда sbatch для запуска программы в пакетном режиме имеет вид
sbatch [опции] --wrap="srun <имя программы> [параметры программы]"
или
sbatch [опции] <имя скрипта> [параметры скрипта]
Минимальный скрипт может выглядеть так
#!/bin/bash
srun myprogram param1 param2
Внимание!
Библиотека OpenMPI работает только с командой sbatch и при этом перед именем программы в опции --wrap или в скрипте вместо srun добавляется orterun:
sbatch [опции] --wrap="orterun <имя программы> [параметры программы]"
Команда srun для запуска интерактивной программы имеет вид
srun [опции] <имя программы> [параметры программы]
-n <число процессов> если число процессов (tasks) не задано, то по умолчанию n=1.
-t <время> при отсутствии заказа времени для решения задачи выделяется по умолчанию 30 минут. Максимальное время для счета задачи:
Время может быть задано в виде:
-N <кол-во узлов> задает число узлов (nodes) для задачи, если пользователю это важно.
Для увеличения оперативной памяти можно воспользоваться опциями:
--mem-per-cpu=<MB> задаёт минимальную память в расчёте на одно ядро в мегабайтах ; если не задано, то по умолчанию 1 ГБ;--mem=<MB> задаёт память на узле в мегабайтах.
Эти опции взаимно исключают друг друга.
--gres=gpu:<тип GPU>:<кол-во GPU> задаёт запуск программы на узлах с GPU. Если gres не задан, то количество GPU=0, т.е. GPU при счете не используются. Если не указан тип GPU, то автоматически назначается младшая модель (m2090). Типы GPU в 2024 году m2090, k40m, v100, a100.
-p <раздел> или --partition=<раздел> позволяет указать раздел (partition) кластера для запуска задачи.sinfo -s.
Если раздел не задан пользователем явно, то по умолчанию будет выбран раздел apollo, но при отсутствии в нем нужного числа свободных процессоров будет задействован раздел tesla.-p debug позволяет запускать задачи в специально выделенном для отладки программ разделе debug с максимальным временем счета 30 минут. Например, srun -p debug mytestОпции -w, -x, -С позволяют более гибко регулировать список узлов, допустимых для запуска задачи (см. man sbatch).
Например:
-w tesla[5-7,15] - выделить заданию ресурсы узлов tesla5, tesla6, tesla7, tesla15, а если на них не хватит, то и другие узлы;-x tesla22 - не выделять заданию ресурсы узла tesla22;-С a2017 - выделять задаче только те узлы, которые имеют ресурс с именем (Feature), указанным после -C. На кластере имеются ресурсы с именами: tesla, a2017, a2019 (поколения узлов); bigmem (узлы с большим объёмом ОЗУ), a100, v100 (модель GPU).
Информацию о том, какие ресурсы есть на конкретном узле, можно получить командой вида scontrol show node tesla22.Описание всех опций и примеры команд можно посмотреть в руководстве man с помощью команд:
man sbatch
man srun
По умолчанию стандартный вывод пакетной задачи и стандартный поток ошибок направляются в файл с именем slurm-%j.out, где %j заменяется уникальным идентификатором (номером) задачи. Перенаправление ввода-вывода можно выполнить, указав программе sbatch опции
--input=<filename pattern>--output=<filename pattern>--error=<filename pattern>При задании имени файла (filename pattern) можно использовать символы замены, в частности, %j заменяется на JobID, %t - на номер процесса в рамках задания. Таким образом file_%j_%t.txt при каждом запуске задачи сгенерирует уникальные имена для каждого процесса.
Выдаваемые результаты конкретной команды srun можно поместить вместо стандартного в указанный файл, добавив после команды символ перенаправления вывода >.
srun mytest > out_mytest &
Можно (чаще, при интерактивном запуске) параллельно просматривать результаты и сохранять их в файле, например:
srun --mem 40000 mytest | tee out_mytest
В результате интерактивного запуска программы hostname выдаётся имя узла, на котором запущен соответствующий процесс, например:
u9999@umt:~$> srun hostname
apollo5
При запуске в пакетном режиме команда запуска программы задаётся либо в скрипте, либо через опцию --wrap, например,
sbatch -n 2 --wrap="srun hostname"
или
sbatch mybat
где скрипт mybat:
#!/bin/sh
#SBATCH -n 2
srun hostname &;
wait
Внимание!
srun внутри скрипта может запрашивать ресурсы только в тех пределах, которые установлены командой sbatch.srun. При этом все опции, указанные в командной строке или самом скрипте в строках #SBATCH, приписываются к каждой команде srun данного скрипта, если не переопределены в ней. Так, результирующий файл приведённого примера будет содержать 2 строки с именами узлов (возможно, одинаковых), на которых выполнятся 2 процесса задачи, сформированные командой srun.& в конце строки), то они при наличии ресурсов могут выполняться одновременно.u9999@umt:~$ sbatch -n 3 --wrap="srun mytest1 3 5.1"
Submitted batch job 776
сформирована пакетная задача с запуском 3-х процессов mytest1 c 2-мя параметрами. Задаче присвоен уникальный идентификатор 776.
u9999@umt:~$ srun -N 2 sleep 30 &
[1] 22313
сформирована интерактивная задача в фоновом режиме. [1] - номер фоновой задачи в текущем сеансе, 22313 - pid процесса srun на управляющей машине. Уникальный идентификатор можно узнать с помощью команд squeue, sacct.
Все опции запуска описаны в batch-файле. За 60 секунд до окончания заказанного времени все процессы, запущенные через srun получат сигнал TERM и завершатся, после чего последняя команда в скрипте restart_sbatch снова поставит его в очередь. Перезапуск произойдёт и в том случае, когда программа, запущенная через srun завершится самостоятельно.
Опция --signal задаёт номер сигнала, который будет отправлен процессам (KILL) и время отправки сигнала (60 секунд до конца заказанного времени счёта).
Запуск
sbatch restart_sbatch
Содержимое restart_sbatch:
#!/bin/sh
#SBATCH -n 1 -t 180
#SBATCH --signal=KILL@60
srun myprog arg1 arg2
# здесь можно вставить анализ результатов,
# формирование новых параметров,
# проверку условий завершения
# и т.п.
sbatch ./restart_sbatch
Иногда бывает необходимо запустить на кластере интерактивную программу или подключиться к уже запущенной программе в интерактивном режиме (например для запуска отладчика). Ниже рассмотрено несколько вариантов запуска интерактивных программ.
Для взаимодействия с пользователем через текстовый интерфейс программа обращается к специальному устройству — псевдотерминалу (pseudo teletype, PTY). Для создания такого устройства на узлах необходимо указать команде srun опцию --pty.
В примере ниже для задачи выделено два узла, но интерактивный интерпретатор командной строки запущен только на первом из них.
[host]$ srun -n 36 -t 40 --pty bash
[node19]$ echo $SLURM_NODELIST
node[19,23]
Если вы работаете в графической среде XWindow (клиенты X2Go, Mobaxterm и т.п.), то по такой же схеме можно запускать на узлах задачи с графическим интерфейсом. Единственное отличие — при запуске надо добавить опцию --x11. По умолчанию графический вывод возможен с любого из выделенных узлов.
[host]$ srun -n 8 -N 1 -t 40 --pty --x11 matlab
Для подключения к уже запущенной задаче необходимо знать её идентификатор и список узлов. На кластере "Уран" для этого служит команда mps, которая разворачивается в команду squeue:
squeue -a -u $USER -o '%.9i %.5P %.8j %.8u %.20S %.4T %.9M %.9l %.5D %R
Получив идентификатор задания его можно указать в параметре --jobid. Дополнительно в параметре -w можно указать узел, к которому надо подключиться. По умолчанию выполняется подключение к первому из узлов.
Пример подключения к задаче отладчиком gdb:
[host]$ srun -p debug -n 36 -t 40 myprog &
[host]$ mps
JOBID PARTI NAME USER START_TIME STAT TIME TIME_LIMI NODES NODELIST(REASON)
10323407 debug bash user8 2020-06-25T10:48:45 RUNN 1:52 3:00 3 node[31-32,46]
[host]$ srun --jobid=10323407 -w node46 --pty bash
[node46]$ ps ax | grep myprog
9556 ? S+ 0:00 myprog
[node46]$ gdb -p 9556
Многие современные пакеты, такие как Jupiter Notebook или Tensor Board имеют встроенный веб-сервер, который обеспечивает взаимодействие с программой через веб-браузер. В этом случае возможно запустить сервер на узле, а браузер на хост-машине или на домашнем компьютере пользователя.
Запуск браузера на домашнем компьютере требует дополнительных настроек, связанных с пробросом портов, и здесь рассматриваться не будет.
Далее предполагается, что пользователь кластера использует подключение с поддержкой графической среды XWindow (клиенты X2Go, Mobaxterm и т.п.). Поскольку запускаемые скрипты требуют выполнения нескольких команд, они оформлены в виде файлов, которые могут запускаться как через srun, так и через sbatch.
В скриптах номера портов TCP выбираются на основе UID пользователя и базового смещения большего 1024. Это должно обеспечить возможность одновременного запуска скрипта на одном узле несколькими пользователями. Если порт случайно оказался занят, то можно поменять базу (в пределах 2000-20000) и попробовать запустить скрипт снова.
Для запуска Jupiter Notebook на узле, необходимо передать ему опцию --no-browser и IP адрес сетевой карты (иначе будет использован IP 127.0.0.1). Можно настроить авторизацию по паролю, отредактировав файл ~/.jupyter или выполнив команду jupyter notebook password, но авторизации по токену будет достаточно.
Скрипт запуска jupiter_slurm.sh
#!/bin/sh
#SBATCH -J jupiter_notebook # Job name
HOST=$(hostname -i)
unset XDG_RUNTIME_DIR
jupyter notebook --no-browser ---ip=$IP
Запустив скрипт и дождавшись сообщения с URL и токеном можно запустить браузер и подключиться к своему JupiterNotebook.
[host]$ srun -n1 -t60 jupiter_slurm.sh &
...
[I 11:59:00.782 NotebookApp] The Jupyter Notebook is running at:
[I 11:59:00.782 NotebookApp] http://192.168.100.19:8888/?token=e5044d65c85c7759e428667826fca80e96f6c3178e754931
[host]$ firefox http://192.168.100.19:8888/?token=e5044d65c85c7759e428667826fca80e96f6c3178e754931
Запуск Tensor Board в целом аналогичен запуску Jupiter Notebook. В отличие от Jupiter Notebook у Tensor Board нет парольной защиты, так что теоретически возможно подключение к вашей Tensor Board какого-то пользователя кластера. При необходимости, эта проблема будет решаться административным путём — отключением слишком любопытных пользователей.
Скрипт запуска tensorboard_slurm.sh
#!/bin/sh
#SBATCH -J tensor_board # Job name
HOST=$(hostname -i)
tensorboard --host=$HOST --logdir=$1
Запуск:
[host]$ srun -n1 -t60 tensorboard_slurm.sh ./mylogdir &
...
TensorBoard 2.2.1 at http://192.168.100.19:6006/ (Press CTRL+C to quit)<enter>
[host]$ firefox http://192.168.100.19:6006
u9999@umt:~$ sbatch -n 3 --wrap="srun myprog 3 5.1"
Submitted batch job 776
сформирована пакетная задача с запуском 3-х процессов mytest1 c 2-мя параметрами. Задаче присвоен уникальный идентификатор 776.
u9999@umt:~$ srun -N 2 sleep 30 &
[1] 22313
сформирована интерактивная задача в фоновом режиме. [1] - номер фоновой задачи в текущем сеансе, 22313 - pid процесса srun на управляющей машине. Уникальный идентификатор можно узнать с помощью команд squeue, sacct.
srun -n1 --cpus-per-task=12 myprog
Запуск одного процесса на одном узле с выделением ему 12 ядер.
Один процесс, которому выделена одна видеокарта модели K40m
srun -n1 -p tesla --gres=gpu:k40m:1 my_cuda_prog
Один процесс, которому выделена восемь видеокарт модели a100
srun -n1 -p hiperf --gres=gpu:a100:8 my_cuda_prog
Один процесс, которому нужна одна видеокарта модели v100 или a100
srun -n1 -p hiperf --gres=gpu:1 my_cuda_prog
Возможные варианты видеокарт в 2024 году: m2090, k40m, v100, a100
srun -n3 -С bigmem myprog
Свойством bigmem помечены узлы с памятью 192 Гбайт и более (96 Гбайт в разделе debug).
Все опции запуска описаны в batch-файле. За 60 секунд до окончания заказанного времени все процессы, запущенные через srun получат сигнал TERM и завершатся, после чего последняя команда в скрипте restart_sbatch снова поставит его в очередь. Перезапуск произойдёт и в том случае, когда программа, запущенная через srun завершится самостоятельно.
Опция --signal задаёт номер сигнала, который будет отправлен процессам (KILL) и время отправки сигнала (60 секунд до конца заказанного времени счёта).
Запуск
sbatch restart_sbatch
Содержимое restart_sbatch:
#!/bin/sh
#SBATCH -n 1 -t 180
#SBATCH --signal=KILL@60
srun myprog arg1 arg2
# здесь можно вставить анализ результатов,
# формирование новых параметров,
# проверку условий завершения
# и т.п.
sbatch ./restart_sbatch
squeue sacct sinfo scontrol характеристики GPU
squeue — просмотр очереди (информации о задачах, находящихся в счете или в очереди на счет); возможно использование ключей, например:
squeue --user=`whoami` # посмотреть только свои задачи;
squeue --states=RUNNING # посмотреть считающиеся задачи;
squeue --long # выдать более подробную информацию.
Пример
u9999@umt:~$ srun -N 2 sleep 30 &
[1] 22313
u9999@umt:~$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
777 all sleep u9999 R 0:23 2 umt[10,15]
sacct — просмотр задач текущего пользователя за сутки (с начала текущего дня);
возможно использование ключей, например:
sacct -u u9999 --starttime 2019-01-01 # посмотреть все задачи пользователя u9999 с начала года.
Пример
u9999@umt:~$ sacct
JobID JobName Partition AllocCPUS State ExitCode
--------- ---------- ---------- ------------ ------------- --------
522 sbatch tesla 2 COMPLETED 0:0
522.batch batch 1 COMPLETED 0:0
777 sleep all 2 CANCELLED+ 0:0
780 sbatch tesla 2 FAILED 0:0
780.batch batch 1 FAILED 127:0
783 sleep tesla 2 RUNNING 0:0
sinfo — просмотр информации об узлах (прежде всего, о состоянии узлов: доступны, заняты, свободны, ...);
возможно использование ключей, например:
sinfo -s # выдача суммарной информации о разделах кластера без детализации по узлам.
Пример
u9999@umt:~$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
umt* up 8:00:00 4 down* umt[59,92,139,201]
umt* up 8:00:00 203 idle umt[1-58,60-91,93-118,120-138,140-200,202-208]
umt* up 8:00:00 1 down umt119
tesla up 8:00:00 1 alloc tesla2
tesla up 8:00:00 18 idle tesla[3-20]
tesla up 8:00:00 1 down tesla1
Пример выдачи sinfo из команд mqinfo и mps:
PARTITION SOCKET CORE CPU THREAD GRES TIMELIMIT CPUS(A/I/O/T)
umt 2 4 8 1 20:00:00 1203/53/408/1664
tesla 2 6 12 1 gpu:8 infinite 322/2/36/360
all* 2 4+ 8+ 1 20:00:00 1525/55/444/2024
scontrol — выдача детальной информации об узлах, разделах, задачах:
scontrol show node tesla34 # информация об узле,
в частности, причине состояния drain, down;
scontrol show partition # о разделах;
scontrol show job 174457 # о задаче.
Информацию о технических характеристиках GPU выдает программа nvidia-smi:
srun --gres=gpu:1 nvidia-smi
Опция вида -w tesla21 позволяет выдать эту информацию для конкретного узла, например:
u9999@umt:~$ srun -w tesla21 --gres=gpu:1 nvidia-smi
Fri Jun 14 17:15:57 2019
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.46 Driver Version: 390.46 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Tesla M2090 On | 00000000:09:00.0 Off | Off |
| N/A N/A P12 28W / N/A | 0MiB / 6067MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
| 1 Tesla M2090 On | 00000000:0A:00.0 Off | Off |
| N/A N/A P12 27W / N/A | 0MiB / 6067MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
| 2 Tesla M2090 On | 00000000:0D:00.0 Off | Off |
| N/A N/A P12 28W / N/A | 0MiB / 6067MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
| 7 Tesla M2090 On | 00000000:33:00.0 Off | Off |
| N/A N/A P12 28W / N/A | 0MiB / 6067MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
Дополнительная информация о характеристиках GPU доступна с помощью программы pgaccelinfo (входит в поставку компилятора PGI). Для получения информации о конкретном узле, используя опцию -w, следует набрать:
u9999@umt:~$ mpiset 7
u9999@umt:~$ srun -w tesla21 --gres=gpu:1 pgaccelinfo
При запуске на кластере задача попадает в очередь заданий и ей присваивается уникальный идентификатор (ID). Для отмены выполнения задачи (ожидающей счета или уже стартовавшей) служит команда scancel:
scancel 565 345 # убрать из очереди задачи с указанными ID;
scancel -u u9999 # убрать из очереди все задачи пользователя u9999;
scancel --state=PENDING -u u9999 # убрать из очереди ожидающие запуска задачи пользователя u9999.
CTRL+C— снимает интерактивную задачу без фонового режима.
Пример. Снятие интерактивной задачи, запущенной в фоновом режиме.
u9999@umt:~$ srun -p tesla -N 2 sleep 1h &
[1] 13847
u9999@umt:~$ mps
PARTITION SOCKET CORE CPU THREAD GRES TIMELIMIT CPUS(A/I/O/T)
umt 2 4 8 1 20:00:00 0/0/768/768
umt_p2 2 4 8 1 20:00:00 0/0/512/512
tesla 2 6+ 12+ 1 gpu:8 20:00:00 234/2/12/248
...
JOBID PARTI NAME USER STAT TIME TIME_LIMI NODES NODELIST(REASON)
7650963 tesla sleep u9999 RUNN 0:21 30:00 2 tesla[2,4]
Завершаем задачу:
u9999@umt:~$ scancel 7650963
srun: Force Terminated job 7650963
u9999@umt:~$ srun: Job step aborted: Waiting up to 32 seconds for job step to finish.
slurmstepd: error: *** STEP 7650963.0 ON tesla2 CANCELLED AT 2019-08-20T12:59:13 ***
srun: error: tesla4: task 1: Terminated
srun: error: tesla2: task 0: Terminated
Надо нажать Enter
[1]+ Exit 143 srun -p tesla -N 2 sleep 1h
u9999@umt:~$ mps
PARTITION SOCKET CORE CPU THREAD GRES TIMELIMIT CPUS(A/I/O/T)
umt 2 4 8 ...
JOBID PARTI NAME USER STAT TIME TIME_LIMI NODES NODELIST(REASON)
u9999@umt:~$
Технология Docker позволяет создавать виртуальную среду исполнения. По сравнению с виртуальными машинами накладные расходы на виртуализацию составляют менее 1%.
С точки зрения пользователя данная технология даёт возможность настраивать среду исполнения и воспроизводить ее на разных компьютерах. Внутри контейнера у пользователя имеются права суперпользователя, что позволяет устанавливать необходимые пакеты без привлечения администратора кластера. Кроме того, Docker может работать с графическими ускорителями, что является очень полезным, например, при работе с библиотеками глубинного обучения.
Стандартная реализация Docker, позволяет пользователю получить права суперпользователя на хостовой машине, что неприемлемо с точки зрения безопасности. Поэтому на кластере используются альтернативная реализация — podman, которая устраняет данный недостаток. Podman имеет ряд особенностей, о которых будет написано ниже.
Для общего понимания технологии Docker можно ознакомиться с шестью статьями на Хабре.
Пользовательская конфигурация podman хранится в каталоге ~/.config/container. Стандартное размещение данных— ~/.local/share/container, но, поскольку podman не совместим с файловой системой NFS, то на кластере для хранения образов используется локальный каталог /tmp. Это значит, что копии каждого используемого образа будут создаваться по мере необходимости в каталоге /tmp на каждом вычислительном узле. Соответственно, не стоит использовать копирование входных/выходных данных между контейнером и домашним каталогом. Лучше использовать монтирование домашнего каталога внутрь образа при запуске с помощью опции -v $HOME:$HOME
Конфигурация хранилища данных для каждого пользователя кластера описана в ~/.config/containers/storage.conf и имеет вид
[storage]
driver = "vfs"
runroot = "/tmp/u9999_run"
graphroot = "/tmp/u9999_storage"
[storage.options]
mount_program = ""
где u9999 надо заменить на свой логин
В конфигурации podman на кластере "Уран" в файле /etc/containers/registries.conf подключены публичные реестры registry.access.redhat.com, docker.io, registry.fedoraproject.org, quay.io, registry.centos.org и локальный реестр 172.16.0.1:5000. Если требуется добавить свое хранилище или убрать поиск в вышеперечисленных, то можно скопировать конфигурационный файл в свой каталог ~/.config/container/ и отредактировать копию.
На одном из компьютеров кластера по адресу 172.16.0.1:5000 организован локальный Docker-реестр, который может быть использован пользователями кластера для хранения своих образов. ВНИМАНИЕ. Доступ к реестру осуществляется без авторизации и поэтому есть небольшой риск, что кто-то испортит или удалит ваш образ.
При подготовке образа рекомендуется предварительно произвести сборку на локальной машине и убедится в корректности Dockerfile. Сборка контейнера с использованием podman происходит дольше, чем с использованием стандартного docker. Поэтому желательно осуществлять сборку контейнеров на узлах кластера с помощью планировщика SLURM. Для этого можно выполнить команду:
srun -c 8 --mem 10000 --pty bash
В результате мы попадём на один из вычислительных узлов, на котором можно выполнять сборку. Команда сборки запускается из каталога, где находится Dockerfile и должна иметь примерно следующий вид:
docker build -t <tag> <directory>
Пример
docker build -t hello_docker .
Важно понимать, что после сборки контейнер будет находиться в каталоге /tmp на узле, на котором производилась сборка. Чтобы контейнер можно было использовать на других узлах, его необходимо скопировать в общественное хранилище на кластере с помощью следующей команды:
docker push --tls-verify=false localhost/hello_docker 172.16.0.1:5000/hello_docker
Также обе команды можно выполнить за одной задачей, выполнив:
srun -c 8 --mem=10000 bash -c 'docker build -t hello_docker . && docker push --tls-verify=false localhost/hello_docker 172.16.0.1:5000/hello_docker
ВАЖНО. Так как на общественном хранилище не настроена авторизация, то при создании контейнеров необходимо использовать уникальные имена, например, используя в качестве префикса имя пользователя.
Минимальный Dockerfile приведен в приложении 1. Bash скрипт для сборки и загрузки контейнера в общее хранилища приведен в приложении 2.
Запуск осуществляется следующей командой:
srun -c 8 --mem=10000 docker run -v ~:/work -t hello_docker ls /work
если образ на узле отсутствует, то он будет подтянут из реестра автоматически. При следующих запусках на том же узле будет повторно использована сохраненная на этом узле копия образа.
В данном случае опция -v ~:/work указывает на то, что домашний каталог пользователя будет смонтирован в каталог /work внутри контейнера. Если в вашей программе или скриптах используется путь к домашнему каталогу, то можно попробовать другой вариант -v $HOME:$HOME, который смонтирует домашний каталог в контейнере под тем же именем, под которым он виден вне контейнера.
Вместо команды ls /work может присутствовать любая другая команда с параметрами.
При запуске можно добавить в образ дополнительные библиотеки:
srun -c 8 --mem=10000 docker run -v ~:/work -v /common/user/gpu_libs:/gpu_libs -e LD_LIBRARY_PATH=/gpu_libs -t hello_docker ls /work
Bash скрипт для запуска контейнера с использованием GPU приведен в приложении 3.
FROM ubuntu:18.04
VOLUME /work
WORKDIR /work
CMD ['ls']
CONTAINER_NAME=hello_docker
docker build -t $CONTAINER_NAME .
docker push --tls-verify=false localhost/$CONTAINER_NAME 172.16.0.1:5000/$CONTAINER_NAME
CONTAINER_NAME=hello_docker
docker pull --tls-verify=false 172.16.0.1:5000/$CONTAINER_NAME
CUDA=""
if [ -e /dev/nvidiactl ]; then
DEVICES=(/dev/nvidia*)
CUDA=${DEVICES[@]/#/--device }
fi
docker run $CUDA -v ~:/work -t $CONTAINER_NAME ls /work
$> srun -n 1 --mem=10000 --output=quad.txt docker run -v $HOME:$HOME -ti tkralphs/coinor-optimization-suite cbc $HOME/coin-or/Cbc/examples/quad.mps
$> less quad.txt
Trying to pull 172.16.0.1:5000/tkralphs/coinor-optimization-suite...
manifest unknown: manifest unknown
Trying to pull registry.access.redhat.com/tkralphs/coinor-optimization-suite...
name unknown: Repo not found
Trying to pull docker.io/tkralphs/coinor-optimization-suite...
Getting image source signatures
Copying blob sha256:14f491cdf5e5dfff3f9296e85ea5f0ed7ed792a0df58fd753e5a53aa72dda67f
Copying blob sha256:53e3366ec435596bed2563cc882ba47ec25df6be2b1027e3243e83589c667c1e
Copying blob sha256:ee690f2d57a128744cf4c5b52646ad0ba7a5af113d9d7e0e02b62c06d35fd14c
Copying blob sha256:e92ed755c008afc1863a616a5ba743b670c09c1698f7328f05591932452a425f
Copying blob sha256:c596d3b2f1a98fc3d58eb98ff4de80a9bd7c50f8118e89189ec25c1b4c9678cb
Copying blob sha256:b9fd7cb1ff8f489cf082781b0e1fe0c13b840e20147e8fc8204b4592da7c2f70
Copying blob sha256:891eb02d766a3e5408f240128347472983067be41493f1a10cf6216574f614f0
Copying blob sha256:42f559670afb72a15465e2a0785122587c284f0cbfb7b7883bc0f27e6e999a32
Copying blob sha256:87ef252adc7d4cab8eae16d70cc529d70c857d964309e13c3a9d64b6b49670d8
Copying blob sha256:8f85d5b3b6ecc7367bb8186917017bcba3d916c08ffcea240b896b2e562fe0fa
Copying blob sha256:38e446e2e1f2ec785a4ad5e49af8cfcd34027a915c3b5d40732eeb65f66b5019
Copying config sha256:c9697bd9dae0a80bf39e3feca37bc7b4ef9a6efa03269870cb7d15f51426999c
Writing manifest to image destination
Storing signatures
....
1. Структура python-скрипта
Здесь предполагается, что python-скрипт - это текст программы, написанной на языке, понимаемом интерпретатором python соответствующей версии, и начинающейся со строки следующего вида с заменой 'N.N' на номер версии (например, на 3 или на 3.9).
#!/usr/bin/env pythonN.N
В этом случае имя python-скрипта может быть непосредственно передано команде sbatch в качестве имени исполняемого файла для постановки задачи на выполнение на вычислительных узлах кластера. После первой строки могут быть добавлены строки вида #SBATCH ... с заказом требуемых задаче ресурсов (см. man sbatch).
2. Каталог ~/.local
При использовании python надо понимать, что на вычислительных узлах разрешено писать лишь в подкаталоги каталогов ~/_scratch и ~/_scratch2, а некоторые модули python используют каталог ~/.local
для записи временных подкаталогов и файлов. Значит, перед использованием python (в частности, до установки своих модулей) следует убедиться, что каталог ~/.local - это ссылка на ~/_scratch/.local, выполнив команду ls -l ~/.local. Если это не так, то нужно переместить каталог ~/.local в одну из указанных папок, выполнив, например, команды
mv ~/.local ~/_scratch/
ln -s ~/_scratch ~/.local
3. Установка новых модулей к имеющимся версиям python
На кластере "Уран" установлено несколько версий python. В силу того, что некоторые модули системы python требуют настройки на конкретные версии системного ПО кластера, установка необходимых дополнительных модулей python осуществляется самим пользователем в зависимости от потребностей запускаемых им программ.
При использовании менеджера пакетов pip (см. man pip) для установки недостающих пакетов следует указывать опцию --user, чтобы дополнительные пакеты устанавливались в специальный каталог конкретного пользователя и не влияли на работу других пользователей, и, вызывать версию pip, соответствующую используемой версии python.
Пример:
pip3.9 install --user mpi4py
4. Работа с именованными виртуальными средами выполнения (virtual environment)
Создание виртуальных сред выполнения (комплектов пакетов) и переключение на работу с ними рекомендуется осуществлять через менеджеры пакетов conda или mamba, а также с помощью специальных скриптов, обеспечивающих такую настройку.
Так команда
source /opt/intelpython39/bin/activate
переключает на работу с относительно свежей версией python3.9 с установленными дополнительно библиотеками pandas, jupyter, scikit-image, h5py, pillow, networkx, protobuf и opencv. Для работы программ, использующих видеокарты для машинного обучения, в этой версии python также установлены pytorch, tensorflow, keras, которые собраны на базе cuda 11.8. Кроме того, будет доступен менеджер пакетов mamba.
Модуль mpi4py делает возможным формирование нескольких mpi-процессов с обменом сообщениями (данными) между ними даже тогда, когда они выполняются на разных вычислительных узлах (см. https://mpi4py.readthedocs.io/en/stable/tutorial.html).
Например, команда
pip3.9 install --user mpi4py
установит пакет mpi4py в подкаталог .local домашнего каталога пользователя. После этого при выполнении python-скрипта со строкой
from mpi4py import MPI
утилита python3 найдёт установленный модуль (при условии, что python3 эквивалентно python3.9).
На вычислительных узлах модуль mpi4py будет правильно стыковаться с нужной реализацией MPI, если перед запуском выбрать (командами mpiset ... или module switch ...) конкретную реализацию стандарта MPI, отличную от openmpi, и задать предварительную загрузку соотвествующей библиотеки, задав её имя в переменной LD_PRELOAD, например, выполнив команду
export LD_PRELOAD=`libmpi_name.sh`
Постановка в очередь таких python-скриптов осуществляется командами, подобными упрощённой
mqrun -n 4 -t 5 ./testmpi.py
или базовой
sbatch -n 4 -t 5 -J test --wrap='srun ./testmpi.py'
Здесь srun необходима для формирования группы из заданного числа MPI-процессов.
Предполагается, что предварительно было выполнено
cd ~/_scratch/tests
и скрипт ./testmpi.py находится в каталоге ~/_scratch/tests.
Модуль pymp устанавливается командой
pip install --user pymp-pypi
и позволяет, добавив специальные строки в python-скрипт по аналогии с декларациями OpenMP в C- и fortran-программах, образовать несколько подпроцессов с имитацией общих массивов данных, например, для ускорения выполнения длительного цикла за счёт привлечения дополнительных вычислительных ядер процессора (см. https://github.com/classner/pymp ).
Понятно, что такие python-скрипты должны выполняться лишь на одном вычислительном узле, так как массивы переменных (располагающиеся в оперативной памяти) должны быть доступны всем подпроцессам. В команде постановки в очередь необходимо указать дополнительно количество вычислительных ядер на подзадачу
sbatch -n 1 --cpus-per-task=4 -t 5 -J test ./testmp.py
Предполагается, что предварительно было выполнено
cd ~/_scratch/tests
и скрипт ./testmp.py находится в каталоге ~/_scratch/tests.
1. Размер дисковой квоты для пользователей ограничен 100 GB.
Уточнить размер квоты и места на диске, занимаемого пользователем, можно с помощью команд quotacheck и du (см. инструкцию Базовые команды ОС UNIX).
Внимание! Возможно появление ошибок при запуске задач, если квота дискового пространства исчерпана. Рекомендуется удалять ненужные файлы, а нужные результаты переписывать на свою машину. Так будет надежнее, т.к. гарантии сохранности файлов на кластере нет.
2. Одновременно считающиеся задачи пользователя могут занимать до 1024 CPU (вычислительных ядер).
3. Максимальное время, выделяемое для счета задачи:
20 часов - в будние дни,
85 часов - на выходные,
100 часов - на выходные с праздниками.
Если пользователь не закажет время, то по умолчанию для решения задачи будет выделено 30 минут. (Подробнее в инструкции Команды запуска SLURM) .
Замечание.
Дополнительная информация об ограничениях может выдаваться при входе на кластер.
В системе SLURM предусмотрено деление пользователей на учётные группы (account). Каждая учётная группа - это совокупность пользователей, работающих над одним проектом. На основе активности учётной группы определяются приоритеты для всех её членов. Затраты машинного времени членов учётной группы автоматически суммируются в статистике.
С 2019 года в СКЦ ИММ УрО РАН введены учётные группы на основе источников финансирования, указанных в заявках и договорах. Такое деление позволяет уравнять приоритеты организаций, которые подали в заявках информацию об одном-двух пользователях суперкомпьютера, с группами, которые включают большое количество пользователей.
Пользователь может состоять в нескольких учётных группах и запускать задачи от их имени. Одна учётная группа пользователя считается группой по умолчанию и используется в тех случаях, когда пользователь не указывает явно группу при запуске задачи.
Для смены учётной группы, используемой по умолчанию командами запуска задач, можно выполнить команду macctmgr. Для явного указания учётной группы в командах srun и sbatch используйте опцию -A <имя_группы>.
Просмотр учётных групп производится командой sacctmgr, просмотр статистики работы - командой sreport.
$ sacctmgr show -s user u9999 format=user,defaultaccount%30,account%30,qos
User Def Acct Account QOS
---------- ------------------------------ ------------------------------ --------------------
u9999 imm-2019-1 2019-99-19 restricted
u9999 imm-2019-1 imm-2019-2 normal
u9999 imm-2019-1 imm-2019-1 normal
u9999 - имя пользователя.-s указывает, что надо выдать связанные с пользователем учётные группыformat= задает список полей (и их ширину через %)В данном случае, пользователь u9999 входит в три учетные группы - 2019-99-19, imm-2019-1, imm-2019-2. По умолчанию используется группа imm-2019-1.
Поле QOS (quality of service) описывает ограничения, накладываемые на сочетание пользователь + учётная группа. normal - обычные ограничения, restricted - запуск задач запрещён.
sacctmgr show -s user $USER format=user,defaultaccount%30,account%30,qos
Явно указать учётную группу при запуске через srun или sbatch можно с помощью опции-A или --account=
srun --account=2019-99-19 myprog
srun -A 2019-99-19 myprog
$ sacctmgr show account imm-2019-1 format=account%15,description%30,organization
Account Descr Org
--------------- ------------------------------ ------
imm-2019-1 АААА-А19-999999999999-1 imm
В поле description вносится описание учётной группы, как правило в виде номера регистрации проекта в РосРИД или номера договора с ИММ УрО РАН.
$ sreport cluster AccountUtilizationByUser start=2019-01-01 end=2019-06-01 user=u9999
Usage reported in CPU Minutes
----------------------------------------------------------------
Cluster Account Login Proper Name Used Energy
--------- ----------- ------ --------------- -------- --------
umt imm-2019-2 u9999 TestUse+ 9437 0
umt imm-2019-1 u9999 TestUse+ 4442 0
В отчёт попадают только реально использовавшиеся группы.
$ sreport cluster AccountUtilizationByAccount start=2019-01-01 end=2019-06-01 account=imm-2019-1
--------------------------------------------------------------------------------
Usage reported in CPU Minutes
--------------------------------------------------------------------------------
Cluster Account Login Proper Name Used Energy
--------- ----------- ------ ------------ ---------- --------
umt imm-2019-1 27411385 0
umt imm-2019-1 u9990 User1 266 0
umt imm-2019-1 u9991 User2 6098924 0
umt imm-2019-1 u9992 User3 7431731 0
umt imm-2019-1 u9999 User4 13880463 0
Для выбора компиляторов, библиотек обмена сообщениями и пакетов прикладных программ, необходимых для работы программы пользователя, используются модули установки переменных окружения.
Команда mpiset позволяет выбрать модуль из списка основных модулей, задающих компилятор и версию библиотеки MPI.
Команда mpiset без параметров выдает пронумерованый список доступных вариантов. Строка, помеченная словом active, указывает на текущие настройки.
Для смены модуля (библиотеки MPI, компилятора) необходимо выполнить команду
mpiset <n>
где <n> – номер варианта настроек для данного кластера.
Пример. Список основных вариантов настроек, полученный в начале сеанса 28.12.2016 командой mpiset на кластере "Уран":
active 1 MVAPICH2 Intel 14.0, mvapich2/intel64
2 OpenMPI Intel 11.1, openmpi/intel64
3 OpenMPI 32bit GCC 4.4, openmpi/gcc32
4 OpenMPI 32bit Intel 14.0, openmpi/intel32
5 OpenMPI GCC v4.4, openmpi/gcc64
6 OpenMPI v1.10 GCC 4.8, openmpi/gcc64_1.10
7 MVAPICH2 2.1 PGI 16.5, mvapich2/pgi_16.5
8 Intel MPI Intel Compiler 17.0, intelmpi/intel64
При работе на кластере можно использовать различные компиляторы, библиотеки обмена сообщениями и пакеты прикладных программ (приложения), поэтому пользователь должен определить среду для решения своей задачи, выбрав нужное программное обеспечение. Выбор определяется модулем установки переменных окружения, требуемых для работы программы. Названия модулей содержат имена компиляторов, библиотек, пакетов, номера версий. Например, при загрузке модуля openmpi/intel64 программа пользователя будет откомпилирована 64-разрядным компилятором intel с библиотекой openmpi.
Список загруженных на настоящий момент модулей можно выдать с помощью команды module list.
Сервисная команда mpiset служит для быстрой смены модуля, задающего компилятор и версию библиотеки MPI.
Списки доступных модулей на кластерах могут отличаться и пополняться с введением нового программного обеспечения.
Пример. Список модулей, доступных на кластере umt на 01.07.2011, выданный с помощью команды module avail
OpenFoam/1.7.x matlab/R2010b openmpi/gcc64
dvm/current mpi/default openmpi/intel64
firefly/71g-openmpi music/4.0 paraview/3.10
matlab/R2010a mvapich2/intel64 towhee/6.2.15
В целом, работа с модулями обеспечивается командой module.
module avail - вывод на экран списка доступных модулей;module list - вывод на экран списка загруженных (на данный момент) модулей;module show <имя модуля из списка> - вывод на экран полного имени файла с описанием команд изменения окружения, выполняемых при загрузке модуля;module whatis <имя модуля из списка> - вывод на экран комментария к модулю;module whatis - вывод на экран списка модулей с комментариями;
module load <имя модуля из списка> - загрузка модуля; после выполнения данной команды (из командной строки или конфигурационного файла) среда исполнения будет настроена на использование программного обеспечения, соответствующего указанному модулю;
module unload <имя загруженного модуля> - выгрузка модуля отменит настройки переменных окружения, задаваемых данным модулем;module switch <имя загруженного модуля> <имя модуля> - замена загруженного модуля (первого) на указанный модуль (второй);module clear - выгрузка всех загруженных на текущий момент модулей.Внимание!
mpiset или module имеет силу на текущий сеанс работы на кластере.$HOME/.bash_profile пользователя, используя следующие команды:module initadd <имя модуля из списка доступных> - меняет $HOME/.bash_profile, загружая указанный модуль для следующих сеансов работы;module initlist - выдаёт список загруженных в $HOME/.bash_profile модулей для следующих сеансов работы;module initclear - чистит $HOME/.bash_profile, оставляя лишь модуль null, который не содержит никаких настроек.OpenMP подключается опцией, соответствующей установленному компиляторy:
gcc/gfortran -fopenmp GNU
icc/ifort -openmp Intel (по умолчанию на umt)
pgcc/pgCC/pgf77/pgfortran -mp PGI
Так, компиляция файла exam.c на umt компилятором Intel (с учетом умолчания) выполняется командой
icc -openmp exam_omp.c -o exam_omp
или командой
mpicc -openmp exam_omp.c -o exam_omp
Число параллельных нитей OpenMP задается с помощью переменной окружения OMP_NUM_THREADS. Как правило, она устанавливается перед запуском программы из командной строки командой вида
export OMP_NUM_THREADS=8
Если число нитей больше числа выделенных процессу ядер, то, по крайней мере, одно ядро будет исполнять более одной нити, что целесообразно, например, в случае, когда часть нитей имеет меньшую вычислительную активность.
При запуске приложения пользователю необходимо указать число ядер (cpus) для каждого из процессов (task) с помощью опции --cpus-per-task=<ncpus>. При этом система предоставляет узел для процесса, если на нем имеется указанное число свободных ядер. Максимальное число ядер, равное 36, содержат узлы раздела apollo (см. Кластер "Уран"). Пусть задано export OMP_NUM_THREADS=12, тогда в результате выполнения команды интерактивного запуска
srun --cpus-per-task=6 exam_omp > exam_omp.out
одному (n=1 по умолчанию) процессу (task), т.е. задаче, пользователя будет выделено 6 ядер на узле и при вычислениях будет задействовано 12 нитей; результаты вычислений будут записаны в указанный пользователем файл exam_omp.out.
Если программе нужен запуск на узле с большим объёмом оперативной памяти, то надо добавить опцию --mem=<MB>, где <MB> - требуемый объём памяти на узле. Например, команда
srun --mem=48G --cpus-per-task=12 exam_omp > exam_omp.out
запустит один процесс на узле с оперативной памятью не меньшей, чем 48 GB (о типах узлов см. Кластер "Уран"). Для заказа памяти из расчета на одно ядро используется опция --mem-per-cpu=<MB>, например,
srun --mem-per-cpu=4G --cpus-per-task=12 exam_omp > exam_omp.out
В пакетном режиме соответствующий запуск может выглядеть так:
sbatch --mem-per-cpu=4G --cpus-per-task=12 mybat_omp
где файл mybat_omp содержит строки
#!/bin/sh
srun exam_omp > exam_omp.out
В качестве примера программы с OpenMP можно использовать pi_omp.c.
Возможен запуск гибридных MPI/OpenMP приложений с помощью опции --ntasks-per-node=<ntasks>, где <ntasks> - число процессов на узле. Например, для запуска на двух 36-ядерных узлах 6 процессов с 12 нитями каждый можно выполнить команду:
sbatch -N 2 --cpus-per-task=12 --ntasks-per-node=3 my_bat_omp
ИММ УрО РАН предоставляет пользователям системы Matlab (Матлаб) возможность организации параллельных вычислений на кластере "Уран".
Подробная информация представлена в полной инструкции "Параллельный Matlab".
Число лицензий для вычислений на кластере в настоящее время равно 1000.
Запускать программы на кластере можно из командной строки или из системы Matlab. Для этого на своем компьютере следует установить программу PuTTY и какой-нибудь X-сервер.
Параллельные вычисления на кластере инициируются
1) запуском параллельных програм;
2) запуском частично параллельных программ (c parfor или spmd);
3) запуском программ с использованием GPU.
Программа пользователя должна быть оформлена как функция (не скрипт) и находиться в начале одноименного файла.
Файл должен иметь расширение "m"(например, my_function.m).
При запуске программы-функции указывается необходимое для счета число параллельных процессов и максимальное время выполнения в минутах.
Запуск программ на кластере из командной строки осуществляется с помощью команд:mlrun - для параллельных программ, например,
mlrun -np 8 -maxtime 20 my_parfunctionгде 8 - число копий функции my_parfunction, 20 - максимальное время счета в минутах;
mlprun - для частично параллельных программ (с parfor или spmd), например,
mlprun -np 8 -maxtime 20 my_poolfunctionгде один процесс будет выполнять программу-функцию, а оставшиеся 7 будут использованы в качестве пула для выполнения parfor и spmd;
mlgrun - для программ с использованием GPU, например,
mlgrun -np 8 -maxtime 20 my_gpufunctionгде 8 - число процессов (копий функции), каждый из которых может использовать свое GPU.
Запуск программ на кластере из окна системы Matlab осуществляется с помощью соответствующих служебных функций:imm_sch - для параллельных программ, например,
job1 = imm_sch(8,20,@my_parfunction);
imm_sch_pool - для частично параллельных программ (с parfor или spmd), например,
job2 = imm_sch_pool(8,20,@my_poolfunction);
imm_sch_gpu - для программ с использованием GPU, например,
job3 = imm_sch_gpu(8,20,@my_gpufunction);
В приведенных командах запускаются функции без параметров с использованием 8 процессов, 20 минут - максимальное время счета;
job1, job2, job3 - ссылки на созданные системой Matlab объекты Job (работа). Имя функции можно набрать с символом "@" или в кавычках.
Пример. Для функции с параметрами, например rand, вызываемой для генерации 2х3 матрицы случайных чисел с числом процессов 4 и максимальным временем счета 5 минут, следует соответственно набрать в командной строке
mlrun -np 4 -maxtime 5 rand '1,{2,3}'или в окне Matlab
job = imm_sch(4,5,@rand,1,{2,3});Подробнее в Параллельный Matlab/Запуск параллельной программы/Пример запуска программы.
В результате запуска программа ставится в очередь на счет и, если ресурсов кластера достаточно, входит в решение.
Пользователь может контролировать прохождение своей программы через систему запуска как в окне системы Matlab с помощью Job Monitor, так и из командной строки с помощью команд системы запуска.
ANSYS - это программный пакет конечно-элементного анализа, решающий задачи в различных областях инженерной деятельности (прочность конструкций, термодинамика, механика жидкостей и газов, электромагнетизм), включая связанные многодисциплинарные задачи (термопрочность, магнитоупругость и т.п).
ANSYS CFX, ANSYS Fluent – самостоятельные программные продукты от ANSYS,Inc., предназначенные для решения стационарных и нестационарных задач механики жидкостей и газов.
/common/runmvs/bin/ansysrun в настоящее время используется для запуска ansys145, cfx5solve и fluent.
Вызов ansysrun без параметров выдает краткую информацию об использовании.
Внимание!
Команды настройки переменных окружения содержатся в файле /common/runmvs/conf/ansys_env.sh, поэтому строка
. /common/runmvs/conf/ansys_env.shдолжна быть в ~/.bashrc.
При отсутствии этой строки выдается диагностика и постановки задания в очередь не происходит.
Примеры.
Запуск ansys145 с 12-ю процессами на 60 минут для выполнения ANSYS-скрипта ansys_s1:
ansysrun -np 12 -maxtime 60 -stdin ansys_s1 ansys145
Запуск на 30 минут ansys145 с 8-ю процессами и использованием GPU с соответствующим увеличением памяти до 3 ГБ (на один процесс) для выполнения ANSYS-скрипта ansys_s2:
ansysrun -np 8 -gpu 8 -m 3G -maxtime 30 -stdin ansys_s2 ansys145
Запуск cfx5solve по 6 (=np/nh) процессов на двух узлах на 100 минут для выполнения bench.def (def-файл ANSYS):
ansysrun -np 12 -nh 2 -maxtime 100 cfx5solve -def bench.def
Запуск fluent c 16 процессами на 400 минут для выполнения my.cav (cav-файл ANSYS) с дополнительным параметром 3ddp:
ansysrun -np 16 -maxtime 400 fluent 3ddp -i my.cav1. Quick Start User Guide / Slurm, Documentation.
2. Общие принципы построения системы SLURM. Берсенев А.Ю. / Семинар ОСО, 13.04.2011.
3. Обзор планировщиков для SLURM. Берсенев А.Ю. / Семинар ОСО, 20.04.2011.
4. Оптимизация управления ресурсами суперкомпьютеров с помощью SLURM. M. Тим Джонс, 18.10.2012.
5. Инструкция Slurm для пользователя. Краткое руководство по запуску / Суперкомпьютер ИК НАН Украины