From: Mayne, Christopher G (
Date: Thu Mar 28 2013 - 20:52:28 CDT


Glad that the latest alpha version of VMD is clearing up most of the errors. A quick search of my inbox reveals that the ModRedundant line involving O****R is in fact the same error as I have come across before, but again, I was unable to work with the original reporter to solve it.

With respect to your further comments / questions.

1. Our top priority is to maintain consistency with CGenFF force field, and by extension, CHARMM. While one is tempted to explore higher levels of theory and advancements such as CP corrections, they are not yet proven to play nice with the highly tuned and *empirical* force field. Modifications, extensions, and improvements to force fields require much in the way of vetting; so we're sticking with the prescribed methods until the literature suggests it is safe to adopt new methods.

We believe, however, that one of the key features of ffTK is that it provides those familiar with FF development various tools to investigate the effects of modifications, such as CP corrections, on parameters and FF performance. This does, in many cases, require that you're not afraid to get your hands a little dirty and modify some of the code to parse what you want--which we're happy to hear you're not afraid to do! Where feasible, we may even be able to help.

2. In line with my statements above, we compute interaction energies at the HF/6-31G* level of theory to maintain consistency for non-bonded terms with CHARMM. However, we found that computing the dipole moment at MP2/6-31G* (within the molecule) is an especially effective metric for assessing overall charge distribution that aids the optimizer in arriving at physically relevant charges. I hesitate to do so, but I will mention that if you simply specific the HF log file in the MP2 box, it will parse without error, but please note that your dipole term will be less accurate, and we've found that in some cases this really does make a difference.

3. This is a NAMD issue that I'll have to take up with them. If you could be a little more descriptive about what step in ffTK, specifically, is resulting in error, and send us the files that reproduce the error I'll look into it.

We love feedback, so thanks for taking the time to make thoughtful comments and suggestions.

Christopher Mayne

On Mar 28, 2013, at 7:23 PM, Paweł Kędzierski wrote:

W dniu 28.03.2013 17:13, Mayne, Christopher G pisze:


Thanks for the patch! I had already applied a similar modification to the regex in our CVS some time ago, after other users had reported this error on VMD-L. This means that the fix should appear in the latest alpha builds of VMD 1.9.2 available through BioCoRE. However, if you send us the originally offending file, we can test against the latest version to ensure that the currently implemented patch functions as intended.

I had sent that file to<> as suggested by John Stone; however, as it was calculated by the troublesome version 09RevC.01 of Gaussian, I made these files for all steps from the initial optimization up to the hessian for optimization of bonded parameters. You can download them from
I have just downloaded vmd1.9.2a20 from BioCore and I see quite a few differences in relevant plugins compared to what I used with vmd1.9.1. Suddenly, errors disappeared. Good. Apparently, all these logs from C.01 are parsed without problems now.
There is only one minor glitch - gaussian does not like the ModRedundant line "O * * * * R" saved by fftk in the hessian input file.

With regard to the hessian, another user has reported problems with ffTK reading gaussian log files for the hessian calculation when using G09RevC.01. I was never able to track down the error as the user stopped replying and I don't have access to G09RevC.01 to test/track it myself. If you have access to G09RevB.01, the resulting log file should play nice with ffTK. To the best of my knowledge (I use ffTK almost daily), the latest VMD 1.9.2.alpha in combination with G09RevB.01 functions properly from start to finish.

Thanks, fortunately I have access to G09RevB.01.
Now I came up with more questions and comments.

  1. "QM Target Data" at "Opt. Charges" tab used to require two log files with single point energies for the compound and water (now three with MP2).
It would be useful though to have an input field to directly provide the number for the energy instead of the file. First, because it would save two gaussian calculations (and possible problems with file parsing :-). The energy of the compound is already in the gaussian log file from optimization (both HF and MP2), and the HF/6-31G* energy of TIP3 water is always the same.
Second, and the more important comment is that this implies that the interaction energies are calculated with basis set superposition error. This approach may agree with general CHARMM methodology but it would be interesting to check how it works with counterpoise corrected energies. Simple text fields for the energies of separate molecules would allow for such tests without the hassle of parsing gaussian log files from counterpoise calculations. It might e.g. turn out, that the scaling factor from gas to condensed phase would be more consistent with CP corrected interaction energies.
  2. In the new fftk version (from VMD 1.9.2a20) there are two entries for "Cmpd LOG" for optimization of charges: HF and MP2. What is the reason of providing MP2 energies for the compound only and not for water? Without this file, it doesn't run at all now - shouldn't it be optional?
  3. Apparently optimization for such simple molecule as H2S triggers a bug in namd2.8 which I had in path - the gradients are "nan" and namd allocates more and more memory until it gets killed (with vmd and fftk). I had a copy of ancient namd2.5 and this one worked. This is observed at optimization of bond and angle parameters.


Christopher Mayne

On Mar 28, 2013, at 9:34 AM, John Stone wrote:

 Can you also send us the Gaussian log file that goes with the patch?
It is helpful for us to have a collection of log files that previously
encountered trouble with parsers, so we can re-test them when changes
are made to the code. No need to send it to VMD-L, just email a gzipped
log file to<>, or if it is too large, then post it somewhere
and send us a URL. Thanks!

 John Stone<>

On Thu, Mar 28, 2013 at 03:25:50PM +0100, Pawe?? K??dzierski wrote:

Dear Christopher,
Thank you for prompt answer.

W dniu 28.03.2013 14:03, Mayne, Christopher G pisze:

Updates of geometry (PDB file) and charge (PSF file) are done directly in
their respective tabs. The "Update Parameter File with Optimized
Parameters" is only used when updating bonds, angles, and dihedrals, after
optimization. Note that the "Optimization LOG File" required there is the
log file written by ffTK, which contains a portion at the end denoted by
"FINAL PARAMETERS" tag, NOT a Gaussian log file.

Ooops, I missed this detail, sorry.
In the mean time I have progressed a bit but now I am getting errors
parsing Gaussian log files from QMtool.
I know that Gaussian people are often playing tricks with their log
files as I have my own script parsers which break from one version to
another. And I already found one such bug (patch attached) but now I
have problems with hessian parser which seem more involved.
Could you advice which version of Gaussian is recommended/best tested
with FFTK and the plugins it depends on? I have some choice at our
computing center and I would like first make myself familiar with fftk
rather than chasing parsing bugs without good understanding of tcl.

I strongly suggest viewing the screencasts available on the documentation

I did. I just need to get thorough the tricky details. BTW, you did an
excellent piece of work.

Christopher Mayne

On Mar 28, 2013, at 6:26 AM, Pawe?? K??dzierski wrote:

Dear all,
I have just started playing with FFTK, and want to make sure that I get
it correctly.
As a simple test case I started with H2S molecule and got successfully
through most of BuildPar tab; that is, I have assigned LJ parameters and
saved optimized geometry as PDB. I checked that the numbers and coords
are correct in par and pdb files.
So far, it means that basic parsing of gausian log file works.
Now I got to the "Update Parameter File with Optimized Parameters" part.
When I load the "Optimization LOG File:" and then click the "Write
Updated Parameter File" button, the par file is updated (checked by
modification time" but the equlibrium parameters (b0 and Theta0) are
saved as zeros.
Is this expected behaviour? Or may it be that the plugin is incompatible
with gaussian 2003 (g03) which I use?
Thank you in advance,

NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801 Phone: 217-244-3349