Квантовохимическая программа ПРИРОДА
- В этой теме 34 ответа, 9 участников, последнее обновление 13 лет, 11 месяцев назад сделано
Zheka.

Зацените:
Priroda 8 (2008.09.05)
copyright (c) D.N. Laikov
date: Mon Oct 13 04:41:09 2008
parallel on 8 processors
node 0: 'cluster.uimech.org'
node 1: 'node-2'
node 2: 'node-3'
node 3: 'node-5'
node 4: 'cluster.uimech.org'
node 5: 'node-2'
node 6: 'node-3'
node 7: 'node-5'
Memory: 256m (256m) + 768m

Я написал на e-mail Лайкову Д.Н. просьбу скомпилировать ПРИРОДУ под кластер AMD64/Linux/mpich(myrinet). Он быстро откликнулся и всё сделал, за что ему большое спасибо.

Сравнил одну и ту же задачу (расчёт энергии методом RI-MP2/L1 для Zr,Al,Cl,C14,H22), на:
1) 2-х ядрах (один узел, shared-memory) + использование временных файлов; Memory used = 321 486 KB
Memory used = 296 686 KB
Disk used = 1 359 076 KB, 5 615 611 KB written, 61 805 158 KB read
Disk used = 1 174 988 KB, 5 602 120 KB written, 63 477 093 KB read
Message passing statistics:
node sent KB # msg time received time
0 6502965 20443 14.8 6331083 23370 183.3
1 6331083 23370 12.5 6502965 20443 62.6
CPU time = 2170.81 sec = 36.18 min = 0.60 hr = 50.01%
CPU time = 2166.63 sec = 36.11 min = 0.60 hr = 49.92%
REAL time = 4340.58 sec = 72.34 min = 1.21 hr
ratio = 99.93%
2) 8-и ядрах (4 узла, mpich) + direct scf + использование временных файлов; Memory used = 104 084 KB
Memory used = 96 803 KB
...
Memory used = 96 803 KB
Disk used = 340 973 KB, 1 660 024 KB written, 3 753 728 KB read
Disk used = 154 254 KB, 1 252 573 KB written, 2 564 625 KB read
...
Disk used = 151 303 KB, 1 262 203 KB written, 2 708 858 KB read
Message passing statistics:
node sent KB # msg time received time
0 6520597 19913 90.2 6533594 18073 181.1
1 5934661 14291 338.0 6865495 16598 114.7
...
7 5934752 14257 308.7 6865571 16567 113.9
CPU time = 5097.08 sec = 84.95 min = 1.42 hr = 98.30%
CPU time = 5085.72 sec = 84.76 min = 1.41 hr = 98.09%
...
CPU time = 5089.17 sec = 84.82 min = 1.41 hr = 98.15%
REAL time = 5184.97 sec = 86.42 min = 1.44 hr
ratio = 786.30%
3) 8-и ядрах (4 узла, mpich) + временные файлы хранились в оперативной памяти узлов кластера; Memory used = 102 808 KB
Memory used = 95 527 KB
...
Memory used = 95 527 KB
Disk used = 507 944 KB, 1 727 872 KB written, 18 299 528 KB read
Disk used = 300 528 KB, 1 322 012 KB written, 14 799 208 KB read
...
Disk used = 298 637 KB, 1 338 523 KB written, 15 600 260 KB read
Message passing statistics:
node sent KB # msg time received time
0 6286869 16099 67.7 6534622 16905 102.3
1 5950730 13993 133.4 6646807 13654 67.2
...
7 5950447 13989 111.3 6646509 13653 67.1
CPU time = 742.32 sec = 12.37 min = 0.21 hr = 99.93%
CPU time = 742.57 sec = 12.38 min = 0.21 hr = 99.96%
CPU time = 742.96 sec = 12.38 min = 0.21 hr = 100.02%
...
CPU time = 742.64 sec = 12.38 min = 0.21 hr = 99.97%
REAL time = 742.83 sec = 12.38 min = 0.21 hr
ratio = 799.80%
4) 8-и ядрах (4 узла, mpich) + direct scf + временные файлы хранились в оперативной памяти узлов кластера; Memory used = 104 084 KB
Memory used = 96 803 KB
...
Memory used = 96 803 KB
Disk used = 340 973 KB, 1 660 024 KB written, 3 753 728 KB read
Disk used = 154 254 KB, 1 252 573 KB written, 2 564 625 KB read
...
Disk used = 151 303 KB, 1 262 203 KB written, 2 708 858 KB read
Message passing statistics:
node sent KB # msg time received time
0 6520597 19913 81.2 6533594 18073 111.8
1 5934661 14291 326.9 6865495 16598 85.4
...
7 5934752 14257 292.7 6865571 16567 78.3
CPU time = 4951.15 sec = 82.52 min = 1.38 hr = 99.96%
CPU time = 4952.22 sec = 82.54 min = 1.38 hr = 99.98%
...
CPU time = 4953.41 sec = 82.56 min = 1.38 hr = 100.01%
REAL time = 4953.09 sec = 82.55 min = 1.38 hr
ratio = 799.88%
В итоге время расчёта во втором случае даже малость увеличилось. Зато потребляемая память размазалась равномерно по всем узлам. В третьем случае (когда всё хранилось в ОЗУ, т.к. распределение задач на много узлов позволило уместить временные данные в ОЗУ) расчёт ускорился в 6 раз. В 4-м случае (при использовании direct scf) скорость опять падает, польза только от распределения памяти (возможности проведения расчётов, требующих большой объём ОЗУ). При включении direct scf потребляемая дисковая память уменьшилась в 2 раза.
Параллельная версия Priroda 8 — это здорово 🙂 У меня в этой связи вопрос: какие изменения произошли в 8-й версии в плане функциональности, производительности и т.д.?

