Project

General

Profile

Bug #1940

QMMM not functional -> manual misleading

Added by Grzegorz Wieczorek over 3 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
core library
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

In git master EVERY attempt to do some electronic embedding qmmm fails (checked for orca and gaussian). Example with orca (gaussian version segfaults at the same place), CMAKE_BUILD_TYPE Debug:
% gmx mdrun ntmpi 1 -ntomp 1 -s pyp.tpr <== look at #1934 for input, but it can be any other...
:
) GROMACS - gmx mdrun, 2016-dev-20160404-ff11a85-dirty (-:
(...)
QM/MM calculation requested.
Layer 0
nr of QM atoms 22
QMlevel: RHF/3-21G

Setting ORCA path to: /home/soft/orca_3_0_3_linux_x86-64...
ORCA initialised...

starting mdrun 'PHOTOACTIVE YELLOW PROTEIN in water'
500 steps, 0.5 ps.
Segmentation fault (core dumped)
% gdb /home/gigo/gromacs_debug/gromacs_orca/bin/gmx core
GNU gdb (Debian 7.10-1+b1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
(...)
Reading symbols from /home/gigo/gromacs_debug/gromacs_orca/bin/gmx...done.
[New LWP 26376]
[New LWP 26397]
[New LWP 26398]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/home/gigo/gromacs_debug/gromacs_orca/bin/gmx mdrun -ntmpi 1 -ntomp 1 -s pyp.tp'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f167640892a in update_QMMMrec (cr=0x25b7740, fr=0x25f56d0, x=0x286d7f0, md=0x2ca2180, box=0x37d57f0, top=0x37d1830) at /home/gigo/gromacs_orca_test/src/gromacs/mdlib/qmmm.cpp:840
840 snew(qm_i_particles, QMMMlist->nri);
(gdb) p QMMMlist->nri
Cannot access memory at address 0x18
(gdb) p QMMMlist
$1 = (t_nblist *) 0x0
(gdb) quit

Similarly to #1934, the neighbor list needed for giving the QM program information about the classic part environment is never created. In 5.1.2 it is possible to do some QMMM, but the only link between QM and MM parts are link atoms (they don't work in the gaussian case - gromacs-5.1.2 writes 0 as atomic number. Its easy to solve, but alike patch for #1934 its only polishing a car with broken engine) Therefore, the part of the manual (5.1.*, and probably older as well as devel versions) concerning QMMM (I admit that I didn't take a look at ONIOM) ... should be removed, and included again, when the programming is done. The manual encouraged me to do QMMM in gromacs - it doesn't say that the user should grab some ancient version supplied by Gerrit Groenhof.
Now, can anybody explain, in short, what are the programming tasks to be done to make QMMM work, maybe explain the neighbor lists building for this case, point me to some publications, say what are possible pitfalls and other stuff that one who wants to get involved in it should know, what git branch to send the code for reviews to?
Best Regards,

Grzegorz

Associated revisions

Revision 0115a9ec (diff)
Added by Berk Hess over 3 years ago

Add QMMM checks

QMMM only works with cutoff-scheme=group and dynamics. grompp and
mdrun now check for this.
Also fixed potential print of NULL string in init_gaussian.

Fixes #1940.

Change-Id: I8215e339070d811ba07d17d743061b18b665a33b

History

#1 Updated by Grzegorz Wieczorek over 3 years ago

Hi,

As of version 5 on, the old QM/MM interface is no longer supported. Although there are plans for a new API, i recommend that you switch to version < 5.

If I am not mistaking, QM/MM relies on a group based nb search.

For most, if not all normal purposes it is working fine, as we are using that interface on daily basis.

I agree however, that we should update the manual, and will do that when I find the time.

Gerrit

#2 Updated by Gerrit Groenhof over 3 years ago

Hi,

As of version 5 on, the old QM/MM interface is no longer supported. Although there are plans for a new API, i recommend that you switch to version < 5.

If I am not mistaking, QM/MM relies on a group based nb search.

For most, if not all normal purposes it is working fine, as we are using that interface on daily basis.

I agree however, that we should update the manual, and will do that when I find the time.

Gerrit

#3 Updated by Mark Abraham over 3 years ago

I agree that there's significant problems here - one has no chance of using the old interface in GROMACS 5.1 without specifying the group scheme.

However, at the very least we need some regression-test input cases from interested users or there won't be anything related to QM/MM in GROMACS 2017. :-)

In the meantime, we should add some basic checks in mdrun and warning text in the manual.

#4 Updated by Grzegorz Wieczorek over 3 years ago

I will look for some published QMMM examples and try to reproduce results with Gromacs-4.6.7, lets say. It will be a basis for creating regression tests for other versions. If you have any suggestions of such publications, I will be very obliged for suggestions. One of the first problems that came to my mind was preparing g09 (to which I can have access ... possibly) - it differs a lot from the gaussian version described in http://wwwuser.gwdg.de/~ggroenh/roadmap.pdf ...
But first things first - initially I will try to find something that can be repeated with orca.
Does it even make sense? :)
Could you tell me, please, if it is reasonable to upload any changes to existing qmmm code into gerrit git at this stage (heh... it was a nice exercise for me)? If significant part of it is going to be changed, maybe ... its just a spam :)
Best,
Grzegorz

#5 Updated by Berk Hess over 3 years ago

Note that 5.1 should (might) work when you use cutoff-scheme = group
If the changes you upload qualify as fixes (and not new functionality), they could be included in GROMACS 2016, which could be useful for many users for quite some time.
It could also be useful as a basis for the new interface, but I don't have a good overview of the qmmm code.

#6 Updated by Gerrit Groenhof over 3 years ago

Hi Grzegorz,

Instead of adapting the gaussian source code with the roadmap, you will also find a script on the website: http://wwwuser.gwdg.de/~ggroenh/qmmm.html#gaussian

that allows one to run QM/MM with any version of gaussian, or after some adaptation any QM program.

For literature examples, our QM/MM papers were all performed with gromacs, but I should be making some regression test cases available myself. Nevertheless, I can share with you the inputs for all projects we've published so far

#7 Updated by Grzegorz Wieczorek over 3 years ago

Mark, Berk, Gerrit,
Thank you for all the info. I will let you know what is the progress.
Indeed, Gromacs-5.1.2 seems to work with cutoff-scheme = group (and orca for now) - I mean that it is able to run and produce some results, so I can compare them to something that was published. Thus - the main long term task, as I understand it, is adaptation of the QMMM to the Verlet scheme. Is this correct?
Gerrit, thank you very much for you offer - I would gladly rerun your inputs on Gromacs-4.6.7 (if necessary) and 5.1.2. I'm looking at the papers now.
Best Regards,

g

#8 Updated by Gerrit Code Review Bot over 3 years ago

Gerrit received a related patchset '1' for Issue #1940.
Uploader: Berk Hess ()
Change-Id: I8215e339070d811ba07d17d743061b18b665a33b
Gerrit URL: https://gerrit.gromacs.org/5806

#9 Updated by Berk Hess over 3 years ago

  • Tracker changed from Task to Bug
  • Category set to core library
  • Status changed from New to Fix uploaded
  • Target version set to 5.1.3
  • Affected version set to 5.1.2

I uploaded a fix that adds a check.
We should support QMMM with cutoff-scheme=verlet, that's not hard, since we already have functionality that extracts all pairs involving free-energy calculations into a separate, simple atom-pair list.

#10 Updated by Berk Hess over 3 years ago

  • Status changed from Fix uploaded to Resolved

#11 Updated by Erik Lindahl over 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF