Внимание!

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

Квантовохимическая программа ПРИРОДА

Просмотр 15 сообщений - с 16 по 30 (из 35 всего)
Хранитель
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

Участник
DrkChemist
Участник

А где такое чудо можно взять?

Хранитель
Zheka
Хранитель
DrkChemist писал(а):
А где такое чудо можно взять?

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

Хранитель
Zheka
Хранитель

Сравнил одну и ту же задачу (расчёт энергии методом 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 раза.

Участник
SeriousSem
Участник

Параллельная версия Priroda 8 — это здорово 🙂 У меня в этой связи вопрос: какие изменения произошли в 8-й версии в плане функциональности, производительности и т.д.?

Хранитель
Zheka
Хранитель
SeriousSem писал(а):
Параллельная версия Priroda 8 — это здорово 🙂 У меня в этой связи вопрос: какие изменения произошли в 8-й версии в плане функциональности, производительности и т.д.?

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

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

Хранитель
Zheka
Хранитель

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

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%

Участник
amg
Участник
Zheka писал(а):
Из проблем 6-й версии можно назвать странноватую процедуру оптимизации (оптимизированная структура часто бывает находится где-то около настоящего минимума).

У меня такое тоже изредка бывало, когда ППЭ довольно плоская и использовал умолчаемые параметры точности вместо тех, которые применяю обычно:
$grid accur=1e-8 $end
$optimize steps=300 tol=1e-5 $end

Хранитель
Zheka
Хранитель
amg писал(а):
У меня такое тоже изредка бывало, когда ППЭ довольно плоская и использовал умолчаемые параметры точности вместо тех, которые применяю обычно:
$grid accur=1e-8 $end
$optimize steps=300 tol=1e-5 $end

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

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

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

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

Да. Просто начальная геометрия — С2-симметричная и очень близкая к ПС. Пустив оптимизацию с предварительно посчитанным гессианом, я получил минимум. ППЭ здесь действительно экстремально плоская по отношению к вращению метилов — соответствующее колебание всего 5 см-1.

ЗЫ Если нужно, могу приложить файлы с расчетами.

Хранитель
Zheka
Хранитель
amg писал(а):
ЗЫ Если нужно, могу приложить файлы с расчетами.

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

Участник
amg
Участник

На самом деле я не вполне точно описал последовательность действия. Первым шагом было просто оптимизация исходной геометрии. В результате структура в видимых глазом пределах не изменилась, поэтому я счел этот шаг необязательным. А он, как оказалось, важен. После этой оптимизации получается гессиан с одной мнимой частотой (а без нее — без мнимых частот). Далее оптимизация полученной геометрии с приложенным соответствующей ей гессианом дает минимум или ПС (последнее — с saddle=1). Файлы расчетов — в архиве. Порядок расчетов соответствует дате файлов.

Вообще, искать стационарные точки в данном случае — одно мучение, т.к. поверхность ОЧЕНЬ плоская, в пределах 5 кал/моль (не ккал !), да и смысл этого невелик, это гораздо меньше RT. В таких случаях мне помогает сканирование по подходящей координате (расчет тоже есть в архиве). И вполне может оказаться, что найденные стационарные точки — просто артефакты.

Архив великоват для вложения, поэтому он по адресу http://limor1.nioch.nsc.ru/file/ClAlMe2.zip

Хранитель
Zheka
Хранитель
amg писал(а):
Архив великоват для вложения, поэтому он по адресу http://limor1.nioch.nsc.ru/file/ClAlMe2.zip

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

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

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

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

Участник
amg
Участник
Zheka писал(а):
Не подскажите ответ на вопросов по входным файлам:
Зачем при расчёте гессиана после всех секций приводить энергию?

Эта строка никак не влияет. Просто она, видимо, есть в MOL-файлах, содержащих оптимизированные геометрии предыдущих расчетов, их я не глядя вставлял в следующий инпут. (MOL-файлы у меня делает скрипт-обработчик аутпута из строк, помеченных MOL>).

Участник
КВГ
Участник

Evgeniy, не подскажете, а где берут эту Priroda? E-mail Лайкова, взятый из его статьи, не действует. Веб-сайта не нашел.

Просмотр 15 сообщений - с 16 по 30 (из 35 всего)

Для ответа в этой теме необходимо авторизоваться.

abcdefghijklmnopqrstuvwxyz абвгдеёжзийклмнопрстуфхцчшщьыъэюя
abcdefghijklmnopqrstuvwxyz абвгдеёжзийклмнопрстуфхцчшщьыъэюя
Сменить аватар
Секретный вопрос
<%= q %>
Наложить бан
Пользователь
USER
Сделать предупреждение
Пользователю
USER