Расчет

[AlexKsen]

Уважаемые форумчане, почему то не заканчивается расчет. В Гамессе просто только начал работать, поэтому задаю вопрос. Спасибо.

[sanya1024]

Смотрим. Host is node908.eth0.mvs50k.jscc.ru -- о, знаем этот кластер и как на нем работается!
Ваш расчет просто кончился по времени. Вы сколько времени заказывали?
CPU 0: STEP CPU TIME= 1.95 TOTAL CPU TIME= 14399.8 ( 240.0 MIN)
TOTAL WALL CLOCK TIME= 32111.8 SECONDS, CPU UTILIZATION IS 44.84%
CPU TIME=240.0 MIN, а WALL CLOCK TIME (т.е., фактическое время)=535 минут.
То, что CPU UTILIZATION IS 44.84% -- это очень плохо. Смотрим, в чем дело.

PARALLEL VERSION RUNNING ON 64 PROCESSORS IN 8 NODES. Ноды 8-ядерные, все правильно. При запуске указывали -np 128, так? Это нужно потому, что Гамесс на каждой ноде запускает на каждый считающий процесс еще один управляющий (исключительно эффективно: на каждого работника по надсмотрщику).
А собирали Вы его как? (компилятор, библиотеки)

Молекула, конечно, зверская. Но Гамесс не настолько хорошо распараллелен, чтобы на 64 ядрах получить заметный выигрыш в скорости. 32 или на крайняк 48 ядер, думаю, будет нормально.

Еще одна причина -- глюки самого кластера mvs100k. Запросто с ним бывает, что одна и та же задача, в зависимости от того, каким нодам в зубы попадет, может считаться с приличной скоростью и CPU UTILIZATION близким к 100% или жутко медленно и очень низким CPU UTILIZATION (бывает даже ~10-20% !).

Сейчас Вам лучше стартовать оптимизацию с последней точки.

[sanya1024]

Теперь комментирую сам инпут. MEMORY=95536000 -- удобнее пользоваться ключом MWORDS=96 (это память в мегасловах).
GBASIS=N31 NGAUSS=6 -- это базис 6-31G без поляризационных функций. Несерьезно. Уж лучше GBASIS=N31 NGAUSS=6 NDFUNC=1 npfunc=1 -- добавка поляризационных функций. И тогда очень рекомендуется поставить ispher=1 в группу $CONTRL -- чтоб работать со сферическими d функциями, а не с декартовыми. Избавитесь от лин. зависимости и немного уменьшите размер базиса.

Сейчас у Вас по дефолту оптимизация геометрии в декартовых координатах. Это медленно и неэффективно. Лучше к runtyp=optimize добавить NZVAR=<любое ненулевое число>, а еще добавить группу $ZMAT DLC=.TRUE. AUTO=.TRUE. $END -- автоматическая генерация делокализованных координат для оптимизации.

Ну, и базис 6-31G для цинка -- тоже не фонтан...

[AlexKsen]

Спасибо. Время я запрашивал 1200 мин. Да, я и хотел сегодня с последней точки оптимизации поставить снова. Только поставлю с поляризационными функциями. А какой Вы считаете для Zn базис подойдет - какой нибудь cc?

[ Post made via Windows Smartphone ]

[sanya1024]

Да зачем cc? Возьмите ECP (LANL какой-нибудь). На самом деле, базис на Zn -- это не самая серьезная ошибка. BTW, куда Вы помещаете временные файлы? правильно их класть в /scratch (пропишите это в gms-files.sh и в rungms) -- это пространство на локальных дисках нод. Иначе тормозит вся файловая система.

[AlexKsen]

sanya1024, Вы, я как понимаю работаете с Гамессом и очень хорошо в нем разбираетесь. Скажите, пожалуйста, можно ли в Гамессе проводить сканирование ППЭ, как в Гауссиане: замораживая нужную координату, прописать число шагов и изменения к.-л. параметра?

[sanya1024]

Можно замораживать координаты. В той же группе $ZMAT задаете массив координат IFZMAT(1). Например, IFZMAT(1)=1,8,25. Первая цифра -- 1, 2, 3 или 4 -- означает, соответственно, длину связи, валентный угол, торсионный угол или угол выхода из плоскости (out-of-plane). Следующие цифры -- для каких атомов координата. Т.е., 1,8,25 означает длину связи между 8 и 25 атомом. Можно заморозить сразу несколько координат за раз.

