Проект

Общее

Профиль

Руководство пользователя кластера OpenPOWER ВЦ ДВО РАН

Версия: 0.6
Дата: 19.07.2018
Значимые обновления в руководстве, ответы на часто задаваемые вопросы и список программного обеспечения вынесены на отдельные страницы.

 
 
Данное руководство содержит минимально необходимый объем информации для работы на гибридном кластере ВЦ ДВО РАН: описание процесса регистрации, сведения по работе в ОС Linux (вход в систему, работа с каталогами и файлами, мониторинг) и работе с MPI программами и непараллельными программами на кластере (компиляция, запуск, остановка, работа с очередями). В тексте под термином параллельная программа подразумеваются только MPI программы.

Команды и переменные командного интерпретатора, названия программ, листинги, непосредственный ввод/вывод консоли выделены моноширинным шрифтом.

Вопросы относительно работы кластера следует отправлять на e-mail: .

Вопросы относительно этого документа (ошибки, неточности, предложения) можно отправлять на e-mail: .

Описание системы

Гибридный вычислительный кластер состоит из одного управляющего и четырех вычислительных узлов. Все они представляют собой серверы Sitonica PW22LC (IBM Power Systems S822LC 8335-GTB). Каждый включает в себя два процессора IBM POWER8 с максимальной частотой 4,023 ГГц, два сопроцессора NVIDIA Tesla P100 GPU, 256 ГБ DDR4 ОЗУ, контроллер EDR InfiniBand и два жестких диска Seagate ST1000NX0313 1 ТБ 7200RPM. Для хранения пользовательских данных используется внешнее дисковое хранилищу объемом 50 ТБ. В качестве сети управления используется сеть, построенная по технологии Gigabit Ethernet. В качестве сети передачи данных используется сеть EDR InfiniBand с пропускной способностью в 100 Гбит/с.

Регистрация

Регистрация пользователей на кластере происходит через систему ЦКП http://ckp.ccfebras.ru.

Вход в систему

Для работы с системой пользователь должен иметь свою учетную запись на управляющем узле кластера. Регистрация пользователя на кластере происходит в соответствии с предыдущей частью руководства. После регистрации пользователь получает свое имя (логин), пароль и домашнюю директорию. Если имя пользователя, например, будет user, то домашняя папка находится в /home/user.

При первом входе в систему предлагается сменить пароль. Обратите внимание, что перед вводом нового пароля в строке (current) LDAP Password: необходимо ввести еще раз текущий пароль. Требования к новому паролю: он должен быть достаточной длины, содержать хотя бы 1 цифру и 1 заглавную букву. Директория ~/.ssh содержит пару ключей (id_rsa и authorized_keys) для доступа к узлам кластера. При добавлении личного ssh-ключа, необходимо добавить открытый ключ в файл authorized_keys через перенос строки (т.е. после уже имеющегося одного открытого ключа).

Пользователи имеют возможность работать на кластере с любой машины, находящейся в сети института и интернет. Для входа в систему пользователю необходим адрес сервера (http://jupiter.febras.net), а также имя и пароль, полученные при регистрации.

Вход с Windows-машины

Работа с системой осуществляется по безопасному протоколу SSH при помощи какого-либо ssh-клиента. Клиент должен поддерживать протокол версии 2. Рекомендуется использовать PuTTY. Эта программа является свободно распространяемой и проста в использовании.

После запуска программы пользователь должен выбрать протокол ssh и в поле «Host Name (or IP address)» указать адрес сервера. Нажатие на «Open» приведет к отправке запроса на подключение. В случае успешного подключения к серверу будет предложено ввести имя (логин), а затем и пароль.

Окно ssh-клиента PuTTY

При вводе пароля символы на экране не отображаются. Если все введено правильно, то пользователь автоматически окажется в своей домашней директории. Этот каталог доступен пользователю с любого узла кластера.

Примечание. На кластере существует единое дисковое пространство для директорий /opt (только чтение) и /home. Все узлы используют дисковый массив сервера посредством сетевой файловой системы NFS. Файл записанный на одном из узлов кластера автоматически становится доступен на любом другом.

Работа в ssh-сессии происходит в терминальном (текстовом, консольном) режиме. Необходимо помнить, что консоль Linux, в отличии от Windows, различает регистр вводимых символов, то есть mydoc.txt и mydoc.TXT не одно и то же. После входа на экране отображается консоль командного интерпретатора в формате имя_пользователя@машина текущий_каталог:

[user@jupiter ~]$

Вход с терминала Linux

В любой дистрибутив ОС Linux входит терминальный ssh-клиент (обычно OpenSSH). Минимальный формат команды для подключения к кластеру таков:

[user@localhost ~]$ ssh jupiter.febras.net -l имя_пользователя

Копирование файлов

См. соответствующий раздел руководства кластера версии 5.0.

Навигация

См. соответствующий раздел руководства кластера версии 5.0.

Редактирование файлов

См. соответствующий раздел руководства кластера версии 5.0.

Environment Modules

На кластере используется система модулей окружения (Environment Modules). Загруженные модули можно посмотреть с помощью команды:

[user@jupiter ~]$ module list
Currently Loaded Modulefiles:
  1) core           2) xl/13.1-15.1   3) cuda           4) essl           5) spectrum_mpi

Указанные выше модули загружаются по умолчанию при входе в систему.

Список всех доступных модулей можно увидеть с помощью команды:

[user@jupiter ~]$ module avail

------------------------------------------------- /etc/modulefiles --------------------------------------------------
biobuilds/2017.11              mpi/mvapich2-ppc64le           pgi/16.10(default)
conda/pytorch/0.4.0            openmpi/gcc/1.10.6/4.8.5       pgi/17.4
core                           openmpi/gcc/2.0.2a1/4.8.5      pgi/18.4
cuda                           openmpi/gcc/2.1.0/4.8.5        python/2.7
cuda_/8.0.61                   openmpi/pgi/1.10.2/16.10       python/3.5
cudnn/5.1                      openmpi/pgi/1.10.2/17.4        singularity/2.2.1
espresso/cpu/5.4               openmpi/xl/1.10.6              singularity/2.3.1
espresso/cpu/5.4-default-libs  openmpi/xl/1.10.6_/13.1-15.1   singularity/2.4
espresso/gpu/5.4               openmpi/xl/2.0.2a1             singularity/2.4.2
espresso/gpu/5.4-esslcuda      openmpi/xl/2.0.2a1_/13.1-15.1  spectrum_mpi
espresso/gpu/6.0               openmpi/xl/2.1.0               spectrum-mpi/gcc/10.1/4.8.5
espresso/gpu/6.2-esslcuda      openmpi/xl/2.1.0_/13.1-15.1    spectrum-mpi/pgi/10.1
essl                           openmpi/xl/3.0.0/13.1-15.1     spectrum-mpi/xl/10.1/13.1-15.1
essl_/5.5                      pai/caffe/bvlc/1.0.0           tensorflow/1.1.0
example/notavail               pai/caffe/ibm/1.0.0            tensorflow/1.2.1
gamess/07.10.2017-A            pai/caffe/nvidia/0.15.14       tensorflow/1.2.1-gpu
gcc/4.8.5                      pai/chainer/1.23.0             utils/mpirun-pbswrap
modem/2016.05                  pai/digits/5.0.0               xl/13.1-15.1
mpi/gcc/2.0/4.8.5              pai/theano/0.9.0
mpi/mvapich2-2.0-ppc64le       pai/torch/7

