Взаимодействие между компонентами программы через текстовые файлы
Взаимодействие между компонентами программы через текстовые файлы
Эта тема больше посвящена квантовой химии, но я решил разместить её здесь т.к. она может быть интересна также любым программистам.
Программа для квантовых расчётов Gaussian, которой я пользуюсь, имеет кучу косяков, например далеко не идеальный алгоритм оптимизации: так, очень часто финальная геометрия имеет не самую низкую энергию (хотя обычно это мелочь), а иногда оптимизация просто не работает, вылетает, и приходится придумывать костыли.
Такие костыли перестали бы быть костылями, если бы была возможность автоматически запускать Gaussian из другой программы. Например, я написал бы свой алгоритм оптимизации геометрии. Тогда моя программа генерирует входной файл для Gaussian, запускает его и получает выходной файл; его она парсит и берёт оттуда энергию (а также, возможно, градиенты и пр.), далее рассчитывает новую геометрию, снова запускает Gaussian и т.д., до тех пор пока оптимизация не сойдётся.
Если бы такое взаимодействие было удобно сделать, я бы попробовал придумать много чего полезного. Например, я мог бы сделать свою численную оптимизацию, а также расчёт частот для составных методов (G2MP2, FPD). Заодно в алгоритме была бы какая-нибудь эвристическая проверка надёжности результата.
Чтобы это возможно было реализовать, нужно иметь возможность запустить Gaussian из другой программы, и наверно очень желательно предварительно выполнить какую-то виртуализацию диска (т.е. создать виртуальный диск, как бы ещё один винчестер, из оперативной памяти).
Идея такого взаимодействия между программой может показаться слишком сумбурной, но в реальности это очень удобный способ организовать подключение к программам сторонних библиотек. Вот в Chemcraft, например, используется компонент Delphi от сторонних разработчиков, который из набора картинок делает анимированный gif. Когда я переходил от Delphi 7 к Delphi XE, мне пришлось всё это обновлять, искать новую версию этого компонента и часть функций была потеряна (прозрачный фон). А если бы просто был екзешник, которому на вход подаётся текстовой файл с набором инструкций и списком bmp/jpg файлов, а на выходе он бы генерировал gif – это было бы намного удобнее. Такой экзешник как сторонняя библиотека может быть подключен к программе на любом языке, и кроссплатформенные приложения тоже легче делать. Работать он будет чуть медленнее, но для подавляющего большинства задач это не имеет значения.
Есть ли в мировом ИТ попытки перейти на такую парадигму взаимодействия между компонентами? Для этого достаточно важны средства виртуализации диска.
Я ещё боюсь немного оконфузиться насчёт Gaussian-а, т.к. он как раз состоит из множества link-ов, но я не знаю как работают эти линки и не хочу разбираться, я хочу просто запустить главную программу, чтобы она мне входной файл превратила в выходной.
Если такой интерфейс когда-нибудь станет доступен, я смогу попробовать реализовать, например, такие вещи, как:
- Сделать составной метол (FPD) очень удобным, с оптимизацией геометрии и частотами, и с эвристической оценкой точности полученного результата;
- Просчитать одну молекулу, точнее одну геометрию, десятком разных DFT-функционалов, прогнать результаты через нейросеть и получить очень точную энергию;
- Сделать свой ONIOM, в котором вместо двух слоёв есть три: слой A, который считается на дорогом методе, слой B, который считается на дешёвом, и слой AB, который считается на обоих.
Программа для квантовых расчётов Gaussian, которой я пользуюсь, имеет кучу косяков, например далеко не идеальный алгоритм оптимизации: так, очень часто финальная геометрия имеет не самую низкую энергию (хотя обычно это мелочь), а иногда оптимизация просто не работает, вылетает, и приходится придумывать костыли.
Такие костыли перестали бы быть костылями, если бы была возможность автоматически запускать Gaussian из другой программы. Например, я написал бы свой алгоритм оптимизации геометрии. Тогда моя программа генерирует входной файл для Gaussian, запускает его и получает выходной файл; его она парсит и берёт оттуда энергию (а также, возможно, градиенты и пр.), далее рассчитывает новую геометрию, снова запускает Gaussian и т.д., до тех пор пока оптимизация не сойдётся.
Если бы такое взаимодействие было удобно сделать, я бы попробовал придумать много чего полезного. Например, я мог бы сделать свою численную оптимизацию, а также расчёт частот для составных методов (G2MP2, FPD). Заодно в алгоритме была бы какая-нибудь эвристическая проверка надёжности результата.
Чтобы это возможно было реализовать, нужно иметь возможность запустить Gaussian из другой программы, и наверно очень желательно предварительно выполнить какую-то виртуализацию диска (т.е. создать виртуальный диск, как бы ещё один винчестер, из оперативной памяти).
Идея такого взаимодействия между программой может показаться слишком сумбурной, но в реальности это очень удобный способ организовать подключение к программам сторонних библиотек. Вот в Chemcraft, например, используется компонент Delphi от сторонних разработчиков, который из набора картинок делает анимированный gif. Когда я переходил от Delphi 7 к Delphi XE, мне пришлось всё это обновлять, искать новую версию этого компонента и часть функций была потеряна (прозрачный фон). А если бы просто был екзешник, которому на вход подаётся текстовой файл с набором инструкций и списком bmp/jpg файлов, а на выходе он бы генерировал gif – это было бы намного удобнее. Такой экзешник как сторонняя библиотека может быть подключен к программе на любом языке, и кроссплатформенные приложения тоже легче делать. Работать он будет чуть медленнее, но для подавляющего большинства задач это не имеет значения.
Есть ли в мировом ИТ попытки перейти на такую парадигму взаимодействия между компонентами? Для этого достаточно важны средства виртуализации диска.
Я ещё боюсь немного оконфузиться насчёт Gaussian-а, т.к. он как раз состоит из множества link-ов, но я не знаю как работают эти линки и не хочу разбираться, я хочу просто запустить главную программу, чтобы она мне входной файл превратила в выходной.
Если такой интерфейс когда-нибудь станет доступен, я смогу попробовать реализовать, например, такие вещи, как:
- Сделать составной метол (FPD) очень удобным, с оптимизацией геометрии и частотами, и с эвристической оценкой точности полученного результата;
- Просчитать одну молекулу, точнее одну геометрию, десятком разных DFT-функционалов, прогнать результаты через нейросеть и получить очень точную энергию;
- Сделать свой ONIOM, в котором вместо двух слоёв есть три: слой A, который считается на дорогом методе, слой B, который считается на дешёвом, и слой AB, который считается на обоих.
Re: Взаимодействие между компонентами программы через текстовые файлы
Такой интерфейсинг и вызовы одних программ через другие достаточно популярен для малопопулярных кодов.
Скажем MRCC Каллая вызывается (вплетено в) CFOUR и MOLPRO.
Gromacs можно сплести с ORCA так чтобы она выполняла квантовую часть.
Для орки вообще много мелких кодов которые делают чтото свое на основе ее ДФТ.
Насчет гауссиана я не уверен насколько такие игры легальны.
Использование составных методов для оптимизации и частот мне кажется странным подходом, впрочем я могу ошибаться, четко сформулировать причину почему мне так кажется я не могу.
Скажем MRCC Каллая вызывается (вплетено в) CFOUR и MOLPRO.
Gromacs можно сплести с ORCA так чтобы она выполняла квантовую часть.
Для орки вообще много мелких кодов которые делают чтото свое на основе ее ДФТ.
Насчет гауссиана я не уверен насколько такие игры легальны.
Использование составных методов для оптимизации и частот мне кажется странным подходом, впрочем я могу ошибаться, четко сформулировать причину почему мне так кажется я не могу.
Re: Взаимодействие между компонентами программы через текстовые файлы
Если вы можете заранее построить DAG (ориентированный ациклический граф, англ. directed acyclic graph) для вашей задачи, то берету любую workflow engine из списка https://github.com/common-workflow-lang ... ow-systems и вперед.
Одна из самых первых и наиболее известных workflow engine это утилита make, все остальное работает по образу и подобию.
Что-то подобное делаю сейчас для CASINO используя snakemake https://github.com/Konjkov/snakerules
Например правило https://github.com/Konjkov/snakerules/b ... efile#L142
позволяет рассчитать пробные WFN для CASINO (gwfn.data) для всех комбинаций списков METHODS, BASES, MOLECULES
другие правила позволяют рассчитать далее VMC энергию, DMC энергию c требуемой точностью, экстраполировать на нулевой шаг в комплексном времени.
Но граф должен быть ациклическим это важно, нельзя неопределенное число шагов крутится в цикле, либо цикл должен быть полностью реализован как один шаг на графе.
Вот например как реализован цикл по списку алгоритмов оптимизации SCF
https://github.com/Konjkov/snakerules/b ... efile#L123
если по diis не сошлось берем gdm, если по gdm не сошлось - не судьба, но можно расширить список другими вариантами.
Одна из самых первых и наиболее известных workflow engine это утилита make, все остальное работает по образу и подобию.
Что-то подобное делаю сейчас для CASINO используя snakemake https://github.com/Konjkov/snakerules
Например правило https://github.com/Konjkov/snakerules/b ... efile#L142
позволяет рассчитать пробные WFN для CASINO (gwfn.data) для всех комбинаций списков METHODS, BASES, MOLECULES
другие правила позволяют рассчитать далее VMC энергию, DMC энергию c требуемой точностью, экстраполировать на нулевой шаг в комплексном времени.
Но граф должен быть ациклическим это важно, нельзя неопределенное число шагов крутится в цикле, либо цикл должен быть полностью реализован как один шаг на графе.
Вот например как реализован цикл по списку алгоритмов оптимизации SCF
https://github.com/Konjkov/snakerules/b ... efile#L123
если по diis не сошлось берем gdm, если по gdm не сошлось - не судьба, но можно расширить список другими вариантами.
If you are not part of the solution, you are part of the precipitate.
Re: Взаимодействие между компонентами программы через текстовые файлы
Т.е. вам это подсказывает ваша интуиция. А вы занимались расчётами с составными методами? Вот кажется Керк Петерсон, В. Соломоник как раз занимаются расчётами частот на FPD.Использование составных методов для оптимизации и частот мне кажется странным подходом, впрочем я могу ошибаться, четко сформулировать причину почему мне так кажется я не могу.
А если не FPD, а например CCSDT(Q)/CBS - что вы думаете про расчёт частот этим методом?
Re: Взаимодействие между компонентами программы через текстовые файлы
Доброе утро! Gau$$ian конечно многие не любят, но - его разработкой, т.е. написанием кода, занимались и занимаются вполне достойные люди, которые вполне себе понимают, что делают и знают тонкости того, над чем работают. Поэтому, я как-то сомневаюсь, что вот так с лету можно написать алгоритм оптимизации лучше, чем в Gaussian. То - что вы говорите по поводу оптимизации, если используются Декартовы координаты решается тривиально - Gau$$ian считает энергию + градиенты, они вместе с координатами выдираются быдло-скриптом и передаются библиотеке оптимизации (там до хрена алгоритмов оптимизации), хоть вот этой (https://nlopt.readthedocs.io/en/latest/) которая генерит новые координаты для расчета энергии и градиентов. Такое же можно сделать и для внутренних координат. Но - повторюсь, думаю, Вам не удастся вот так сразу "сделать" Gau$$ian. Я как-то думал над обратной задачей так как находил алгоритм оптимизации Гауссиана вполне достойным (и у них даже есть опция кормить градиенты и энергию из других программ). Короче - эта штука решается скриптом на Питоне (/dev/shm - это типа можно писать в память). Я - не кодер и не программист, но такие вещи, вызывание сторонних кодов и библиотек - скорее обычное дело. Мне прожженые математики и кодеры утверждали сколько раз, что написать лучше, чем в стандартных библиотеках (GSL, NLOpt, Numpy) вряд ли удастся даже им.
Метод Feller-Peterson-Dixon можно вообще заимплементить в скрипт, который отсабмитит несколько последовательных расчетов Gau$$ian or any other code.
"Просчитать одну молекулу, точнее одну геометрию, десятком разных DFT-функционалов, прогнать результаты через нейросеть и получить очень точную энергию" - а как Вы будете тренировать нейросеть? На каких данных? Толковых экспериментальных данных - мало, и все они для маленьких молекул. Теория, типа каплд - кластера, - тоже для маленьких. Даже если Вы натренируете нейросеть на воспроизведение энергетических характеристик маленьких молекул - почему Вы думаете, что все отработает также на больших?
"Сделать свой ONIOM, в котором вместо двух слоёв есть три: слой A, который считается на дорогом методе, слой B, который считается на дешёвом, и слой AB, который считается на обоих." - а это зачем? https://comp.chem.umn.edu/qmmm/ Вот мне кажется, Вам будет сложно обойти этого чела с его финансированием.
Вообще я очень уважаю людей, способных генерировать идеи самим, это очень похвально! Но - прежде чем что-то начать, надо все очень хорошо обдумать.
Метод Feller-Peterson-Dixon можно вообще заимплементить в скрипт, который отсабмитит несколько последовательных расчетов Gau$$ian or any other code.
"Просчитать одну молекулу, точнее одну геометрию, десятком разных DFT-функционалов, прогнать результаты через нейросеть и получить очень точную энергию" - а как Вы будете тренировать нейросеть? На каких данных? Толковых экспериментальных данных - мало, и все они для маленьких молекул. Теория, типа каплд - кластера, - тоже для маленьких. Даже если Вы натренируете нейросеть на воспроизведение энергетических характеристик маленьких молекул - почему Вы думаете, что все отработает также на больших?
"Сделать свой ONIOM, в котором вместо двух слоёв есть три: слой A, который считается на дорогом методе, слой B, который считается на дешёвом, и слой AB, который считается на обоих." - а это зачем? https://comp.chem.umn.edu/qmmm/ Вот мне кажется, Вам будет сложно обойти этого чела с его финансированием.
Вообще я очень уважаю людей, способных генерировать идеи самим, это очень похвально! Но - прежде чем что-то начать, надо все очень хорошо обдумать.
Кто смел тот и съел
Re: Взаимодействие между компонентами программы через текстовые файлы
Мне кажется, для этого надо просчитать на FPD большое количество разных двухатомных молекул, и тренировать нейросеть на этих данных."Просчитать одну молекулу, точнее одну геометрию, десятком разных DFT-функционалов, прогнать результаты через нейросеть и получить очень точную энергию" - а как Вы будете тренировать нейросеть? На каких данных? Толковых экспериментальных данных - мало, и все они для маленьких молекул. Теория, типа каплд - кластера, - тоже для маленьких. Даже если Вы натренируете нейросеть на воспроизведение энергетических характеристик маленьких молекул - почему Вы думаете, что все отработает также на больших?
Re: Взаимодействие между компонентами программы через текстовые файлы
я думаю достаточно много двухатомных молекул уже было посчитано на FDP, см 10.1063/1.4993625 и ссылки в нем, равно как и на T1 и W1
С другой стороны создание гиперпараметризованных (тысячи параметров) ДФТ функционалов на основе нейросетей тоже имеет сейчас место быть. Вопросов на самом деле много. Сколько надо данных, где качеством этих данных можно пожертвовать и на мой взгляд самое главное - будет ли полученный результат работать за пределами обучающей выборки двухатомных молекул. В частости я не удивлюсь если кольцевые токи/сопряжение/ароматичность а также связанные с ними пайпай стекинг/вандерваальсово взаимодействие и даже водородная связь не будут описываться функционалом натренированном на двухцентровом взаимодействии.
С другой стороны создание гиперпараметризованных (тысячи параметров) ДФТ функционалов на основе нейросетей тоже имеет сейчас место быть. Вопросов на самом деле много. Сколько надо данных, где качеством этих данных можно пожертвовать и на мой взгляд самое главное - будет ли полученный результат работать за пределами обучающей выборки двухатомных молекул. В частости я не удивлюсь если кольцевые токи/сопряжение/ароматичность а также связанные с ними пайпай стекинг/вандерваальсово взаимодействие и даже водородная связь не будут описываться функционалом натренированном на двухцентровом взаимодействии.
Re: Взаимодействие между компонентами программы через текстовые файлы
"на мой взгляд самое главное - будет ли полученный результат работать за пределами обучающей выборки двухатомных молекул" - согласен на 100%! Опять - потребуются достаточно большие выборки в молекуле, например под сотню-другую атомов. Там точность - никакая ни в теории ни в эксперименте. Дальше, возможно наивный вопрос. Даже если нейросеть будет предсказывать более-менее точную энергию системы, интересно, как будет насчет аналитических первых и вторых производных энергии для оптимизации молекулы/расчета частот? Это вообще, реально?
Кто смел тот и съел
Re: Взаимодействие между компонентами программы через текстовые файлы
мне кажется с градиентами и вторыми производными там треш будет
Кто смел тот и съел
Re: Взаимодействие между компонентами программы через текстовые файлы
Вы хотите чтобы из Chemcraft'а можно было запускать Gaussian?
Что-то похоже на Gaussview и WebMo?
Мне тоже кажется, что самое удобно это Python.
Не совсем понял насчет виртуального диска. Все эти пакеты вызываются из коммандной строки, может
это какая-то особенность программирования под Windows?
Есть ещё один пример интеграции квант. хим. пакетов в другие программы.
Это SAPT2016, он использует по выбору Dalton, Molpro, Orca, Gamess и Gaussian.
Еще один пример, CamCASP, но он использует только Dalton.
Во всех этих случаях требуется наличие исходников упомянутых пакетов для перекомпиляции, кроме Орки.
Что-то похоже на Gaussview и WebMo?
Мне тоже кажется, что самое удобно это Python.
Не совсем понял насчет виртуального диска. Все эти пакеты вызываются из коммандной строки, может
это какая-то особенность программирования под Windows?
Есть ещё один пример интеграции квант. хим. пакетов в другие программы.
Это SAPT2016, он использует по выбору Dalton, Molpro, Orca, Gamess и Gaussian.
Еще один пример, CamCASP, но он использует только Dalton.
Во всех этих случаях требуется наличие исходников упомянутых пакетов для перекомпиляции, кроме Орки.
Re: Взаимодействие между компонентами программы через текстовые файлы
Вроде бы, только из gif-ов. Я им пользовался, чтобы анимировать картинки, которые делает molden. А он делает гифы, поэтому проблема других форматов не стояла. Но конвертировать графические форматы из командной строки или в скрипте - есть ImageMagick. Кстати, представляя себе идеологию ImageMagick (делать все что угодно их всего что угодно), думаю, что он тоже может делать анимированные гифы, причем из bmp/jpeg в том числе. Но он, зараза, тяжелый, жрущий память и медленный. Еще mplayer (mencoder) можно глянуть, он тоже всеядный, и интерполированную авишку, например, может сделать.
Re: Взаимодействие между компонентами программы через текстовые файлы
Я изучаю понемногу что за зверь эти нейросети, и ответить однозначно не могу.Даже если нейросеть будет предсказывать более-менее точную энергию системы, интересно, как будет насчет аналитических первых и вторых производных энергии для оптимизации молекулы/расчета частот? Это вообще, реально?
Вообще, я тут подумал, что озвученная идея - просчитать энергию на нескольких функционалах и обработать результаты через нейросеть - вряд ли более перспективна, чем другая идея, которую я написал в теме про Chemcraft - просто взять набор расчётов в каком-то выбранном каталоге и повторить эти расчёты с немного другими ключевыми словами в новых каталогах. Т.е. вы просчитали, например, ряд молекул на B3LYP/6-31G(D,P), и с помощью этой утилиты получили несколько каталогов с большим набором входных файлов, предполагающих расчёт тех же систем на PBE, PBE0, wB97XD и т.д. Одновременно Chemcraft создаст большой batch-файла для Gaussian, где все эти файлы перечислены.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 228 гостей