tddft opt (cs vs c1)

[surius]

Добрый день господа,
Зашел в тупик с решением проблемы оптимизирования геометрии в возбужденном состоянии (с1). А именно: обнаружилась странная особенность, 
данная структурка прекрасно оптимизируется в Cs, но совершенно отказывается оптимизироваться в C1. Оптимизация ведется в  базисный 
набор 6-311++(d,p), с учетом только синглетных состояний. Под словами не хочет оптимизироваться слудует понимать, что расчет несходиться, но в тоже время и не останавливается аварийно. Просто проходит 
все итерации и потом сообцает что сходимости нет.
Может кто из уважаемых форумчан встречался с таком когда-нибудь, или просто имеет соображения почему такое вообще может происходить, моих способностей для объяснения оного просто не хватает

[sanya1024]

Покажите выдачу (в заархивированном виде, конечно).

[surius]

Покажите выдачу

простите за долгое молчание, я уже и отчаился думал, вы в не зоны доступа.
выдача в прикрепленных файлах.

pass: 314159265

[sanya1024]

Я уже вернулась, включаюсь потихоньку

[sanya1024]

Честно говоря, я в Гауссиане не спец, возможно, проблемы именно из-за каких-то особенностей Гауссиана и его взаимодействия с *.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) -- переполненный и линейно зависимый, что может приводить к странностям. Гамесс, скорее всего, будет ругаться, заставит принимать меры (потом расскажу, если понадобится). Гауссиан на такие мелочи как дико переполненный базис, похоже, внимания не обращает. Как он с этим справляется -- только его разработчикам ведомо (ау, кто знает!)

[surius]

Есть еще вероятность, что базис 6-311++G(d,p) -- переполненный и линейно зависимый, что может приводить к странностям... Гауссиан на такие мелочи как дико переполненный базис, похоже, внимания не обращает. Как он с этим справляется -- только его разработчикам ведомо (ау, кто знает!)

sanya1024, снимаю перед вами воображаемую шляпу . 
Ну то есть хочу сказать вам огромное спасибо за плодотворную идею.
Внемля вашему совету о смене базиса, основанном на предположении о переполнености базиса и/или некорретное работе G. с
.chk проделал следующие манипуляции: взял оптимизированную геометрию (c1) для S0 полученную B3LYP и ручками протощил ее через все стадии
переоптимизировал S0--->VE--->opt td для геометрии с1 использую Даннинговский cc-pvdz и все прекрасно работает. геометрия оптимизируется, значения энергий имеют тот же физически адекватный вид. Все довольны.
К сожалению пока не могу сказать, что именно явилось проблемой - неадекватная работа с .chk или переполненость базиса, 
но судя по наблюдаемым осциляциям склонен грешить на переполненость в частности и на G. в целом. Я попробую 
локализовать проблему, а именно посмотрую как G. работает с последовательным забором данных из .chk - короче говоря там видно будет.
И может быть еще небольшой вопросик в догонку. А если я перейду с cc-pvdz на cc-pvtz есть ли вероятность снова "поймать" 
проблемму переполнености или проблема только с попловским базисом?

ps
а еще не могли бы вы дать ссылочки хоть на какие-нибудь материалы касающиеся переполнености бызисных наборов
способов проверки оного и возможных проявлений такой перепонености

[alxyppv]

Насколько я понимаю, проблему с переполненностью базиса Гауссин решает выкидывая "лишние" функции. Ну это как в Firefly в таких случаях появляется предупреждение о линейной зависимости и предлагается вручную выкинуть часть функций, вызывающих линейную зависимость. Гауссиан это делает автоматически, что видимо и может приводить к артефактам в cложных расчетах.
Проблема была вызвана именно диффузными функциями, а не попловским базисом. Попробуйте поставить aug-cc-pvdz, и скорее всего она появится опять. Гауссиан, судя по всему, не считает нужным сообщать о наличии таких проблем и решает их самостоятельно Если Вы хотите видеть, когда такая проблема может быть - попробуйте запустить задачу в Firefly, и он Вас известит о ее наличии.

[sanya1024]

Насчет ссылок, к сожалению, навскидку ничего найти не могу. Я тут основываюсь на личном опыте. В Гамесс и FireFly встроена проверка базиса на линейную зависимость (строго говоря, неполный базис тоже может быть линейно зависимым: например, три копланарных вектора в трехмерном пространстве линейно зависимы, но базис в трехмерном пространстве они не задают). И -- да, в мануале Гамесса тоже обращают особое внимание на диффузные функции.

[surius]

Насколько я понимаю, проблему с переполненностью базиса Гауссин решает выкидывая "лишние" функции.

выкидывание-выкидыванию рознь

Ну это как в Firefly в таких случаях появляется предупреждение о линейной зависимости и предлагается вручную выкинуть часть функций...

как бы я был рад такой возможности. Но это "насекомое" считает, что лучше ориентируется в реалиях. Более того он даже не считает 
нужным известить о линейной зависимости (даже при установке расширенных параметров выдачи)

Проблема была вызвана именно диффузными функциями, а не попловским базисом. Попробуйте поставить aug-cc-pvdz, и скорее всего она появится опять.

Да возможно вы правы насчет дифф. функций. С другой стороны, как показал опыт, гораздо проще (быстрее) посмотреть будут ли 
проблеммы с cc-pvtz (без aug), чем проверять вызовет ли aug-cc-pvdz проблемы  

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

К сожалению у меня нет такой возможности. Из подручных средств, на следующие пол года, только самым обычный ноут и кластер c G. за 2000 км по SSH. наверное нужно будет написать администрации письмо с просьбой поставить FF. Так то они с открытой душой на такие просьбы. (я ведь правельне понимаю что ФФ даже в формате multicore free for use?
(может вы случаем знаете ФФ с OpneMPI дружит?) 

Насчет ссылок, к сожалению, навскидку ничего найти не могу. Я тут основываюсь на личном опыте. В Гамесс и FireFly встроена проверка базиса на линейную зависимость. И -- да, в мануале Гамесса тоже обращают особое внимание на диффузные функции.

счастливые вы - пользователи FF

[sanya1024]

Ну, есть еще Гамесс (к-рый надо собирать руками под конкретную архитектуру)
Собс-но, с FF проблем никаких: скачиваете версию под нужную архитектуру, пишете по прилагаемой к архиву форме письмо для получения пароля, и вуаля!

На самом деле для Ваших целей даже не нужна параллельная версия. Вы можете пропустить задачу с EXETYP=CHECK в непараллельном режиме на своем ноуте. При этом программа оценивает объемы памяти, нужные для расчета, и вообще проверяет, корректно ли задан ввод -- только сам расчет не проводится. В частности, программа проверяет базис на линейную зависимость и показывает, какие функции следует выкинуть. Видимо, в Гауссиане алгоритм проверки аналогичный, но Г. выкидывает все функции сам, никому ничего не говоря. Опять-таки в Гамессе и FF есть параметр, определяющий, с какого момента функции считать линейно зависимыми. Можно им порулить. А в Гауссиане он запрятан глубоко от пользователя.

С cc-pvtz по сравнению с cc-pvdz, скорее всего, никаких проблем с линейной зависимостью не будет. А вот aug-cc-pvdz уже может вызвать проблемы. Ведь дело не в размере базиса, а в "расположении" векторов: вспомните про 3 копланарных вектора в трехмерном пространстве.