QMMM with ORCA: memory leaks, buffer overflows and much more
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)
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 pyp.top -n pyp.ndx -c pyp.gro -o pyp.tpr
#gmx_d compiled with orca, pyp.ndx, .gro and .top taken from http://wwwuser.gwdg.de/~ggroenh/qmmm.html#ex, pyp.mdp taken from thereof, modified, attached
gmx_d mdrun -ntmpi 1 -ntomp 1 -s pyp.tpr
Using 1 MPI thread
Using 1 OpenMP thread
QM/MM calculation requested.
nr of QM atoms 22
Setting ORCA path to: /home/soft/orca_3_0_3_linux_x86-64...
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!
#1 Updated by Grzegorz Wieczorek about 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.
#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.