Распараллеливание в VASP

Aug 19 2020

У меня есть система, которая имеет 1 k-точку, 54 атома NBANDS=152, и NGZ=80. Я запускаю моделирование AIMD на VASP версии 5.4.4.

Суперкомпьютер имеет 32 ядра на узел. Это кластер LINUX, связанный с Infiniband, современной многоядерной машиной. Мне было интересно, как лучше всего выбрать параметры и запросить ресурсы, чтобы получить эффективный и быстрый расчет. Вот несколько сценариев, которые я рассмотрел. Мне любопытно, какой метод будет «лучшим» (с точки зрения эффективности и скорости).

  1. Основываясь на том, что я читал здесь
  • Я должен запросить что-то вроде 19 полос (152/8). Возможно, установите NBANDS = 160, чтобы запросить даже 20 ядер.
  • Могу ли я установить NCORE = 20 в моем файле INCAR и запросить 20 ядер на 1 узле?
  • Или было бы лучше установить NCORE = 10. А затем запросить что-то вроде 2 узлов и 10 ядер на узел? или это создаст слишком много коммуникационных накладных расходов и замедлит симуляцию?
  1. Если я решу использовать # ядер = # атомов = 54
  • Могу ли я установить NCORE = 32, а затем запросить 54 ядра на 2 узлах (32 на 1 узле + 22 на втором)? Или 9 ядер / узел и 6 узлов?
  1. Разве я не могу просто запросить весь узел? 1 узел, 32 ядра
  • поэтому установите NCORE = 32, и я просто запрашиваю весь узел. Однако руководство VASP предлагает против этого, потому что это сделает NPAR = 1
  • это меня немного смущает, потому что я предполагаю, что 32 ядра на одном узле были бы более эффективными, чем наличие ядер на нескольких узлах, взаимодействующих друг с другом.

Ответы

11 TristanMaxson Aug 20 2020 at 04:04

Как человек, который провел много тестов для VASP, я предлагаю вам попробовать экспериментальный подход. Я действительно верю, что VASP добавит вам дополнительные бэнды, если понадобится распараллеливание, поэтому я бы не стал беспокоиться об этом лично. Компоновка узла физически (32 ядра на 1 процессоре против 16 ядер на 2 процессорах против специальных схем процессоров AMD на одном процессоре) может значительно отличаться от кластера к кластеру, вы не можете узнать, что является оптимальным, не попробовав.

Поскольку кажется, что вы запускаете моделирование MD, я думаю, что стоит протестировать каждую систему, прежде чем запускать длительное моделирование. Незначительные изменения не требуют повторной оценки, но если вы перейдете от 50 до 150–300 атомов, идеал может измениться. Выполните серию быстрых вычислений со всем диапазоном NCORE, который кажется разумным. Используйте лучший результат. Я стараюсь проверять каждый фактор самого большого узла.

Для 32 ядер я бы проверил NCORE = (1, 2, 4, 8, 16, 32). Я бы рассчитал это против 10 или около того геометрических шагов. Это может показаться пустой тратой времени, но в конечном итоге может сэкономить много времени в будущем.

Я почти всегда предлагаю запрашивать целые узлы, если у вас нет веской причины не делать этого. Вы можете в конечном итоге увидеть вариант KPAR, оглядываясь вокруг, я слышал смешанные мнения. Я лично никогда не получал лучшего результата с распараллеливанием kpoint, чем без него. Однако это может повлиять на память.

7 DoubleKx Aug 21 2020 at 03:50

Я думал, что опубликую результаты тестирования в соответствии с предложением Тристана. Может быть, это будет кому-то полезно в будущем. Я сделал всего 10 шагов в MD (размер шага 1 фс, всего 10 фс).

Все процентные различия относятся к запуску NCORE = 1 с 32 ядрами и 1 узлом. При переходе к 2 узлам с 64 ядрами (NCORE = 32) происходит ускорение на 33%.

Очевидно, это может отличаться в зависимости от вашего кластера. Это, кстати, кластер Грэма на Sharcnet в Канаде - так что, надеюсь, он будет полезен другим канадцам :)