Прикладные пакеты

Здесь находятся рекомендации по установке, запуску и оптимизации для вычислений на кластере различных программных пакетов

Компиляция и запуск C2PK

C2PK — Программный пакет для квантовой химии и физики твердого тела. Репозиторий на github.

Последовательность сборки пакета в домашнем каталоге

#Выбор mpi - vapich4.1/gcc 8.5.0
module load mvapich4/gcc64

# Вспомогательная библиотека DBCSR от разработчиков C2PK
wget 'https://github.com/cp2k/dbcsr/releases/download/v2.9.1/dbcsr-2.9.1.tar.gz'
tar xf dbcsr-2.9.1.tar.gz

mkdir dbcsr-2.9.1/build
cd dbcsr-2.9.1/build

# каталог установки ~/dbcsr
cmake .. -DUSE_MPI=ON -DCMAKE_C_COMPILER=mpicc -DCMAKE_CXX_COMPILER=mpic++ -DCMAKE_Fortran_COMPILER=mpif90  -DCMAKE_INSTALL_PREFIX=${HOME}/dbcsr

make -j 8
make install

# Возвращаемся в исходный каталог
cd ../..

# Сборка CP2K
wget https://github.com/cp2k/cp2k/releases/download/v2026.1/cp2k-2026.1.tar.bz2
tar xf cp2k-2026.1.tar.bz2

mkdir cp2k-2026.1/build
cd cp2k-2026.1/build

# каталог установки ~/cp2k
cmake .. -DCMAKE_C_COMPILER=mpicc -DCMAKE_CXX_COMPILER=mpic++ -DCMAKE_Fortran_COMPILER=mpif90 -DCP2K_USE_MPI=ON -DCMAKE_INSTALL_PREFIX=${HOME}/cp2k 

make -j 8
make install

cd  ../..

Установка примеров (при желании):

git clone https://github.com/cp2k/cp2k-examples.git

Пример запуска из подкаталога _scratch/work домашнего каталога:

module load mvapich4/gcc64
export LD_LIBRARY_PATH="${HOME}/cp2k/lib64/:$LD_LIBRARY_PATH"
export PATH="${HOME}/cp2k/bin/:$PATH"

mkdir ~/_scratch/work
cd ~/_scratch/work
cp ~/cp2k-examples/gw/1_H2O_GW100/H2O_GW100_def2-QZVP.inp test.inp

export OMP_NUM_THREADS=8
export OMP_PLACES=cores
export OMP_PROC_BIND=true

srun --exclusive --ntasks-per-node=2 --cpus-per-task=8 -N 1 cp2k.psmp -i test.inp > test.out

Оптимизация запуска LAMMPS

Сгенерировано ИИ


Выбор оптимального числа узлов кластера для LAMMPS — это процесс поиска баланса между скоростью счета и эффективностью использования ресурсов. Не существует единственного "правильного" числа, так как оно зависит от размера вашей системы, аппаратного обеспечения и физической модели. Вот пошаговая стратегия, которая поможет вам найти этот оптимум.

1. Проведите тест масштабирования

Это главный метод для определения лимитов масштабируемости. Суть в том, чтобы взять фиксированную задачу (вашу систему с определенным количеством атомов) и запускать её на нарастающем количестве ядер (например, N=1, 2, 4, 8, 16, 32, 64, 128...).

Что делать: Запустите вашу систему на 100-200 шагов для каждого количества ядер. Используйте команды balance или fix balance для распределения нагрузки .

На что смотреть:

  1. Время расчета (Loop time): Сравните, во сколько раз ускорился расчет. Идеальное ускорение (100%) — это когда на 64 ядрах расчет идет в 64 раза быстрее.
  2. Эффективность: Рассчитайте эффективность как (T1 / TN) / N * 100%. Как правило, LAMMPS показывает эффективность >50%, пока на одно ядро приходится несколько сотен атомов .

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

2. Используйте анализ профайлера (Timing Data)

После каждого прогона LAMMPS выводит детальную статистику. Это ваш главный инструмент диагностики. В конце файла log.lammps вы увидите таблицу:

Section %varavg %total
Pair ... ...
Neigh ... ...
Comm ... ...
Other ... ...

Следите за Comm (Communication): Если процент времени, потраченный на коммуникацию (Comm), при увеличении числа узлов становится слишком большим (например, >30-40%), дальнейшее добавление узлов неэффективно. Прирост производительности будет минимальным .

Следите за %varavg: Высокое значение (близкое к 100%) указывает на сильную несбалансированность нагрузки. Это значит, что одни ядра простаивают в ожидании других. В этом случае стоит сначала попробовать балансировку (fix balance) .

3. Учитывайте геометрию и разбиение (Domain Decomposition)

LAMMPS использует пространственное разбиение: симуляционный ящик режется на прямоугольные блоки, каждый из которых отдается одному MPI-процессу .

Проблема "блинов": Если вы используете "неудобное" число MPI-процессов (например, простое число, такое как 7 или 11), разбиение может получиться несбалансированным (например, длинные и тонкие "слайсы").

Что делать: Используйте команду processors в скрипте, чтобы вручную задать раскладку сетки (например, processors 4 4 4 для 64 ядер), чтобы блоки были максимально кубическими. Это минимизирует площадь поверхности обмена данными .

4. Учитывайте тип потенциала и системы

Разные задачи масштабируются по-разному :

Потенциалы малого радиуса (LJ, EAM): Обычно хорошо масштабируются. Ограничением часто становится сетка для дальнодействия (PPPM).

Дальнодействие (Kspace, PPPM): Если в системе есть кулоновские взаимодействия (вода, ионы), расчеты PPPM включают быстрые преобразования Фурье (FFT). FFT требует глобальной коммуникации, что сильно ухудшает масштабируемость за пределы одного узла. В таких системах "золотой серединой" часто является 1-4 узла, даже если у вас много ядер.

Связанные списки (Neigh): Если в профайлере Neigh занимает >50% времени, попробуйте увеличить параметр every в команде neigh_modify (например, с 1 на 10), чтобы реже перестраивать списки соседей .

5. Настройка гибридного параллелизма (MPI + OpenMP)

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

Правило: Запускайте 1 MPI-процесс на сокет (физический чип) или на группу ядер, используя OpenMP для распараллеливания внутри узла.

Зачем: Это уменьшает количество MPI-сообщений, которыми обмениваются узлы, и снижает нагрузку на коммуникационную сеть .


Резюме: Пошаговый алгоритм действий

  1. Оцените размер: Для хорошей производительности на одно ядро должно приходиться от 500 до 10 000 атомов.
  2. Балансировка: Если система неоднородна (например, жидкость с пузырьками или мембрана), обязательно используйте fix balance 10 1.1 rcb .
  3. Тест: Начните с 1 узла, увеличивая количество ядер (но не выходя за пределы 500–1000 атомов/ядро).
  4. Проверка узлов: Когда эффективность на одном узле упадет ниже 70-80% (смотрите на рост Comm), начните добавлять второй, третий и четвертый узлы.
  5. Стоп-критерий: Как только время расчета перестает уменьшаться пропорционально количеству добавленных ядер (например, добавили 10 ядер, а расчет стал быстрее только на 5%), вы нашли оптимум.

Важное примечание

Официальная документация LAMMPS подчеркивает: "Нет замены определению узких мест производительности и опробованию различных вариантов" . Всегда проверяйте гипотезы короткими прогонами (100-200 шагов) на вашей конкретной системе и вашем конкретном кластере.