Компиляция программ

Доступные компиляторы

На кластере (на 16.02.2018) поддерживаются следующие компиляторы языков программирования для архитектуры ppc64le:

Компиляторы на кластере
Компилятор Файл компилятора Язык Модуль
GNU C 4.8.5 gcc C gcc/4.8.5
GNU C++ 4.8.5 g++ C++ gcc/4.8.5
GNU Fortran 4.8.5 gfortran Fortran 90 gcc/4.8.5
IBM XL Fortran 15.1.5 xlf/xlf_r* Fortran 77 xl/13.1-15.1
IBM XL Fortran 15.1.5 xlf90/xlf90_r Fortran 90 xl/13.1-15.1
IBM XL C 13.1.5 xlc/xlc_r C xl/13.1-15.1
IBM XL C++ 13.1.5 xlc++/xlc++_r C++ xl/13.1-15.1
PGI C 17.4 pgcc C pgi/17.4
PGI C++ 17.4 pgc++ C++ pgi/17.4
PGI Fortran 17.4 pgf90 Fortran pgi/17.4
NVIDIA Cuda 8.0.61 nvcc - cuda

* - файлы компиляторов IBM с постфиксом "_r" используются для сборки безопасных с точки зрения потоков исполняемых файлов.

Пути к компиляторам GNU и IBM XL прописаны в переменной окружения «PATH» для всех пользователей. Дополнительно в переменной среды «LD_LIBRARY_PATH» указаны пути к библиотекам этих компиляторов. Поэтому загружать какие-либо модули для их использования не нужно. Для использования остальных компиляторов необходимо подгружать соответствующие модули.

Компиляция MPI программ

На кластере (на 16.02.2018) поддерживаются следующие реализации библиотеки MPI:

Библиотеки MPI на кластере
Библиотека MPI Компилятор Модуль
IBM Spectrum MPI 10.1 GNU C/C++/Fortran 4.8.5 spectrum-mpi/gcc/10.1/4.8.5
IBM XL C/C++ 13.1.5 и Fortran 15.1.5 spectrum-mpi/xl/10.1/13.1-15.1
PGI С/C++/Fortran 17.4 spectrum-mpi/pgi/10.1
OpenMPI 2.0.2a1 GNU C/C++/Fortran 4.8.5 openmpi/gcc/2.0.2a1/4.8.5
IBM XL C/C++ 13.1.5 и Fortran 15.1.5 openmpi/xl/2.0.2a1
OpenMPI 1.10.2 PGI С/C++/Fortran 17.4 openmpi/pgi/1.10.2/17.4

По умолчанию для всех пользователей установлены переменные среды, позволяющие использовать библиотеку Spectrum MPI совместно с компиляторами IBM XL (модуль spectrum-mpi/xl/10.1/13.1-15.1). Для использования остальных реализаций MPI, или при необходимости использования других компиляторов, нужно загрузить соответствующий модуль. В связи с тем, что все реализации MPI конфликтуют между собой, перед загрузкой нового модуля необходимо выгружать текущий:

module unload xl/13.1-15.1
module unload spectrum-mpi/xl/10.1/13.1-15.1
module load gcc/4.8.5
module load openmpi/gcc/2.0.2a1/4.8.5

При использовании компилятора PGI требуется загрузить его модуль перед загрузкой модуля библиотеки MPI:

module unload xl/13.1-15.1
module unload spectrum-mpi/xl/10.1/13.1-15.1
module load pgi/17.4
module load openmpi/pgi/1.10.2/17.4

После подключения нужного модуля, пути к данной библиотеке добавляются в переменные среды «PATH» и «LD_LIBRARY_PATH».

Для компиляции mpi программ лучше всего использовать обёртки к компиляторам, чем вручную прописывать для этого специальные флаги. Так, например, чтобы скомпилировать mpi программу, написанную на языке Fortran, нужно воспользоваться оберткой mpifort. Данная команда вызовет компилятор IBM XL Fortran (при условии, что подключен модуль spectrum-mpi/xl/10.1/13.1-15.1), с указанием всех необходимых флагов.

Распишем соответствие между обертками и соответствующими им компиляторами:

Соответствие между обертками MPI и компиляторами
Обертка XL GNU PGI
mpicc xlc_r gcc pgcc
mpifort xlf_r gfortran pgfortran
mpif77 xlf_r gfortran pgfortran
mpif90 xlf90_r gfortran pgfortran
mpic++ xlC_r g++ pgc++
mpicxx xlC_r g++ pgc++

Для того, чтобы посмотреть какие опции компилятора указываются при вызове обертки, можно воспользоваться следующей командой:

[user@jupiter ~]$ mpicc --show
gcc -I/opt/soft/openmpi/2.0.2a1/gcc/include -pthread -Wl,-rpath -Wl,/opt/soft/openmpi/2.0.2a1/gcc/lib -Wl,
--enable-new-dtags -L/opt/soft/openmpi/2.0.2a1/gcc/lib -lmpi

Как видно из данного вывода, единственными опциями, которые может потребоваться указать при вызове компилятора, могут оказаться опции оптимизации.

Замечания по разработке программ на отдельной машине

Практически все реализации MPI поддерживают запуск параллельных приложений в режиме эмуляции на отдельно взятой рабочей станции. Это можно делать как на Linux, так и Windows машинах.

В Linux рекомендуется использовать пакет OpenMPI, а для создания MPI приложений на Windows машинах можно использовать пакет MPICH в версии для Windows. Для успешного портирования программ с Windows на Linux не следует использовать расширения предоставляемые средами программирования, такими как Visual Studio и Borland Builder.

