QM/MM with PWScf

Hi,

i hope these kind of questions are also welcome here:

Can anyone tell me, what is the state of QM/MM-coupling of Lammps to PWSCF?

Is there some active development on the USER-QMMM package?

I noticed that the recent QE release 5.4 ‘broke’ (as in, reordered and redistributed the used functions) the interface that this package uses.

Does anyone have experience with http://qeforge.qe-forge.org/gf/project/qmmmw?

This seems more complete, feature-wise, but is an external project and only guaranteed to work with specific versions of both software packages. Additionally, development there seems stalled, too.

Thank you,

Sebastian

Hi,

i hope these kind of questions are also welcome here:

yup. for as long as you can handle a long story/email... :wink:

Can anyone tell me, what is the state of QM/MM-coupling of Lammps to PWSCF?

it is currently broken, due to recent changes in QE, which broke the
API of the QE library interface for no good reason. i have since sent
patches to paolo gianozzi that have been included into the development
source repo, that restore the API and allow to compile the code again,
but there seem to be other changes in QE 5.4 that break using the
mechanical coupling. i have not had time to do further investigations,
let along restore the available minimal functionality.

Is there some active development on the USER-QMMM package?

there is the desire, but the problem is lack of qualified and
motivated people. that has been plaguing QM/MM interfaces since day
one. to program these, you have to be very good at programming, in
this case in three different programming languages at the same time,
have a very good understanding of parallel programming, have good
knowledge in developing classical MD codes and quantum mechanical
codes, and have a good understanding of the coupling, which has many
challenges in itself. because of that, most QM/MM coupling are not in
a good shape, as they either haphazardly graft a classical MD code
onto a QM code (CPMD's QM/MM coupling to Gromos is an example), or
wedge QM calculations into a classical MD package (Amber-Mopac would
be an example). add to that, that QM/MM isn't the hot topic anymore
that it was a decade ago, and you have a mess. there also seems to be
the trend that people, who have spent significant time working on
developing/improving/maintaining a QM/MM interface, tend to grow less
enthusiastic over time. i fall into that category.

add this all up and you get a situation, where the people most
interested in using a feature are often the least qualified and the
ones that are the most qualified are the least interested. that said,
the quantum espresso community does have a significant interest to
complete the implementation.

I noticed that the recent QE release 5.4 'broke' (as in, reordered and
redistributed the used functions) the interface that this package uses.
Does anyone have experience with
http://qeforge.qe-forge.org/gf/project/qmmmw?

yes. that is what was used as inspiration for the current
implementation. i started that about 2 1/2 years as a favor to "un
veccio amico" in trieste using code from this project. however, it
turned out to be better doing a complete rewrite and in the process
carlo cavazzoni, paolo gianozzi and i ended up doing a massive
refactoring and cleanup of the communication layer in quantum
espresso, which then allowed to write the QE library interface, and
that in turn was the basis for the QM/MM library in LAMMPS. after
doing a proof of concept implementation of a simple mechanical QM/MM
coupling, somebody from the QE developer community was supposed to
take over and validate my code and then complete the implementation by
adding the electrostatic coupling, same as qmmmw.

since then rather little has happened until earlier this year, where i
was contacted by QE developers asking me for a couple more favors to
help completing and reviewing what was done since. so far, i've been
too busy and we're still lacking a suitable developer for the QE side
of things that cares enough and is a good enough programmer.

This seems more complete, feature-wise, but is an external project and only
guaranteed to work with specific versions of both software packages.
Additionally, development there seems stalled, too.

yes, it is "mostly dead" and nobody has yet made the trip to "miracle
max" to bring it back to life. :wink:
it may be easier to get it to work, yet, it also requires programming
to make it work with the current version of QE and decent knowledge of
QE internals or an excellent ability to read code.

axel.

Hi Axel,

Hi Axel,

[...]

I was hoping there were some unmerged updates, but i guess with Lammps
one really gets the complete and up-to-date package :slight_smile:
Let's hope that someone reads this who fits both requirements!
(Or i magically become qualified enough...)

unlikely.

yes. that is what was used as inspiration for the current
implementation. [...] it may be easier to get it to work, yet, it also
requires programming
to make it work with the current version of QE and decent knowledge of
QE internals or an excellent ability to read code.

Ah, i figured it to be the newer implementation.
While it may be more practical, from your description it sounds like qmmmw
falls more in
the 'haphazardly-grafting' category of implementations? Or at least not
ideal.
So, strictly hypothecially speaking of course ;-), where would one start to
help out?