Есть еще runtyp=surface и группа $SURF, но там все совершенно по-идиотски сделано, можно сканировать только по межатмному расстоянию (например, растаскивая два фрагмента молекулы), а по углу уже сканировать нельзя.

Зато в FireFly есть runtyp=rsurface -- релаксированный скан. И там в группе $ZMAT можно задать координату для сканирования (+ scan=.t. -- опция, отсутствующая в Гамессе), а в $SURF -- шаг и др. параметры сканирования.

Если не получается перейти на FireFly, то сканирование в Гамессе придется делать через замораживание координат (1 абзац этого поста) и скрипт, выдергивающий оптимизированные координаты и засовывающий их в след. расчет с новым значением замороженной координаты (+ можно прилепить в конец файла $VEC от пред. точки). Кстати, если кто не поленится сделать такой скрипт, будет очень здорово

[AlexKsen]

Я не совсем понимаю, как количество шагов и параметр изменения, длины связи например. Если Вас не затруднит, не могли бы написать пример входного файла для к.-н. простой молекулы, где происходит удлинение длины связи, сканируем 10 шагов, увеличение происходит на 1 ангстрем на каждом шаге. Спасибо большое!

[ Post made via Windows Smartphone ]

[sanya1024]

Пример: растаскивание двух ацетонитрилов, расположенных соосно "голова к голове". Откройте мануал Гамесса и посмотрите значение параметров в группе $SURF.

Код: Выделить всё

 $CONTRL SCFTYP=RHF 
  ICHARG=0 MULT=1
  RUNTYP=SURFACE
  itol=30 icut=11
  ispher=1 COORD=UNIQUE EXETYP=run $END
 $SYSTEM TIMLIM=360000 MWORDS=50 $END
 $BASIS GBASIS=PC1 $END
! $ZMAT DLC=.TRUE. AUTO=.TRUE.
!  NONVDW(1)=2,7
!  IFZMAT(1)=1,2,7 $END
 $SCF DIRSCF=.TRUE. soscf=.f. $END
 $SURF IVEC1(1)=2,7 IGRP1(1)=7,8,9,10,11,12 DISP1=0.05
  ORIG1=-0.450 NDISP1=200 $END
 $DATA
 C4N2H6
C1
NITROGEN    7.0      0.000000000         0.000000000         0.000000000
CARBON      6.0     -0.000010564        -0.000007367         2.618460200
HYDROGEN    1.0      1.030737609         0.000005819         2.996878811
CARBON      6.0     -0.000023203        -0.000004648         1.162437160
HYDROGEN    1.0     -0.515338136         0.892638921         2.996957450
HYDROGEN    1.0     -0.515365706        -0.892632725         2.996966329
NITROGEN    7.0      0.000000000         0.000000000        -2.000000000
CARBON      6.0      0.000010564         0.000007367        -4.618460200
HYDROGEN    1.0     -1.030737609        -0.000005819        -4.996878811
CARBON      6.0      0.000023203         0.000004648        -3.162437160
HYDROGEN    1.0      0.515338136        -0.892638921        -4.996957450
HYDROGEN    1.0      0.515365706         0.892632725        -4.996966329
 $END
 

[AlexKsen]

Спасибо огромное!:)

[amge]

сканирование в Гамессе придется делать через замораживание координат (1 абзац этого поста) и скрипт, выдергивающий оптимизированные координаты и засовывающий их в след. расчет с новым значением замороженной координаты (+ можно прилепить в конец файла $VEC от пред. точки). Кстати, если кто не поленится сделать такой скрипт, будет очень здорово

Идея отличная и давно назрела. Я ее попробовал реализовать. В приложенном архиве - получившийся скрипт. Чтобы пользоваться, первым делом в начале скрипта нужно вбить свое название запускалки гамесса (возможно, с полным путем) и scr-директории.

Запускать так: gms-scan 120,180,3 NH3-zm.inp
120 и 180 - первое и последнее значения FVALUE, 3 - число точек. Т.е. будут проведены три последовательных расчета с FVALUE=120, 150 и 180. Инпут-файл (вместо NH3-zm свое название, конечно) должен быть с правильным синтаксисом и иметь строку типа
$zmat dlc=.t. auto=.t. ifzmat(1)=3,4,1,2,3 fvalue=100 $end
Пример есть в архиве. В исходном файле может быть любой формат координат, но для второго и следующих расчетов будет COORD=UNIQUE.

