I’ve seen this page about mentioning Gromacs 3.3 and onwards supporting QMMM packages like Gausssian, Gamess, Mopac7. www.gromacs [.] org/Documentation_of_outdated_versions/Installation_Instructions_4.5/compiling_QMMM
But in order to configure gromacs with qmmm programs
i need a configure file to supply with “–with-qmmm-”
In newer releases gromacs lack of this file and goes along with only cmake options. I’m in possesion of Mopac2012 Source code and i saw this paper “https://russianscdays.org/files/pdf18/345.pdf” which they used gromacs with mopac2012 but they didnt specify any of the details about “which version of gromacs” or “which commands they have used to install”.
The general old-style QM/MM has been poorly tested over the years and is mainly de-funct especially with the removal of the “group-scheme” - that’s why it is removed from the new GROMACS 2021 release in it’s old form and to be superseeded by some development efforts by Dmitry Mozorov and Gerrit Groenhof to integrate GROMACS with CP2K and then possibly hooking it up to other packages. I suggest you directly contact Dmitry Morozov at the University of Jyväskylä if you want to know the current state of the newest generation of QM/MM integration in GROMACS.
As you figured correctly, GROMACS can also work with CPMD, there CPMD is the driving software, also performing the time-step integration, and only inquiring forces from GROMACS, in a sense a different type of setup.
I have one foolish question regarding QMMM-part in GROMACS. I am new to GROMACS and did rather QM previously. May be my question has been already answered as well. I have noticed this change with the group-scheme in recent GROMACS version. However, I want to ask, how hard is it to reimplement of other QMMM interface (for example with ORCA) into new GROMACS? Is group-scheme really needed in QMMM calculation? If I see the previous code in GROMACS2018, it seems that the source codes for the qmmm is not that complicated as I feared. Additionally, the coding style is completely different. In 2022-version the qmmm.cpp looks more “object oriented” than in the previous one. No doubt a lot of elaborate work has been done by Morozov, and I am very grateful for that.
If you really want to use ORCA and not CP2K, I would strongly suggest that you still start out witht the interface that Dmitry Mozorov and I put in place.
It might look a bit frightening with the object orientation, but the idea is to make it simpler, not more complex. Almost all code you need is in src/gromacs/applied_forces/qmmm
If you want to build your own integration, tweaking the code in there might be the easiest start. QMMMForceProvider::calculateForces is at the core of everything there.
My main concern (and admittedly the hardest part of writing the QM/MM integration) would be how you would like to interact with ORCA
communicate via file writing / reading is the easiest, but very slow
communicate via linking the necessary library functions is more challenging, we did it for CP2K, but requires compiling one against the other and some cmake.
If you choose the first option, you can almost take the code in QMMMForceProvider::calculateForces as it is, have gromacs make a system call to ORCA, wait for it to finish, then read back a file from ORCA. This might be terribly slow, but then again it’s QM/MM.
A slightly unlikely alternative is contacting the ORCA developers (I have no contact at all with them) and ask them if they are inclined to write a GROMACS patch that allows to run QM/MM with ORCA and GROMACS, but that might be a long shot and not be done before two years…
thanks for your fast reply. Indeed I have also contacted Dmitry regarding this. He also nicely replied me and told me about the reason why CP2K is the chosen one. I don’t think the code is frightening at all as I am familiar with object oriented concept (however rather with Java). In fact I like your coding style, because the previous one did not really follow object oriented sense as I know from Java. C++ is indeed a bit special and just a little bit confusing with the pointers concept.
Correct me if I am wrong. I believe, that the first option was the way GROMACS2018 performs the QM/MM calculation. So the QM-software is called by GROMACS and writes the force, coordinates and maybe charges in a text file and this text file will be read by GROMACS again.
The second option is logically much faster. If I understand you correctly, libcp2k is the part, which is doing the FORCE_ENERGY calculation and directly returns the value as an object back to GROMACS.
However, as you mentioned, I doubt that ORCA-developers will ever give their source code. Additionally, they probably do not have particular interest in this direction. So developing a static library for ORCA might be not possible. Other options are using TURBOMOLE, since they may give the source code, if they agree to the project proposal. Though unfortunately TURBOMOLE is not free and only available for small fee for academic purposes.
There is another concern in my mind currently. Dmitry told me that the Verlet cutoff-scheme in recent GROMACS only allows PBC calculation. Is this correct? QC-software, however, usually does not have this capability. In any case, as far I can remember Christoph Haettig of TURBOMOLE mentioned that TURBOMOLE7.0 has already DFT with PBC. The forces will be implemented also later. I did not follow it currently, but I might search something.
Another question: like I said, I am not really familiar with developing C++ project. I was more a Webapps developer, and this is my first try. If I pursue the first option as a temporary solution, I do still need to recompile the whole GROMACS every time I changed the code. Would that mean, that this is really time consuming?