Зацените:

Priroda 8 (2008.09.05)
copyright (c) D.N. Laikov

Memory: 256m (256m) + 768m

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

Продолжаю тестировать ПРИРОДУ для кластера.

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%

Я пробовал, но какого-то большого толку от этого не получал. Для больших комплексов проще пару раз переоптимизировать. А для маленьких (какой-нибудь ClAlMe2 с релятивистским PBE/L2) как ни крути, как не повышай критерии (выставлял параметры до предела, например accur=1e-12 и т.п., пробовал разные комбинации, добавлял во входной файл оптимизации гессиан и т.д. и т.п.). Так и остаётся одна мнимая частота. Но тут явно ППЭ пологая.

В Gau$$ian-е же при ужесточении критериев решения, сразу появляется и симметрия в структурах АОС, решённых DFT-методами, и пропадают мнимые частоты.

PS: Во вложении задачка для интересующихся. Удастся избавиться от мнимых частот?

Если можно, то нужно 🙂 У меня так и не получилось данное соединение до конца оптимизировать (раз 20 пробовал), хотя вроде бы делал то же самое что и вы.

Спасибо! Я как раз вчера сканированием занимался (просто интересно было дооптимизировать это соединение, поэтому с ним возился, по координате я тоже сканировал из найденых максимумов, вот только переходное состояние не искал).

Не подскажите ответ на вопросов по входным файлам:
Зачем при расчёте гессиана после всех секций приводить энергию?
...
$molecule
z-matrix
...
$end
Energy =   -784.12379607

Это как-то используется в ходе расчёта и влияет на сам расчёт?

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