Документации новой у меня не появилось 🙂
По внешнему виду изменились только 2 верхние строки в выходном файле и появилась возможность распараллеливания (но она была заложена уже в 6-й версии).
Т.е. ничего сказать не могу.
Из проблем 6-й версии можно назвать странноватую процедуру оптимизации (оптимизированная структура часто бывает находится где-то около настоящего минимума). Надеюсь, эта проблема устранена/будет устранена.

Продолжаю тестировать ПРИРОДУ для кластера.
I. В процедуре оптимизации (сканирования и т.п.) прироста производительности не обнаружено (а даже наоборот). Оперативная память самую малость распараллеливается (значение для первого узла, а оно самое большое, примерно одинаковое во всех вариантах, т.е. выгода невелика), а потребление дисковой памяти полностью сосредоточено на первом узле.
Задача: DFT (PBE/3z), Zr2, Al3, Cl2, C44, H79; оптимизация
1. На 2-х ядрах (1 узел)
Memory used = 107 029 KB
Memory used = 32 442 KB
Disk used = 811 182 KB, 14 773 456 KB written, 66 365 288 KB read
Disk used = 0 KB, 2 KB written, 0 KB read
Message passing statistics:
node sent KB # msg time received time
0 30234122 366073 73.9 25761513 963746 304.6
1 25761513 963746 76.7 30234122 366073 728.0
2. На 8-и ядрах (4 узла)
Memory used = 94 766 KB
Memory used = 25 559 KB
...
Memory used = 25 559 KB
Disk used = 811 201 KB, 18 497 655 KB written, 78 747 400 KB read
Disk used = 0 KB, 2 KB written, 0 KB read
...
Disk used = 0 KB, 2 KB written, 0 KB read
Message passing statistics:
node sent KB # msg time received time
0 53269440 454057 561.2 17257456 661811 395.0
1 11075766 482633 619.3 15052323 355237 1286.7
...
7 11310920 482314 429.8 15300961 354899 1334.9
II. В расчёте колебательной задачи замечен 2-х кратный прирост скорости (при 4-х кратном увеличении ядер).
Задача: DFT (PBE/3z), Zr, Cl2, C10 H10; расчёт гессиана
1. На 2-х ядрах (1 узел)
Memory used = 23 345 KB
Memory used = 12 768 KB
Disk used = 234 324 KB, 645 398 KB written, 2 951 768 KB read
Disk used = 0 KB, 0 KB written, 0 KB read
Message passing statistics:
node sent KB # msg time received time
0 2157531 17472 3.1 1520214 68422 5.9
1 1520214 68422 8.7 2157531 17472 27.3
CPU time = 297.93 sec = 4.97 min = 0.08 hr = 99.90%
CPU time = 297.11 sec = 4.95 min = 0.08 hr = 99.63%
REAL time = 298.22 sec = 4.97 min = 0.08 hr
ratio = 199.53%
2. На 8-и ядрах (4 узла)
Memory used = 23 239 KB
Memory used = 12 747 KB
...
Memory used = 12 759 KB
Disk used = 234 330 KB, 645 405 KB written, 2 952 143 KB read
Disk used = 0 KB, 0 KB written, 0 KB read
...
Disk used = 0 KB, 0 KB written, 0 KB read
Message passing statistics:
node sent KB # msg time received time
0 3239874 34037 23.9 991254 35091 33.9
1 439625 32600 33.9 670417 11288 24.9
...
7 466563 32492 29.4 688652 11195 24.9
CPU time = 143.69 sec = 2.39 min = 0.04 hr = 99.96%
CPU time = 143.10 sec = 2.39 min = 0.04 hr = 99.55%
...
CPU time = 143.11 sec = 2.39 min = 0.04 hr = 99.56%
REAL time = 143.74 sec = 2.40 min = 0.04 hr
ratio = 796.38%
У меня такое тоже изредка бывало, когда ППЭ довольно плоская и использовал умолчаемые параметры точности вместо тех, которые применяю обычно:
$grid accur=1e-8 $end
$optimize steps=300 tol=1e-5 $end