Подготовленные исходные коды программ лучше всего компилировать на кластере.

Запуск задач

Диспетчеризация задач

Для диспетчеризации задач на кластере используется система PBS Professional 14.1. С её помощью пользователь может отправлять свои задачи на исполнение, снимать их с исполнения и получать информацию по текущему статусу задачи.

Данная система построена на основе очередей, где под очередью понимается набор пользовательских процессов (программ, задач) выполняющихся в рамках системы диспетчеризации. Каждой очереди сопоставлен ряд атрибутов, в зависимости от которых к задаче будут применены те или иные действия. Типичными атрибутами являются название (идентификатор) очереди, её приоритет, доступные ресурсы, количество задач. В общем случае термин очередь не означает, то что программы в ней будут выполняться строго последовательно.

Чтобы поставить задачу на исполнение, пользователь должен добавить ее при помощи команды qsub в какую-либо очередь. Очереди отличаются друг от друга совокупностью ресурсов, которыми они обладают.

Система очередей

На данный момент для пользователей действует единая очередь маршрутизации задач workq, в которой доступны все 5 узлов. Задачи из неё распределяются по очередям выполнения. Поставить задачу напрямую в очередь выполнения нельзя. Так задачи, для которых установлен walltime не более 10 минут, отправляются в короткую очередь fastq, привязанную к jupiter1[0] – первой половине узла jupiter1. Иначе говоря, часть ресурсов 1 узла кластера, в т.ч. и GPU0, доступна только для быстрых тестовых задач. Установить значение walltime можно с помощью строки:

#PBS -l walltime=0:10:00
в файле задачи.

Задачу, которая запрашивает ресурсов больше, чем есть на 1 виртуальном узле, невозможно запустить с walltime<=0:10:00, поскольку все такие задачи размещаются в очередь fastq, привязанную к виртуальному узлу jupiter1[0]. Поэтому, для любых больших задач необходимо задавать значение walltime как минимум 0:10:01.
Задача с walltime<=0:10:00 обязательно попадает в очередь fastq, но не обязательно на узел jupiter1[0]: в случае, если есть другие свободные узлы, она может быть поставлена на один из них.

Для получения информации об очередях, можно выполнить команду qstat -q:

[eab@jupiter install]$ qstat -q

server: jupiter1

Queue            Memory CPU Time Walltime Node   Run   Que   Lm  State
---------------- ------ -------- -------- ---- ----- ----- ----  -----
fastq              --      --    00:10:00  --      0     0   --   E R
mixedq             --      --    390:00:0  --      0     0   --   E R
mixedq-gpu         --      --       --     --      0     0   --   E R
workq              --      --       --     --      0     0   --   E R
lowq               --      --       --     --      0     0   --   E R
                                               ----- -----
                                                   0     0

Queue – имя очереди; Run – число выполняемых задач; Que – число задач, ожидающих начала выполнения. Команда qstat -Qf имя_очереди позволяет получить информацию о конкретной очереди.

Постановка задачи в очередь

Для постановки задачи в очередь на исполнение используется команда qsub. Данная команда принимает в качестве параметра имя скрипта, в котором описываются требуемые задачей ресурсы и указываются команды, исполняемые при запуске. Рассмотрим пример, иллюстрирующий запуск ранее скомпилированной программы на 1 чанке (некоторой виртуальной части узла, которая не может по всем запрашиваемым ресурсам превышать размер одного узла) кластера, с использованием 4 mpi процессов, выделением 4 ядер и 1 GPU на этом чанке:

[user@jupiter mpi_test]$ cat mpi_test.qsub
#PBS -k oe
#PBS -l select=1:mpiprocs=4:ncpus=32:mem=4gb:ngpus=1
#PBS -l place=shared
#PBS -r n
#PBS -M user@mail.com
#PBS -m abe
#PBS -q workq
#PBS -N mpi_test
#!/bin/sh

cd /home/user/test/mpi_test

module unload xl/13.1-15.1 && module load gcc/4.8.5
module unload spectrum_mpi && module load openmpi/gcc/1.10.6/4.8.5
mpirun -np 4 -npernode 4 --hostfile $PBS_NODEFILE --bind-to core ./mpi

[user@jupiter mpi_test]$ qsub mpi_test.qsub
66330.jupiter1

Если команда выполнена успешно, то на экране отобразится идентификатор задачи (в данном случае это 66330.jupiter1), в противном случае появится сообщение об ошибке. Ошибки пользовательской программы (неправильная компиляция и т.п.) проявятся только при переходе задачи к активному состоянию.

Примечание. Весь вывод программы в стандартный поток и в поток ошибок перенаправляется в файлы, находящиеся в домашней директории пользователя. Названия таких файлов имеют формат имя_задачи.(e/o)порядковый_номер. Для запущенной задачи это будут: mpi_test.e66330 – для потока ошибок и mpi_test.o66330 – для стандартного потока вывода.

Прокомментируем каждую из строчек скрипта mpi_test.qsub:

#PBS -k oe — указание сброса потока вывода (o) и потока ошибок (e)
#PBS -l select=1:mpiprocs=4:ncpus=32:mem=4gb:ngpus=1 — требуемое количество чанков (1); количество mpi процессов (4), количество выделяемых ядер (4 = 32/8), количество оперативной памяти и количество выделяемых GPU (1) на каждом чанке

Параметр ngpus=<число> является обязательным к указанию для задач, планируемых к запуску с использованием графических ускорителей. <число> — количество ускорителей, требуемое задачей.

#PBS -l place=shared — использование узла вместе с другими задачами; shared — совместное использование, excl — монопольное использование
#PBS -r n — является ли задача перезапускаемой (задачей с контрольными точками); y — является, n — не является
#PBS -M user@mail.com — почтовый адрес пользователя
#PBS -m abe — какие сообщения отправляются на указанный адрес (a — ошибка в выполнении задачи, b — начало выполнения, e — завершение выполнения)
#PBS -q workq — идентификатор очереди
#PBS -N mpi_test — название задачи
#!/bin/sh — указание необходимого командного интерпретатора
cd /home/user/test/mpi_test — переход в директорию с исполняемым файлом
module unload xl/13.1-15.1 && module load gcc/4.8.5 — выбор gcc вместо xl
module unload spectrum_mpi && module load openmpi/gcc/1.10.6/4.8.5* — выбор openmpi вместо spectrum_mpi
mpirun -np 4 -npernode 4 --hostfile $PBS_NODEFILE --bind-to core ./mpi — запуск приложения