how much do you know about:
- classical MD and writing classical MD codes?
- plane wave DFT calculations?
- QM/MM methodology in general?
- C++ and Fortran 2003/8 programming?
- advanced parallel programming with MPI (e.g. working with split communicators)

ultimately, the question is: what is your interest in this?
are you looking for a challenging project to to scientific software
development on, or do you have a specific research need which requires
using QM/MM coupling? and if the latter, what specifically? are you
bound to using QE? or determined to use LAMMPS?

Is there a big conceptual difference between the two projects, or could the
electrostatic part
be 'adopted'?

the major conceptual differences are in the mechanics of how the QM/MM
calculations are run. in qmmmw, you start 2 copies of (a modified)
LAMMPS and 1 copy of pw.x; the first 2 in serial (and with sorting
turned off) on the same node as rank zero of pw.x, which can be run in
parallel. communication between the different executables is done via
a (modular) library, which can use system v shared memory or files to
communicate information between the different processes. the USER-QMMM
package is designed to be linked into one combined executable and then
use MPI exclusively for communication. the three different roles of
that executable are still followed, but this is all established via
partitioning the global MPI communicator. USER-QMMM, if ever
completed, will support running the classical MD part in parallel.

the physics of the QM/MM coupling is planned to be the same and
actually not very sophisticated in either case. for instance, there is
no support for having bonds between the QM and the MM regions (which
is a serious challenge to QM/MM coupling and a topic of continued
research). the coupling is conceptually similar to the first
incarnation of the CPMD/Gromos QM/MM coupling developed in the
Roethlisberger group at EPFL in the early 2000s.

Is the interface on the Lammps side stable, or is there even anything
needed?

there is work needed everywhere. neither of the two implementations of
QM/MM coupling were complete and only the qmmmw package ever became
usable for the specific needs of the developers; the one in LAMMPS
never even matured to that point.

With it's modular design, i guess that it's almost completely contained in
the qmmm-package?

and the library, yes. most of the heavy lifting is done on the quantum
espresso side, anyway.

axel.

ultimately, the question is: what is your interest in this?
are you looking for a challenging project to to scientific software
development on, or do you have a specific research need which requires
using QM/MM coupling? and if the latter, what specifically? are you
bound to using QE? or determined to use LAMMPS?

[...]

there is work needed everywhere. neither of the two implementations of
QM/MM coupling were complete and only the qmmmw package ever became
usable for the specific needs of the developers; the one in LAMMPS
never even matured to that point.

My interest was mainly in getting to know what's the current status,
this you answered extraordinarily, for which i am really grateful! :slight_smile:
My current project is not depending on QM/MM, but would surely benefit from
it.
I was recommended NWChem, maybe it can fill this gap.
Maybe in the long run i can contribute to this, but i'd rather not make any
promises/threats. :wink:
I will surely have a closer look on it.

Sebastian

ultimately, the question is: what is your interest in this?
are you looking for a challenging project to to scientific software
development on, or do you have a specific research need which requires
using QM/MM coupling? and if the latter, what specifically? are you
bound to using QE? or determined to use LAMMPS?

[...]

there is work needed everywhere. neither of the two implementations of
QM/MM coupling were complete and only the qmmmw package ever became
usable for the specific needs of the developers; the one in LAMMPS
never even matured to that point.

My interest was mainly in getting to know what's the current status,
this you answered extraordinarily, for which i am really grateful! :slight_smile:
My current project is not depending on QM/MM, but would surely benefit from
it.
I was recommended NWChem, maybe it can fill this gap.

another recommendation would be CP2k. both have the advantage to be
"fully integrated", i.e. have QM and MM features in the same code
base.

axel.