$grid accur=1e-8 $end
$optimize steps=300 tol=1e-5 $end
Я пробовал, но какого-то большого толку от этого не получал. Для больших комплексов проще пару раз переоптимизировать. А для маленьких (какой-нибудь ClAlMe2 с релятивистским PBE/L2) как ни крути, как не повышай критерии (выставлял параметры до предела, например accur=1e-12 и т.п., пробовал разные комбинации, добавлял во входной файл оптимизации гессиан и т.д. и т.п.). Так и остаётся одна мнимая частота. Но тут явно ППЭ пологая.
В Gau$$ian-е же при ужесточении критериев решения, сразу появляется и симметрия в структурах АОС, решённых DFT-методами, и пропадают мнимые частоты.
PS: Во вложении задачка для интересующихся. Удастся избавиться от мнимых частот?
Да. Просто начальная геометрия — С2-симметричная и очень близкая к ПС. Пустив оптимизацию с предварительно посчитанным гессианом, я получил минимум. ППЭ здесь действительно экстремально плоская по отношению к вращению метилов — соответствующее колебание всего 5 см-1.
ЗЫ Если нужно, могу приложить файлы с расчетами.

Если можно, то нужно 🙂 У меня так и не получилось данное соединение до конца оптимизировать (раз 20 пробовал), хотя вроде бы делал то же самое что и вы.
На самом деле я не вполне точно описал последовательность действия. Первым шагом было просто оптимизация исходной геометрии. В результате структура в видимых глазом пределах не изменилась, поэтому я счел этот шаг необязательным. А он, как оказалось, важен. После этой оптимизации получается гессиан с одной мнимой частотой (а без нее — без мнимых частот). Далее оптимизация полученной геометрии с приложенным соответствующей ей гессианом дает минимум или ПС (последнее — с saddle=1). Файлы расчетов — в архиве. Порядок расчетов соответствует дате файлов.
Вообще, искать стационарные точки в данном случае — одно мучение, т.к. поверхность ОЧЕНЬ плоская, в пределах 5 кал/моль (не ккал !), да и смысл этого невелик, это гораздо меньше RT. В таких случаях мне помогает сканирование по подходящей координате (расчет тоже есть в архиве). И вполне может оказаться, что найденные стационарные точки — просто артефакты.
Архив великоват для вложения, поэтому он по адресу http://limor1.nioch.nsc.ru/file/ClAlMe2.zip

Спасибо! Я как раз вчера сканированием занимался (просто интересно было дооптимизировать это соединение, поэтому с ним возился, по координате я тоже сканировал из найденых максимумов, вот только переходное состояние не искал).
Не подскажите ответ на вопросов по входным файлам:
Зачем при расчёте гессиана после всех секций приводить энергию?
...
$molecule
z-matrix
...
$end
Energy = -784.12379607
Это как-то используется в ходе расчёта и влияет на сам расчёт?
upd.: Понял причину моих проблем с оптимизацией ClAlMe2. Просто я раньше округлял расстояния и углы в z-матрице до 3-го знака после запятой, т.к. не считал последующие цифры значимыми. Но при решении колебательной задачи в данном случае они, как оказалось, имеют значение.
Зачем при расчёте гессиана после всех секций приводить энергию?
Эта строка никак не влияет. Просто она, видимо, есть в MOL-файлах, содержащих оптимизированные геометрии предыдущих расчетов, их я не глядя вставлял в следующий инпут. (MOL-файлы у меня делает скрипт-обработчик аутпута из строк, помеченных MOL>).
Evgeniy, не подскажете, а где берут эту Priroda? E-mail Лайкова, взятый из его статьи, не действует. Веб-сайта не нашел.
Для ответа в этой теме необходимо авторизоваться.