Запуск интерактивных программ

Запуск управляющей консоли через планировщик

Вы можете запустить интерактивную задачу, используя директиву qsub -I. Например:

qsub -I -N jobname -l select=1:ncpus=8:mem=1gb:ngpus=1,walltime=1:00:00
После запуска установленная по умолчанию командная оболочка, например bash, откроется на узле, выделенном планировщиком для выполнения задания.

Вы не можете использовать PBS скрипт для запуска интерактивной задачи.

Запуск программ с фиксированным вводом

Программы, использующие стандартный ввод, называются интерактивными. Как правило, такие программы после запуска требуют от пользователя ввода данных. При постановке задачи в очередь любая программа переводится в фоновый режим. В этом режиме ввод данных пользователем в запущенную программу невозможен. Для передачи данных таким программам используется механизм перенаправления стандартных потоков ввода/вывода.

Для перенаправления подготавливается текстовый файл, содержимое которого в точности представляет собой данные, вводимые пользователем. Например, если программа solver предполагает ввод в первой строке размерности матрицы, а во второй количества итераций, то текстовый файл input.txt будет иметь вид:

[user@jupiter solver]$ cat input.txt
10000000
1000

После каждого числа обязателен символ новой строки. Запуск программы на выполнение производится так:

solver < input.txt

Скрипт для постановки в очередь задания, в рамках которого будет выполняться интерактивная программа, будет выглядеть следующим образом:

[user@jupiter solver]$ cat job.qsub
#PBS -k oe
#PBS -l select=1:ncpus=64:mem=8gb:mpiprocs=8
#PBS -r n
#PBS -M user@mail.com
#PBS -m abe
#PBS -q workq
#PBS -N solver
#!/bin/sh

cd /home/user/test/solver

mpirun -np 8 -npernode 8 --hostfile $PBS_NODEFILE --bind-to core ./solver < ./input.txt

exit 0

Запуск непараллельных программ

Запуск непараллельных программ практически ничем не отличается от запуска параллельных программ. Единственное отличие заключается в том, что в qsub скрипте такой программы необходимо указать, что для её работы необходимо только одно ядро:

#PBS -l select=1:ncpus=8:mem=1gb

Также в этом скрипте необходимо запускать непосредственно исполняемый файл программы, то есть не использовать для запуска mpirun.

Состояние пользовательских задач

Для получения информации об очередях и задачах пользователя используется команда qstat. Выполнение этой команды без параметров покажет все задачи пользователя и их состояние.

[user@jupiter ~]$ qstat
Job id                  Name             User            Time Use S Queue
----------------------- ---------------- --------------- -------- - -----
700.jupiter1            mpi_test         user            00:10:40 R workq
701.jupiter1            sample_job       user            0        Q workq
702.jupiter1            solver           user            0        Q workq

Job id — идентификатор задачи, полученный при выполнении qsub; Name — имя задачи; User — имя пользователя, запустившего задачу; Time Use — процессорное время, потраченное задачей; S (State) — состояние задачи ( R – задача выполняется, Q – ожидает в очереди); Queue — очередь.

В данном случае пользователю user принадлежат три задачи.

С помощью команды qstat -n идентификатор_задачи можно получить список узлов, на которых выполняется конкретная задача. Эта информация полезна при мониторинге эффективности использования вычислительных ресурсов с использованием системы Ganglia, так как позволяет отслеживать состояние только используемых задачей узлов.

[user@jupiter ~]$ qstat -n 701

jupiter1:
                                                           Req'd  Req'd   Elap
Job ID          Username Queue    Jobname    SessID NDS TSK Memory Time  S Time
--------------- -------- -------- ---------- ------ --- --- ------ ----- - -----
298.jupiter1    eab      workq    mpi_test      --    1   4    2gb 00:00 R   -- 
   jupiter1/0*4

Для получения более подробной информации о конкретной задаче можно запустить команду qstat -f идентификатор_задачи. Для просмотра информации по завершенным задачам можно использовать команды qstat -x | tail и qstat -xf идентификатор_задачи.

Остановка задач

Остановка программы производится командой qdel идентификатор_задачи

[user@jupiter ~]$ qdel 700

Этой командой задача, стоящая в очереди, убирается из нее, а выполняющаяся задача снимается с выполнения. Следующая по очереди и приоритету задача встает на выполнение.

Задача снимается в течении некоторого времени, поэтому при вызове qstat непосредственно после qdel удаленная задача все еще может быть отражена в таблице.

Углубленная настройка задач

Каждый узел кластера состоит из двух виртуальных узлов, разделяющих ресурсы узла поровну. Для оперативной памяти действует исключение: она может заимствоваться из соседнего виртуального узла.

Соответствие физических и программных ресурсов

Соответствие между физическими ресурсами узлов и программными ресурсами, которыми оперирует планировщик, не всегда прозрачно и очевидно. Попробуем разобраться в этом.

Физический узел кластера содержит 2 процессора, что соответствует 20 вычислительным ядрам или 160 потокам выполнения. В планировщике же задается такая конфигурация, что узел состоит из двух виртуальных узлов, на каждом из которых есть 80 вычислительных процессоров, обозначаемых как ncpus (т.е. вычислительный процессор планировщика соответствует потоку выполнения физического устройства). В зависимости от ситуации словом процессор обозначаются разные сущности. Чтобы прояснить ситуацию, рассмотрим гипотетический вариант конфигурации планировщика, когда виртуальный узел состоит из ncpus=10 вычислительных процессоров (т.е. вычислительный процессор планировщика соответствует ядру физического устройства). Задача, запускаемая планировщиком, не может не потреблять вычислительные ресурсы, то есть минимальное значение для ncpus задачи есть 1. Таким образом, в текущей конфигурации на узле можно одновременно запустить максимум 160 задач, а в конфигурации, приведенной для сравнения, только 20.

Мы неоднократно упоминали о рекомендации использовать значение ncpus примерно в 8 раз большее требуемого количества ядер. В этом случае, если минимальное значение ncpus равно 8 (что соответствует одному ядру), то максимальное количество задач, которые одновременно можно запустить на одном узле, — те же 20, что и во второй конфигурации. В чем же тогда отличие и преимущество конфигурации с ncpus=160? Её очевидным недостатком является необходимость понимать и помнить, что 8 ncpus это "на самом деле" 1 ядро.

