Multiconfiguration pair-density functional theory

[Demuret]

Из того что я понял, это метод, что позволяет работать с теми молекулами, что не определяются лишь одной конфигурацией, но при этом дешевле, тк используятся dft. Кто нибудь пользовался, или знает где он реализован и есть ли его аналоги?

[Гесс]

Из того что я понял, это метод, что позволяет работать с теми молекулами, что не определяются лишь одной конфигурацией, но при этом дешевле, тк используятся dft. Кто нибудь пользовался, или знает где он реализован и есть ли его аналоги?

https://www.annualreviews.org/doi/full/ ... 419-043839

4. AVAILABLE IMPLEMENTATIONS OF MULTICONFIGURATION PAIR-DENSITY FUNCTIONAL THEORY
MC-PDFT has been implemented in the following codes: Molcas 8 (138), OpenMolcas (12), PySCF (139, 140), and GAMESS (141). DMRG can be used as the full CI solver when OpenMolcas is interfaced with QC Maquis (99, 100). OpenMolcas also has multistate PDFT options: SI-PDFT, XMS-PDFT, and VMS-DFT. Most of the applications described here were carried out with Molcas 8 and OpenMolcas.

Это написано Лаурой Гаглиарди в 2021, с тех пор вряд ли многое сильно изменилось, кроме того на странице ее группы
https://gagliardigroup.uchicago.edu/ope ... a/mc-pdft/ впринципе тот же набор, ну только уточнено что pyscf-forge и даны указания по установке.
С молкасом работал достаточно давно (но не про MC-PDFT), он платный.
опенмолкас бесплатный, не работал, ничего сказать не могу.
PySCF ставил и использовал недавно, с прицелом на ADCC пакет, потом оказалось что с pyscf adcc работает только с малыми системами а как только потребовалось чтото большее чем примеры - пришлось уходить в другой приемлимый для adcc код - psi4. Это разумеется не означает что у pyscf будут проблемы с MC-PDFT, и я даже не уверен у кого в моем случае были руки кривые - у adcc или pyscf (себя я скромно исключаю так как лажа подтверждена разработчиками adcc), но вот по одной попытке - мне не понравилось.
GAMESS - это тот еще трындец, мое скромное мнение, начиная с синтаксиса.
DMRG есть в Орке, не тестил. Но, вот тут https://link.springer.com/article/10.10 ... 21-02830-0 тестили, получилась хрень хотя они старались запихнуть реально огромные активные пространства и PT2 Впрочем для той задачи фейлило почти все кроме безумно дорогого MRDDCI c накрученными критериями, еще более дорогого BS-CCSD (и то только потому что система двухконфигурационна, иначе бы взлетать было нечему), ну и BS-DFT если подбирать функционал и схему расчета под ответ (это ваще идеальный вариант, всегда рекомендую).

UPD. Совсем забыл, в орке есть MCRPA, я его даже попробовал использовать. Мою систему считало быстро, не конвержилось нивкакую и потому ушло на свалку. Возможно там надо подходить с более прямыми руками, но мне некогда руки выравнивать.

[Demuret]

Спасибо за ответ.
Надо будет попробовать pySCF, хотя меня внутрине смущает что софт для рассчетов пишут на питоне, как мне лично кажется не самом лучшем языке для такого.
С первого раза как мне показали gamess удивил его синтаксис, поэтому пока это не станет последним вариантом, то предпочту обойтись.
DMRG это все же метод для того чтобы сильно увеличить возможное для рассчетов активное пространства.
Что-то проглядел в мануале орки mcrpa, а сколько базисных функций было в вашей системе, если не секрет и на сколько она была экзотична?

[Гесс]

Надо будет попробовать pySCF, хотя меня внутрине смущает что софт для рассчетов пишут на питоне, как мне лично кажется не самом лучшем языке для такого.

Мне как бы всеравно что у кода "под капотом", но в 2 из 2 опробованных питоновских кодов вылезали ну очень странные фишки. Типа "аутпут/лог не пишем впринципе, временные файлы не пишем впринципе, держим все в памяти до упора (потребляя при этом до 3 Тб оперативы), потом как повезет"

Что-то проглядел в мануале орки mcrpa, а сколько базисных функций было в вашей системе, если не секрет и на сколько она была экзотична?

См мануал 8.5.2, 9.28.2.

750 базисных функций. Саму систему в ближайшие полгода не покажу, это некоторое производное copper paddle wheel с нечетным количеством электронов, которое с формальной точки зрения не является мультиреференсом, а с практической - там не работают TDDFT (дает полный рандом), RI-CC2, ADC, MCRPA (не сводятся), недоступен bt-PNO-EOM-CCSD (ввиду цены, а STEOM-DLPNO в виду UHF), CASSCF и NEVPT2 расходятся на 130 нм, а MRDDCI3 болтает из конца в конец от изменения чего угодно (ужесточения критериев отсечки, смены исходных орбиталей с канонических на кас-натуральные, подключения mrci-натурализации орбиталей и это я не говорю о более явных вещах типа экстраполяции to unselected MR-CI через Psi(0) vs FullMP2 либо про подключение Давидсона). Вообщем будь проклят тот день когда я сел за баранку этого пылесоса кажется экзотичная на ровном месте.

[Demuret]

Мне как бы всеравно что у кода "под капотом", но в 2 из 2 опробованных питоновских кодов вылезали ну очень странные фишки. Типа "аутпут/лог не пишем впринципе, временные файлы не пишем впринципе, держим все в памяти до упора (потребляя при этом до 3 Тб оперативы), потом как повезет"

Ну достаточно часто под написанный на питоне или неожиданно часто вылетает или нестабилен или неоптимизирован и писать на нем что-то серьёзное для постоянного использования особый способ помучить пользователя, но на нем легко писать.
Никогда не подумал бы, что медные китайские фонарики могут быть столь сложны в теоретическом описание.
А может быть для счастья просто не хватает какой-то мелочи типо релятиаизма?))

[kbob]

Спасибо за ответ.
Надо будет попробовать pySCF, хотя меня внутрине смущает что софт для рассчетов пишут на питоне, как мне лично кажется не самом лучшем языке для такого.

Там 12.6% языка С, а из Python в основном numpy
Меня больше смущают авторы: Qiming Sun, Xing Zhang, Peng Bao
https://github.com/search?q=repo%3Apysc ... &type=code