Bug #1934

QMMM with ORCA: memory leaks, buffer overflows and much more

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

Target version:
Affected version - extra info:
Affected version:


Dear GMXers!
The most important part regards the "much more" from the title. To warm up lets see the memory issues first.
qm_orca.c is abundant in memory leaks - allocations (some of them completely unnecessary) not followed by freeing the memory. It happens during initialization of QM software and every time QMMM is called. It is coupled with really bad environment variables handling that can lead to crashes and execution of arbitrary code, which can be dangerous if gmx is setuid/setgid (why should it be??). Few commented excerpts from qm_orca.c:

63: char buf;
64: snew(buf, 200); // OK, we got some memory
66: /
ORCA settings on the system */
67: buf = getenv("GMX_QM_ORCA_BASENAME"); // heh... the previous mem referenced by buf got leaked
68: if (buf)
69: {
70: snew(qm->orca_basename, 200);
71: sscanf(buf, "%s", qm->orca_basename); // buf points to the value of the env variable. It can be longer than 200 though...

Lets try the script1:
setenv GMX_QM_ORCA_BASENAME `seq -s "" 1000`
setenv setenv GMX_ORCA_PATH /home/soft/orca_3_0_3_linux_x86-64

gmx_d grompp -f pyp.mdp -p -n pyp.ndx -c pyp.gro -o pyp.tpr
#gmx_d compiled with orca, pyp.ndx, .gro and .top taken from, pyp.mdp taken from thereof, modified, attached

gmx_d mdrun -ntmpi 1 -ntomp 1 -s pyp.tpr

Lets run:
% ./script1
Using 1 MPI thread
Using 1 OpenMP thread

QM/MM calculation requested.
Layer 0
nr of QM atoms 22
QMlevel: DFT/3-21G

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

Segmentation fault (core dumped)

If GMX_QM_ORCA_BASENAME is set to something reasonable, it runs flawlessly, IF you remove %LJCoefficients and %pointcharges directives from the attached example.ORCAINFO.
Here comes the "much more". If requested by bOpt = true option in the .mdp, gmx does not create .pc nor .LJ files. 5 minutes of debugging shows that it happens, because in qm_orca.c, write_orca_input:

183: if (QMMMrec->QMMMscheme != eQMMMschemeoniom && mm->nrMMatoms)

mm->nrMMatoms is 0. Going back along the execution path, init_QMMMrec in qmmm.c:

732: mm->nrMMatoms = (mtop->natoms)-(qr->qm0->nrQMatoms); /* rest of the atoms */

which for this system yields with 15806 - thats OK. However, before even calling the qmmm calculation, in update_QMMMrec, qmmm.c, for serial execution:

791:  (...) mm_nr = 0 (...)
851: if (QMMMlist.nri) // QMMMlist.nri is zero, so
889: mm_nr++; // we don't get here, so ...

1012: mm->nrMMatoms = mm_nr; // number of MM atoms gets zeroed

My question is:
If you have some suggestions how to fix this, please let me know - as I really want it to work, I will gladly contribute. From the comments in the source I got that there is some work to be done in neighbor searching, but I don't know the details (yet). Discussion on gmx-users and gmx-developers on qmmm are very rare and not giving me too much of enlightment. Any input/guidance on this would be very welcome!
Best Regards,

Grzegorz Wieczorek

pyp.mdp (1.32 KB) pyp.mdp Grzegorz Wieczorek, 03/31/2016 04:41 PM
example.ORCAINFO (249 Bytes) example.ORCAINFO Grzegorz Wieczorek, 03/31/2016 05:01 PM
qm_orca.c (13.5 KB) qm_orca.c Grzegorz Wieczorek, 04/01/2016 03:21 AM
qm_orca.c (13.5 KB) qm_orca.c Grzegorz Wieczorek, 04/01/2016 03:42 AM
qm_orca.c (13.9 KB) qm_orca.c Grzegorz Wieczorek, 04/01/2016 08:55 PM

Related issues

Related to GROMACS - Task #2706: Rework classic QM/MM interfaceAccepted


#1 Updated by Grzegorz Wieczorek almost 4 years ago

OK, in the meantime I fixed the leaks, the possibilities of overflow, reduced the number of unnecessary variables, simplified the way ORCA outputs are read and few other things. The patch is longer than the file itself, so I upload the file. I am sorry - I changed the indentation a bit - to more "conventional" - I wanted to see more code on the screen at a time. I checked, it seems to work not worse than the older version.


#2 Updated by Grzegorz Wieczorek almost 4 years ago

Ehh, this is the latest.

#3 Updated by Grzegorz Wieczorek almost 4 years ago

I've just read about your preferred code formatting and indentation standards, so I applied the new knowledge to the qm_orca.c (making it hardly readable again ;)). Here it is.

#4 Updated by Gerrit Code Review Bot almost 4 years ago

Gerrit received a related patchset '1' for Issue #1934.
Uploader: Grzegorz Wieczorek ()
Change-Id: I999b7112b46b563d2b25fbaab8da4bcefb7d6d0f
Gerrit URL:

#5 Updated by Gerrit Groenhof almost 4 years ago


For ORCA related issues, please contact Christoph Riplinger, who wrote the interface and is also a ORCA developer.


#6 Updated by Erik Lindahl over 3 years ago

Unfortunately seems to be very little interest from the QM/MM developers in actually looking into this.

Gerrit: While I understand you might not have written the interface, we simply don't have the resources to start maintaining the files for the QM/MM developers and coordinate contacts with the people who might have originally written it.

Unless somebody addresses it, the simple solution for us is unfortunately that we'll have to deprecate it and remove some QM/MM stuff from future releases.

#7 Updated by Gerrit Groenhof over 3 years ago

Agreed Erik. Because we're not using the ORCA interface ourselves, there is indeed little priority to maintain from our side. Since all QM/MM can be done with a gaussian script, I can maintain that until we have a general API for doing QM/MM.

#8 Updated by Mark Abraham over 1 year ago

  • Related to Task #2706: Rework classic QM/MM interface added

Also available in: Atom PDF