Использование гиперпоточности (в конфигурации с ncpus=160 у каждого вычислительного ядра есть 8 потоков) в общем случае позволяет улучшить общую пропускную способность вычислительной системы (в среднем выполнять большее количество задач за данное время), потенциально уменьшает плату за единицу потребляемых ресурсов, а также в некоторых случаях, позволяет задаче, ожидающей в очереди, запуститься раньше. В то же время, использование гиперпоточности в некоторых случаях мешает достижению наилучшей производительности вычислительной системы.

Продемонстрируем это на примере. Предположим, есть задача, которой оптимально требуется 20 ядер CPU и не требуется GPU. Также, есть полностью свободный узел кластера:

                                                        mem       ncpus   nmics   ngpus
vnode           state           njobs   run   susp      f/t        f/t     f/t     f/t   jobs
jupiter3[0]     free                 0     0      0  126gb/126gb   80/80     0/0     1/1 --
jupiter3[1]     free                 0     0      0  126gb/126gb   80/80     0/0     1/1 --

Следующий запрос ресурсов

#PBS -l select=2:mpiprocs=10:ncpus=72:mem=4gb
#PBS -l place=pack
позволяет такой задаче разместиться (здесь параметр place=pack обязует планировщика использовать строго один физический узел для чанков из запроса) на обоих виртуальных узлах
                                                        mem       ncpus   nmics   ngpus
vnode           state           njobs   run   susp      f/t        f/t     f/t     f/t   jobs
jupiter3[0]     free                 1     1      0  122gb/126gb    8/80     0/0     1/1 1083
jupiter3[1]     free                 1     1      0  122gb/126gb    8/80     0/0     1/1 1083
при этом оставляя свободные ncpus на каждом из них.

Если указаны правильные параметры

$MPIEXEC --bind-to core a.out
для mpi и
export OMP_PLACES=cores
для OpenMP, то задача равномерно и оптимально разместится на имеющихся 20 физических ядрах (используя только 20 потоков выполнения из 160), а планировщик запомнит, что задача заняла "почти все" (144 из 160) ресурсы CPU на этом узле.

Другая задача с запросом

#PBS -l select=1:ncpus=8:mem=40gb:ngpus=1
может занять любой из все еще свободных виртуальных узлов
                                                        mem       ncpus   nmics   ngpus
vnode           state           njobs   run   susp      f/t        f/t     f/t     f/t   jobs
jupiter3[0]     job-busy             2     2      0   82gb/126gb    0/80     0/0     0/1 1083,1084
jupiter3[1]     free                 1     1      0  122gb/126gb    8/80     0/0     1/1 1083
задействуя одно физическое ядро (используя еще 1 поток из оставшихся 140) и 1 GPU. Теперь виртуальный узел jupiter3[0] имеет состояние job-busy и не может больше принимать задачи.

Каков результат такого размещения задач с точки зрения эффективности использования ресурсов? Одно ядро системы вынуждено обслуживать 2 задачи (1083 и 1084), а оставшиеся 19 ядер оптимально работают с одной задачей (1083). Предположим,в благоприятном случае, балансировщик нагрузки ядра linux, за счет имеющегося в наличии большого количества свободных потоков, позволяет добиться того, что потери в итоговом времени выполнения задач 1083 (которой оптимально нужно 20 ядер) и 1084 (которой оптимально нужно 1 ядро) будут сведены к минимуму. Проще говоря, они практически не помещают друг другу. Другой вероятный сценарий: из-за того, что на каком-то ядре висит 2 задачи, они будут вычисляться, например, в 1.5 раза дольше, чем если бы они использовали ресурсы эксклюзивно. Если при этом еще и параллелизм задачи 1083 устроен так, что происходят регулярные синхронизации, когда все потоки должны завершиться, ожидая самый медленный, то перегрузка одного ядра сильно отразится на производительности для задачи 1083 в целом.

Определение количества mpi-процессов

На каждом узле кластера имеется 2 десятиядерных процессора, каждое ядро может обрабатывать 8 потоков. В скриптах запуска для параметра ncpus максимальным является значение 160 — общее количество потоков. Тем не менее, при определенных условиях (если код запускаемых программ хорошо оптимизирован), количество вычислительных процессов значительно большее, чем 20 доступных ядер, может стать причиной неэффективного выполнения — задачи будут мешать друг другу. Поэтому, если нет особых оснований, рекомендуется использовать 20 mpi-процессов на узле. Таким образом, количество запускаемых mpi-процессов должно примерно соответствовать количеству запрашиваемых ncpus, поделенному на 8. В некоторых случаях допускаются отклонения от этой схемы, например, для приложения GAMESS запускается в 2 раза больше потоков, чем обычно, и половина из них не требует отдельного процессора. В данном случае количество mpi-процессов будет соответствовать количеству ncpus, поделенному на 4.

В силу специфики узла кластера, имеющего 2 GPU, для задач, использующих все 20 mpi-процессов и не использующих GPU, рекомендуется устанавливать значение select=2:ncpus=72:mem=100gb (при этом обязательно указать place=pack), чтобы было возможно размещение еще 2х задач, не требовательных к CPU и задействующих GPU, с параметрами ncpus=8:ngpus=1:mem=25gb.

Использование MPS-сервера

На данный момент на кластере можно использовать CUDA MPS сервер. Настройка пока доступна только для задач, требующих 1 GPU и помещающихся ровно на 1 виртуальный узел (что означает задание ncpus<=80 при полностью свободных процессорных ресурсах виртуального узла). Чтобы активировать этот режим, необходимо в скрипте запуска указать:

#PBS -v USE_MPS=True

MPS-сервер будет создан при запуске задачи и удален после её завершения.

Согласование параметров mpirun

До настоящего времени приходилось дублировать параметры, передаваемые в запрос ресурсов, и параметры mpirun, например:

#PBS -l select=2:ncpus=144:mpiprocs=20:mem=200gb

mpirun -np 40 --hostfile $PBS_NODEFILE --bind-to core a.out
Здесь количество mpi-процессов из запроса (2 чанка по 20 процессов) необходимо повторять в параметре -np. Кроме того, необходимо передавать параметр --hostfile.

Теперь, с помощью экспериментального режима, запускаемого с помощью модуля utils/mpirun-pbswrap, можно заменять вызов mpirun на вызов обертки, которая позволяет избавиться от такого дублирования:

#PBS -l select=2:ncpus=144:mpiprocs=20:mem=200gb

module load utils/mpirun-pbswrap
mpirun --bind-to core a.out

Обертка поддерживается для всех модулей spectrum mpi и openmpi/gcc/2.1.0/4.8.5.

Мониторинг

Web-интерфейс

Мониторинг кластера реализован при помощи системы Ganglia. Эта система позволяет следить за ресурсами кластера посредством web-интерфейса. Система мониторинга находится по адресу http://jupiter.febras.net/ganglia.

Для мониторинга пользователю доступно большое число типов ресурсов: загруженность процессора, оперативная память, загрузка сети, средняя загрузка, количество процессов и ряд других. Имеется возможность наблюдать как за всеми узлами в кластере (по одному параметру), так и за каждым (по всем параметрам).

Консоль

Кроме графического интерфейса существует несколько полезных консольных команд для мониторинга. Команда pbsnodes имя_узла позволяет получить информацию о конкретном узле: тип, состояние, количество процессоров, выполняющиеся задачи. Ниже представлен фрагмент вывода этой команды.

[user@jupiter ~]$ pbsnodes jupiter2
jupiter2
     Mom = jupiter2
     Port = 15002
     pbs_version = 14.1.0
     ntype = PBS
     state = free
     pcpus = 160
     resources_available.arch = linux
     resources_available.host = jupiter2
     resources_available.mem = 263653568kb
     resources_available.ncpus = 160
     resources_available.ngpus = 2
     resources_available.vnode = jupiter2
     resources_assigned.accelerator_memory = 0kb
     resources_assigned.mem = 0kb
     resources_assigned.naccelerators = 0
     resources_assigned.ncpus = 0
     resources_assigned.netwins = 0
     resources_assigned.ngpus = 0
     resources_assigned.vmem = 0kb
     resv_enable = True
     sharing = default_shared

state – состояние узла (job-exclusive – все ресурсы узла заняты; free – на узле есть свободные ресурсы для запуска заданий; offline – узел временно выведен из эксплуатации, запуск заданий на нем невозможен; down – узел выключен); pcpus – число процессорных потоков на узле; jobs – задачи, запущенные на узле; resources_available.ngpus – число GPU на узле; resources_available.nodetype — тип узла: jupiter (CentOS).

При выполнении команды pbsnodes -a -S -j будет выведена сводная информация обо всех узлах кластера.

[user@jupiter ~]$ pbsnodes -a -S -j
                                                        mem       ncpus   nmics   ngpus
vnode           state           njobs   run   susp      f/t        f/t     f/t     f/t   jobs
--------------- --------------- ------ ----- ------ ------------ ------- ------- ------- -------
jupiter1        free                 0     0      0  251gb/251gb 160/160     0/0     2/2 --
jupiter2        free                 0     0      0  251gb/251gb 160/160     0/0     2/2 --
jupiter3        free                 0     0      0  251gb/251gb 160/160     0/0     2/2 --
jupiter4        free                 0     0      0  251gb/251gb 160/160     0/0     2/2 --
jupiter5        free                 0     0      0  251gb/251gb 160/160     0/0     2/2 --

При выполнении команды pbsnodes -v -a -S -j сводная информация будет выведена с внутренней детализацией.

[user@jupiter ~]$ pbsnodes -v -a -S -j
                                                        mem       ncpus   nmics   ngpus
vnode           state           njobs   run   susp      f/t        f/t     f/t     f/t   jobs
--------------- --------------- ------ ----- ------ ------------ ------- ------- ------- -------
jupiter2        free                 0     0      0      0 b/0 b     0/0     0/0     0/0 --
jupiter3        free                 0     0      0      0 b/0 b     0/0     0/0     0/0 --
jupiter3[0]     free                 2     2      0  126gb/126gb   52/80     0/0     0/1 5272,5326
jupiter3[1]     free                 1     1      0  126gb/126gb   72/80     0/0     0/1 5273
jupiter1        free                 0     0      0      0 b/0 b     0/0     0/0     0/0 --
jupiter4        free                 0     0      0      0 b/0 b     0/0     0/0     0/0 --
jupiter5        free                 0     0      0      0 b/0 b     0/0     0/0     0/0 --
jupiter4[0]     free                 1     1      0  126gb/126gb   72/80     0/0     0/1 5278
jupiter4[1]     free                 1     1      0  126gb/126gb   72/80     0/0     0/1 5279
jupiter5[0]     free                 1     1      0  126gb/126gb   72/80     0/0     0/1 5280
jupiter5[1]     free                 1     1      0  126gb/126gb   72/80     0/0     0/1 5281
jupiter1[0]     free                 1     1      0  126gb/126gb   72/80     0/0     0/1 5276
jupiter1[1]     free                 1     1      0  126gb/126gb   72/80     0/0     0/1 5277
jupiter2[0]     free                 1     1      0  126gb/126gb   72/80     0/0     0/1 5275
jupiter2[1]     free                 1     1      0  126gb/126gb   72/80     0/0     0/1 5274

Пакеты прикладных программ

Фреймворки машинного и глубокого обучения

На кластере доступны следующие фреймворки машинного и глубокого обучения:

Фреймворк Версия Модуль
Caffe (Berkeley Vision and Learning Center) 1.0.0 pai/caffe/bvlc/1.0.0
Caffe (оптимизированная версия от IBM) 1.0.0 pai/caffe/ibm/1.0.0
Caffe (форк NVIDIA) 0.15.14 pai/caffe/nvidia/0.15.14
Chainer 1.23.0 pai/chainer/1.23.0
DIGITS 5.0.0 pai/digits/5.0.0
TensorFlow 1.1.0 tensorflow/1.1.0
Theano 0.9.0 pai/theano/0.9.0
Torch 7 pai/torch/7
PyTorch 0.4.0 conda/pytorch/0.4.0

PyTorch

PyTorch — фреймворк глубокого обучения для быстрого и гибкого экспериментирования.

Установлена версия 0.4.0. Пакет собран из git-репозитория при помощи развертывания окружения для сборки из Anaconda и pip.

Использование. В любом qsub скрипте запуска:

# Загружаем модуль PyTorch
module add conda/pytorch/0.4.0

# Запускаем свой pytorch-скрипт:
python <script-name.py>

TensorFlow

