tddft opt (cs vs c1)
tddft opt (cs vs c1)
Добрый день господа,
Зашел в тупик с решением проблемы оптимизирования геометрии в возбужденном состоянии (с1). А именно: обнаружилась странная особенность,
данная структурка прекрасно оптимизируется в Cs, но совершенно отказывается оптимизироваться в C1. Оптимизация ведется в базисный
набор 6-311++(d,p), с учетом только синглетных состояний. Под словами не хочет оптимизироваться слудует понимать, что расчет несходиться, но в тоже время и не останавливается аварийно. Просто проходит
все итерации и потом сообцает что сходимости нет.
Может кто из уважаемых форумчан встречался с таком когда-нибудь, или просто имеет соображения почему такое вообще может происходить, моих способностей для объяснения оного просто не хватает
Зашел в тупик с решением проблемы оптимизирования геометрии в возбужденном состоянии (с1). А именно: обнаружилась странная особенность,
данная структурка прекрасно оптимизируется в Cs, но совершенно отказывается оптимизироваться в C1. Оптимизация ведется в базисный
набор 6-311++(d,p), с учетом только синглетных состояний. Под словами не хочет оптимизироваться слудует понимать, что расчет несходиться, но в тоже время и не останавливается аварийно. Просто проходит
все итерации и потом сообцает что сходимости нет.
Может кто из уважаемых форумчан встречался с таком когда-нибудь, или просто имеет соображения почему такое вообще может происходить, моих способностей для объяснения оного просто не хватает
"Bite my shiny metal ass"
Bender
Bender
Re: tddft opt (cs vs c1)
Покажите выдачу (в заархивированном виде, конечно).
Вот и вся моя работа. Стеречь ребят над пропастью во ржи. (Дж. Д. Сэлинджер)
Re: tddft opt (cs vs c1)
простите за долгое молчание, я уже и отчаился думал, вы в не зоны доступа.sanya1024 писал(а):Покажите выдачу
выдача в прикрепленных файлах.
pass: 314159265
У вас нет необходимых прав для просмотра вложений в этом сообщении.
Последний раз редактировалось surius Вт апр 03, 2012 1:12 pm, всего редактировалось 1 раз.
"Bite my shiny metal ass"
Bender
Bender
Re: tddft opt (cs vs c1)
Я уже вернулась, включаюсь потихоньку
Вот и вся моя работа. Стеречь ребят над пропастью во ржи. (Дж. Д. Сэлинджер)
Re: tddft opt (cs vs c1)
Честно говоря, я в Гауссиане не спец, возможно, проблемы именно из-за каких-то особенностей Гауссиана и его взаимодействия с *.chk файлом?
Что я вижу: Total Energy, E(TD-HF/TD-KS) состояния Excited State 1 при оптимизации в Cs (если все правильно задано) честно падает, никакого квазивырождения с близлежащими состояниями нет и все ОК. В C1 творится нечто безумное: с самого начала Total Energy, E(TD-HF/TD-KS) состояния Excited State 1 выше, чем в задаче с симметрией (что уже само по себе подозрительно), а при дальнейшей оптимизации она (после некоторого падения) начинает расти, а потом осциллирует. Например, смотрим на одном из последних шагов (там, где осцилляции):
Excited State 1: Singlet-A 3.8110 eV
Excited State 2: Singlet-A 3.6587 eV
Excited State 3: Singlet-A 2.6199 eV
(т.е., 3-е состояние сейчас имеет самую низкую энергию, потом 2-е, а 1-е -- самую высокую. Бред какой-то...) И такая петрушка началась с 8-го шага (примерно там, где начались осцилляции), до этого хотя бы порядок состояний был нормальным.
Может, выложите незапароленные архивы, чтобы люди, более опытные в Гауссиане смогли посмотреть? я, в свою очередь, попробую пропустить эту задачу в Гамессе (возможно, не сегодня-завтра, а где-то на неделе). А Вы возьмите оптимизированную в C1 геометрию основного состояния и с нуля, без чтения из чекпойнта, запустите оптимизацию возбужденного (в C1).
Есть еще вероятность, что базис 6-311++G(d,p) -- переполненный и линейно зависимый, что может приводить к странностям. Гамесс, скорее всего, будет ругаться, заставит принимать меры (потом расскажу, если понадобится). Гауссиан на такие мелочи как дико переполненный базис, похоже, внимания не обращает. Как он с этим справляется -- только его разработчикам ведомо (ау, кто знает!)
Что я вижу: Total Energy, E(TD-HF/TD-KS) состояния Excited State 1 при оптимизации в Cs (если все правильно задано) честно падает, никакого квазивырождения с близлежащими состояниями нет и все ОК. В C1 творится нечто безумное: с самого начала Total Energy, E(TD-HF/TD-KS) состояния Excited State 1 выше, чем в задаче с симметрией (что уже само по себе подозрительно), а при дальнейшей оптимизации она (после некоторого падения) начинает расти, а потом осциллирует. Например, смотрим на одном из последних шагов (там, где осцилляции):
Excited State 1: Singlet-A 3.8110 eV
Excited State 2: Singlet-A 3.6587 eV
Excited State 3: Singlet-A 2.6199 eV
(т.е., 3-е состояние сейчас имеет самую низкую энергию, потом 2-е, а 1-е -- самую высокую. Бред какой-то...) И такая петрушка началась с 8-го шага (примерно там, где начались осцилляции), до этого хотя бы порядок состояний был нормальным.
Может, выложите незапароленные архивы, чтобы люди, более опытные в Гауссиане смогли посмотреть? я, в свою очередь, попробую пропустить эту задачу в Гамессе (возможно, не сегодня-завтра, а где-то на неделе). А Вы возьмите оптимизированную в C1 геометрию основного состояния и с нуля, без чтения из чекпойнта, запустите оптимизацию возбужденного (в C1).
Есть еще вероятность, что базис 6-311++G(d,p) -- переполненный и линейно зависимый, что может приводить к странностям. Гамесс, скорее всего, будет ругаться, заставит принимать меры (потом расскажу, если понадобится). Гауссиан на такие мелочи как дико переполненный базис, похоже, внимания не обращает. Как он с этим справляется -- только его разработчикам ведомо (ау, кто знает!)
Вот и вся моя работа. Стеречь ребят над пропастью во ржи. (Дж. Д. Сэлинджер)
Re: tddft opt (cs vs c1)
sanya1024, снимаю перед вами воображаемую шляпу .sanya1024 писал(а):Есть еще вероятность, что базис 6-311++G(d,p) -- переполненный и линейно зависимый, что может приводить к странностям... Гауссиан на такие мелочи как дико переполненный базис, похоже, внимания не обращает. Как он с этим справляется -- только его разработчикам ведомо (ау, кто знает!)
Ну то есть хочу сказать вам огромное спасибо за плодотворную идею.
Внемля вашему совету о смене базиса, основанном на предположении о переполнености базиса и/или некорретное работе G. с
.chk проделал следующие манипуляции: взял оптимизированную геометрию (c1) для S0 полученную B3LYP и ручками протощил ее через все стадии
переоптимизировал S0--->VE--->opt td для геометрии с1 использую Даннинговский cc-pvdz и все прекрасно работает. геометрия оптимизируется, значения энергий имеют тот же физически адекватный вид. Все довольны.
К сожалению пока не могу сказать, что именно явилось проблемой - неадекватная работа с .chk или переполненость базиса,
но судя по наблюдаемым осциляциям склонен грешить на переполненость в частности и на G. в целом. Я попробую
локализовать проблему, а именно посмотрую как G. работает с последовательным забором данных из .chk - короче говоря там видно будет.
И может быть еще небольшой вопросик в догонку. А если я перейду с cc-pvdz на cc-pvtz есть ли вероятность снова "поймать"
проблемму переполнености или проблема только с попловским базисом?
ps
а еще не могли бы вы дать ссылочки хоть на какие-нибудь материалы касающиеся переполнености бызисных наборов
способов проверки оного и возможных проявлений такой перепонености
"Bite my shiny metal ass"
Bender
Bender
Re: tddft opt (cs vs c1)
Насколько я понимаю, проблему с переполненностью базиса Гауссин решает выкидывая "лишние" функции. Ну это как в Firefly в таких случаях появляется предупреждение о линейной зависимости и предлагается вручную выкинуть часть функций, вызывающих линейную зависимость. Гауссиан это делает автоматически, что видимо и может приводить к артефактам в cложных расчетах.
Проблема была вызвана именно диффузными функциями, а не попловским базисом. Попробуйте поставить aug-cc-pvdz, и скорее всего она появится опять. Гауссиан, судя по всему, не считает нужным сообщать о наличии таких проблем и решает их самостоятельно Если Вы хотите видеть, когда такая проблема может быть - попробуйте запустить задачу в Firefly, и он Вас известит о ее наличии.
Проблема была вызвана именно диффузными функциями, а не попловским базисом. Попробуйте поставить aug-cc-pvdz, и скорее всего она появится опять. Гауссиан, судя по всему, не считает нужным сообщать о наличии таких проблем и решает их самостоятельно Если Вы хотите видеть, когда такая проблема может быть - попробуйте запустить задачу в Firefly, и он Вас известит о ее наличии.
А.П.
Re: tddft opt (cs vs c1)
Насчет ссылок, к сожалению, навскидку ничего найти не могу. Я тут основываюсь на личном опыте. В Гамесс и FireFly встроена проверка базиса на линейную зависимость (строго говоря, неполный базис тоже может быть линейно зависимым: например, три копланарных вектора в трехмерном пространстве линейно зависимы, но базис в трехмерном пространстве они не задают). И -- да, в мануале Гамесса тоже обращают особое внимание на диффузные функции.
Вот и вся моя работа. Стеречь ребят над пропастью во ржи. (Дж. Д. Сэлинджер)
Re: tddft opt (cs vs c1)
выкидывание-выкидыванию розньalxyppv писал(а):Насколько я понимаю, проблему с переполненностью базиса Гауссин решает выкидывая "лишние" функции.
как бы я был рад такой возможности. Но это "насекомое" считает, что лучше ориентируется в реалиях. Более того он даже не считаетalxyppv писал(а):Ну это как в Firefly в таких случаях появляется предупреждение о линейной зависимости и предлагается вручную выкинуть часть функций...
нужным известить о линейной зависимости (даже при установке расширенных параметров выдачи)
alxyppv писал(а):Проблема была вызвана именно диффузными функциями, а не попловским базисом. Попробуйте поставить aug-cc-pvdz, и скорее всего она появится опять.
Да возможно вы правы насчет дифф. функций. С другой стороны, как показал опыт, гораздо проще (быстрее) посмотреть будут ли
проблеммы с cc-pvtz (без aug), чем проверять вызовет ли aug-cc-pvdz проблемы
К сожалению у меня нет такой возможности. Из подручных средств, на следующие пол года, только самым обычный ноут и кластер c G. за 2000 км по SSH. наверное нужно будет написать администрации письмо с просьбой поставить FF. Так то они с открытой душой на такие просьбы. (я ведь правельне понимаю что ФФ даже в формате multicore free for use?alxyppv писал(а):Если Вы хотите видеть, когда такая проблема может быть - попробуйте запустить задачу в Firefly, и он Вас известит о ее наличии.
(может вы случаем знаете ФФ с OpneMPI дружит?)
счастливые вы - пользователи FFsanya1024 писал(а):Насчет ссылок, к сожалению, навскидку ничего найти не могу. Я тут основываюсь на личном опыте. В Гамесс и FireFly встроена проверка базиса на линейную зависимость. И -- да, в мануале Гамесса тоже обращают особое внимание на диффузные функции.
"Bite my shiny metal ass"
Bender
Bender
Re: tddft opt (cs vs c1)
Ну, есть еще Гамесс (к-рый надо собирать руками под конкретную архитектуру)
Собс-но, с FF проблем никаких: скачиваете версию под нужную архитектуру, пишете по прилагаемой к архиву форме письмо для получения пароля, и вуаля!
На самом деле для Ваших целей даже не нужна параллельная версия. Вы можете пропустить задачу с EXETYP=CHECK в непараллельном режиме на своем ноуте. При этом программа оценивает объемы памяти, нужные для расчета, и вообще проверяет, корректно ли задан ввод -- только сам расчет не проводится. В частности, программа проверяет базис на линейную зависимость и показывает, какие функции следует выкинуть. Видимо, в Гауссиане алгоритм проверки аналогичный, но Г. выкидывает все функции сам, никому ничего не говоря. Опять-таки в Гамессе и FF есть параметр, определяющий, с какого момента функции считать линейно зависимыми. Можно им порулить. А в Гауссиане он запрятан глубоко от пользователя.
С cc-pvtz по сравнению с cc-pvdz, скорее всего, никаких проблем с линейной зависимостью не будет. А вот aug-cc-pvdz уже может вызвать проблемы. Ведь дело не в размере базиса, а в "расположении" векторов: вспомните про 3 копланарных вектора в трехмерном пространстве.
Собс-но, с FF проблем никаких: скачиваете версию под нужную архитектуру, пишете по прилагаемой к архиву форме письмо для получения пароля, и вуаля!
На самом деле для Ваших целей даже не нужна параллельная версия. Вы можете пропустить задачу с EXETYP=CHECK в непараллельном режиме на своем ноуте. При этом программа оценивает объемы памяти, нужные для расчета, и вообще проверяет, корректно ли задан ввод -- только сам расчет не проводится. В частности, программа проверяет базис на линейную зависимость и показывает, какие функции следует выкинуть. Видимо, в Гауссиане алгоритм проверки аналогичный, но Г. выкидывает все функции сам, никому ничего не говоря. Опять-таки в Гамессе и FF есть параметр, определяющий, с какого момента функции считать линейно зависимыми. Можно им порулить. А в Гауссиане он запрятан глубоко от пользователя.
С cc-pvtz по сравнению с cc-pvdz, скорее всего, никаких проблем с линейной зависимостью не будет. А вот aug-cc-pvdz уже может вызвать проблемы. Ведь дело не в размере базиса, а в "расположении" векторов: вспомните про 3 копланарных вектора в трехмерном пространстве.
Вот и вся моя работа. Стеречь ребят над пропастью во ржи. (Дж. Д. Сэлинджер)
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 13 гостей