Оптимизированные координаты и вектора для следующего расчета берутся из dat-файла в scr-директории. Файлы первого расчета будут с индексом 00, затем индекс инкрементируется.

Ограничения. Не предусмотрено замораживание нескольких координат. Не поддерживается группа $DATA с базисами в ней.

[sanya1024]

Спасибо! попробую потестировать. Когда есть большой кластер, то определенно удобнее запустить в параллель сразу несколько задач с разными FVALUE. Но если нода всего одна, то через такой скрипт должно быть удобнее.

[amge]

Когда есть большой кластер, то определенно удобнее запустить в параллель сразу несколько задач с разными FVALUE.

Хм... Не факт. В релаксированном скане нет резких скачков геометрии - тем и хорош. А если в исходную структуру подставить сразу последнее FVALUE, и сканирование идет не по расстоянию между молекулами, а по какому-нибудь внутримолекулярному параметру - то может получиться дикая геометрия, а гамесс таких не любит.

[sanya1024]

Это да, есть такой риск. Особенно если FVALUE сильно отличается от того, что получается в $DATA. Просто мой "любимый" кластер mvs100k лучше справляется с кучей коротких задач, чем с одной длинной.

[AlexKsen]

Задал сканирование: присоединение ацетата к цинку. Получил выходной файл, открываю его в Кемкрафте (может другая программа нужна?), чтобы посмотреть скан-график, а там ничегог нет. Посмотрите, пожалуйста, в чем проблема! Спасибо!

[sanya1024]

23 Мб -- это ничего нет? а текстовым редактором файл открыть не пробовали?
Почему не поставили $SCF DIRSCF=.t. $END? Все отведенное на задачу время программа считала и писала на диск интегралы (ага, с CPU UTILIZATION 8%). После чего успела только прогнать 3 ССП итерации -- какой уж там скан!
Это Вы постоянно своими расчетами подвешиваете всю файловую систему кластера? Я просила показать мне Ваши запускающие скрипты. У Гамесса есть особенности на этом кластере. При неправильной настройке путей Вы никогда результатов не получите, зато заработаете в свой адрес проклятья от других пользователей.

Я вижу, что Вы составляете инпуты в Авогадро. Обязательно после этого открывайте инпут в текстовом редакторе и добавляйте КРАЙНЕ СУЩЕСТВЕННЫЕ ключи, такие как $SCF DIRSCF=.t. $END, оптимизацию в DLC (см. в постах выше) и т.п. Гамессовские дефолтные настройки не всегда оптимальны, это надо помнить.

[AlexKsen]

Я стараюсь не загружать класстер и поэтому считаю раз в неделю, поэтому проблемы в перегрузке файловой системе, я не должен доставлять! Прикрепляю скрипты для запуска. А сам входной файл в $SURF я правильно все прописал?$SCF DIRSCF=.T. это для чего? Извините, что злоупотребляю Вашей отзывчивостью! Спасибо большое!

[sanya1024]

ОМГ! Вы считаете августовской версией 11 года! медленной и глючной! срочно апгрейдимся. Вышла уже версия 13 года (я ее пока не собирала), но и 12-я работает гораздо лучше 11-й. Пишите в личку, пущу в свою директорию, где собрана версия 12 года.

Со скриптами у Вас все хорошо, файловую систему вешает кто-то другой (поймаю -- убью!).

DIRSCF=.T. включает прямой ССП расчет без записи интегралов на диск. Это рекомендуется для задач с >50 баз. функций. Иначе процесс общения программы с дисками на считающих нодах и передачи огромных массивов по сети займет все время и все ресурсы. Дефолтный вариант годится для маленьких тестовых задач.

Чтобы проверить, правильно ли все в $SURF, поставьте gbasis=am1 и запустите расчет. Это будет гораздо быстрее, чем нормальный расчет DFT, сможете Кемкрафтом посмотреть. И всегда смотрите выдачи текстовым редактором -- половина вопросов сама отпадет

[AlexKsen]

sanya1024, спасибо Вам огромное! Значит все, что я насчитал не пригодиться:( Жалко, что столько времени потратилось, а дажи и посмотреть не на что:( Я рад, что это не я повинен в торможении файловой системы:))

[sanya1024]

Вот сейчас полезла выкладывать для Вас в открытое место файлы Гамесса -- и опять повисла файловая система. Ей-богу, найду того, кто это делает -- руки-ноги поотрываю