TensorFlow — открытая программная библиотека для машинного обучения, разработанная компанией Google для решения задач построения и тренировки нейронной сети с целью автоматического нахождения и классификации образов (https://www.tensorflow.org/).
На кластере доступна оптимизированная для работы на процессорах IBM POWER8 и сопроцессорах NVIDIA Tesla P100 версия пакета, входящая в состав IBM PowerAI 4.0. Для работы с ней применяются контейнеры Singularity. Ниже приводится пример скрипта описания заданий, используемого для запуска TensorFlow на одном вычислительном узле кластера с задействованием двух сопроцессоров.

#!/bin/sh
#PBS -k oe 
#PBS -l select=1:ncpus=16:ngpus=2:mem=10gb
#PBS -r n 
#PBS -M user@mail.com 
#PBS -m abe 
#PBS -q workq 
#PBS -N cifar10  

# Загружаем модуль TensorFlow
module add tensorflow/1.1.0

# Переходим в рабочую директорию проекта
cd /home/user/tf_working_dir 

# Запускаем тренировку нейронной сети,
# описанной в файлах cifar10_multi_gpu_train.py и cifar10.py
python-pai ./cifar10/cifar10_multi_gpu_train.py 

# Проводим оценку результатов обучения нейронной сети
python-pai ./cifar10/cifar10_eval.py
Использование нескольких GPU

Использование нескольких GPU позволяет ускорить расчет градиентов обновления весов сети. Для этого несколько копий модели параллельно просчитываются на отдельных GPU, после чего вычисляется средний градиент ошибки для обновления весов сети.

Ниже приведены части кода, исполняющего задачу классификации изображений из набора CIFAR-10, с помощью сверточной нейронной сети. Полный код приведен в файлах:

cifar10_multi_gpu_train.py – задает процесс обучения на нескольких графических сопроцессорах;
cifar10.py – содержит вспомогательные функции, а также описывает вычислительный граф;
cifar10_input.py – загружает и структурирует данные из набора CIFAR-10;
cifar10_eval.py – загружает обученную модель и оценивает точность тренировки нейронной сети.

Для параллелизации процесса обучения в файле cifar10_multi_gpu_train.py задается параметр FLAGS.num_gpus, представляющий собой количество GPU (задается в tf.app.flags.DEFINE_integer).
Копии модели в TensorFlow принято называть tower. Ниже приведен пример, в котором каждая tower рассчитывается на отдельном GPU, после чего вычисляется средний градиент весов сети:

    tower_grads = [] 
    with tf.variable_scope(tf.get_variable_scope()): 
      for i in xrange(FLAGS.num_gpus): 
        with tf.device('/gpu:%d' % i): 
          with tf.name_scope('%s_%d' % (cifar10.TOWER_NAME, i)) as scope: 
            # Dequeues one batch for the GPU 
            image_batch, label_batch = batch_queue.dequeue() 
            # Calculate the loss for one tower of the CIFAR model. This function 
            # constructs the entire CIFAR model but shares the variables across 
            # all towers. 
            loss = tower_loss(scope, image_batch, label_batch) 

            # Reuse variables for the next tower. 
            tf.get_variable_scope().reuse_variables() 

            # Retain the summaries from the final tower. 
            summaries = tf.get_collection(tf.GraphKeys.SUMMARIES, scope) 

            # Calculate the gradients for the batch of data on this CIFAR tower. 
            grads = opt.compute_gradients(loss) 

            # Keep track of the gradients across all towers. 
            tower_grads.append(grads) 

    # We must calculate the mean of each gradient. Note that this is the 
    # synchronization point across all towers. 
    grads = average_gradients(tower_grads)
Хранение данных на кластере

При работе с фреймворком TensorFlow настоятельно рекомендуется хэшировать данные в директории /tmp, имеющейся на каждом вычислительном узле. Эти директории находятся на локальных дисках объемом 2Tb. Для исключения конфликтов между данными разных пользователей на одном узле, необходимо размещать их в директории /tmp/username, как это сделано в коде ниже.

username = str(os.environ['USER']) 
tf.app.flags.DEFINE_string('data_dir', '/tmp/'+username+'/cifar10_data', """Path to the CIFAR-10 data directory.""")

Полное руководство по созданию данной модели глубокой нейронной сети в TensorFlow приведено по ссылке: https://www.tensorflow.org/tutorials/deep_cnn

Quantum ESPRESSO

Quantum ESPRESSO — это интегрированный набор машинных кодов для энергетических расчетов многоэлектронных систем. Программа основана на теории функциональной плотности, плоских волн и псевдопотенциалов. Свободное программное обеспечение, доступное для всех пользователей кластера.

Версии

Версии пакета
Версия Используемая библиотека Поддержка GPU Модуль Сайт проекта
5.4 NETLIB, FFTW - espresso/cpu/5.4-default-libs http://www.quantum-espresso.org/
5.4 IBM ESSL - espresso/cpu/5.4 http://www.quantum-espresso.org/
5.4 IBM ESSL +* espresso/gpu/5.4 https://github.com/fspiga/qe-gpu-plugin
5.4 IBM ESSL (SMPCUDA) ++ espresso/gpu/5.4-esslcuda http://www.quantum-espresso.org/
6.0 IBM ESSL +++ espresso/gpu/6.0 https://github.com/RSE-Cambridge/qe-gpu

* – число символов “+” соотносится с производительностью пакета (больше – лучше)

Все версии пакета собраны с поддержкой MPI и могут работать в параллельном режиме. Версия Quantum ESPRESSO 6.0 является экспериментальной и может не поддерживать некоторые функции и настройки (например, в этой версии нельзя выставить значение nk большее 1; подробности смотрите на сайте проекта).

Запуск Quantum ESPRESSO

Перед началом работы с пакетом необходимо загрузить соответствующий модуль командой “module add”. Это позволит получить доступ к нужной версии исполняемых файлов пакета и выставить необходимые переменные среды. Также может потребоваться загрузить дополнительные модули, от которых зависит работоспособность соответствующей версии Quantum ESPRESSO. Все эти действия выполняются в скриптах описания заданий.

Ниже приводятся примеры скриптов описания заданий, используемых для запуска Quantum ESPRESSO в параллельном режиме на узлах кластера (два вычислительных узла; используются 2 процессора, т.е. 20 ядер, и 2 сопроцессора на каждом).

Версия Quantum Espresso – espresso/cpu/5.4 и espresso/cpu/5.4-default-libs.

#!/bin/sh
#PBS -N qe_job_name
#PBS -q workq
#PBS -j oe
#PBS -l select=2:ncpus=144:mpiprocs=20:mem=200gb

# Загружаем необходимые модули
# При использовании espresso/cpu/5.4-default-libs загружаем
# данный модуль вместо espresso/cpu/5.4
module add spectrum_mpi essl espresso/cpu/5.4

# Переходим в рабочую директорию
cd /home/user/qe_working_dir

# Запускаем исполняемый файл Quantum ESPRESSO “pw.x”
mpirun -np 40 -npernode 20 --hostfile $PBS_NODEFILE --bind-to core $QE_HOME/bin/pw.x < ausurf.in

Примечание. Здесь запрос с ncpus=144 практически эквивалентен запросу с ncpus=160 с той разницей, что остается возможность для другой, не требовательной к cpu, небольшой задачи с ncpus=8:ngpus=1 занять свободные ресурсы на узле.

Версия Quantum ESPRESSO – espresso/gpu/5.4.

#!/bin/sh
#PBS -N qe_job_name
#PBS -q workq
#PBS -j oe
#PBS -l select=2:ncpus=160:ngpus=2:mpiprocs=20:mem=251gb

# Загружаем необходимые модули
module add spectrum_mpi essl espresso/gpu/5.4

# Переходим в рабочую директорию
cd /home/user/qe_working_dir

# Запускаем исполняемый файл Quantum ESPRESSO “pw-gpu.x”
mpirun -np 40 -npernode 20 --hostfile $PBS_NODEFILE --bind-to core $QE_HOME/bin/pw-gpu.x < ausurf.in

Версия Quantum ESPRESSO – espresso/gpu/5.4-esslcuda.

#!/bin/sh
#PBS -N qe_job_name
#PBS -q workq
#PBS -j oe
#PBS -l select=2:ncpus=160:ngpus=2:mpiprocs=20:mem=251gb

# Загружаем необходимые модули
module add spectrum_mpi essl espresso/gpu/5.4-esslcuda

# Переходим в рабочую директорию
cd /home/user/qe_working_dir

# Запускаем исполняемый файл Quantum ESPRESSO “pw.x”
mpirun -np 40 -npernode 20 --hostfile $PBS_NODEFILE --bind-to core $QE_HOME/bin/pw.x < ausurf.in

Версия Quantum ESPRESSO – espresso/gpu/6.0.

#!/bin/sh
#PBS -N qe_job_name
#PBS -q workq
#PBS -j oe
#PBS -l select=2:ncpus=160:ngpus=2:mpiprocs=2:mem=251gb

# Загружаем необходимые модули
module rm spectrum_mpi xl/13.1-15.1
module add pgi/17.4 spectrum-mpi/pgi/10.1 essl espresso/gpu/6.0

# Переходим в рабочую директорию
cd /home/user/qe_working_dir

# Запускаем исполняемый файл Quantum ESPRESSO “pw.x”
mpirun -np 4 --hostfile $PBS_NODEFILE --map-by ppr:1:socket $QE_HOME/bin/pw.x < ausurf.in

Стандартный вывод и вывод ошибок перенаправляется в файл вида qe_job_name.o1079, где “1079” соответствует номеру задания.

GAMESS

GAMESS — программа пакета вычислительной квантовой химии. GAMESS (US) способен производить расчеты МО при помощи многих методов вычислительной квантовой химии, включая метод Хартри-Фока, теорию функционала плотности (DFT), теорию валентных связей (GVB), и многоконфигурационное самосогласованное поле (MCSCF).

Версии

Установлена и протестирована версия GAMESS 2017 R2 с использованием ESSL и OpenMPI 2.0.2a1.
Для версии GAMESS+LIBCCHEM с использованием вычислений на GPU, компиляция проходит успешно, но часть тестов связанных с вычислением MP2 energy проваливаются.

Запуск GAMESS

Ниже приводится пример скрипта описания задания, используемого для запуска GAMESS в параллельном режиме на узлах кластера (два вычислительных узла).

#!/bin/sh
#PBS -N gm_job_name
#PBS -q workq
#PBS -k oe
#PBS -l select=2:ncpus=144:mpiprocs=40:mem=200gb
#PBS -m abe

# Загружаем необходимые модули
module rm xl/13.1-15.1
module rm spectrum_mpi
module add gcc/4.8.5
module add openmpi/gcc/2.0.2a1/4.8.5
module add gamess/07.10.2017-A

# Переходим в рабочую директорию
cd /home/user/gm_working_dir 

# Запуск GAMESS с входным файлом SubPc.inp.
# rungms принимает 4 параметра:
# имя входного файла (SubPc.inp)
# версия GAMESS (01) 
# количество ядер NCPUS (40)
# количество ядер на узел PPN (20) 
# т.е. происходит запуск на двух узлах с использованием 20 ядер на каждом.
# количество mpiprocs=2*PPN, потому что gamess использует 2 mpi процесса на каждом ядре.
rungms SubPc.inp 01 40 20 >&  run.log

exit 0

Дополнительно

Значение переменной для задания внешнего базисного набора атомных орбиталей установлено как:

setenv EXTBAS $HOME/EXTBAS.txt
Для его использования достаточно разместить файл EXTBAS.txt в своей домашней директории.

BioBuilds

BioBuilds — коллекция инструментов биоинформатики с открытым исходным кодом для работы в области геномики.

Установлена сборка 2017.11. Среди множества пакетов коллекции доступны:
Trinity 2.2.0
Samtools 1.6.0
Bowtie 1.1.2
NCBI BLAST+ 2.6.0
R 3.4.2

Для использования на кластере необходимо подключить модуль:

module load biobuilds/2017.11

ModEM

ModEM — свободно доступная программа для 3D инверсии MT данных.

Установлена версия от 2016.05.

Для использования на кластере необходимо подключить модуль:

module load modem/2016.05
Эта команда добавит нужный путь к исполняемым файлам:
Mod2DMT
Mod2DMT_seq
Mod3DMT
Mod3DMT_seq

Справочная информация

Описание основных команд при работе в ОС Linux — http://wwwinfo.jinr.ru/unixinfo/pc/lin_os.html
Документация к системе диспетчеризации заданий PBS Pro — http://www.pbsworks.com/pdfs/PBSUserGuide14.2.pdf

putty.png Просмотреть (16,8 КБ) Евгений Бойков, 21.07.2017 12:12

пакеты_прикладных_программ.docx - Раздел ППП (19,6 КБ) Евгений Бойков, 08.09.2017 17:12

cifar10.py Просмотреть (14,4 КБ) Сергей Мальковский, 27.09.2017 15:44

cifar10_eval.py Просмотреть (5,53 КБ) Сергей Мальковский, 27.09.2017 15:44

cifar10_input.py Просмотреть (9,8 КБ) Сергей Мальковский, 27.09.2017 15:44

cifar10_multi_gpu_train.py Просмотреть (10,7 КБ) Сергей Мальковский, 27.09.2017 15:45