VMD-L Mailing List

From: Mayne, Christopher G (cmayne2_at_illinois.edu)
Date: Thu May 30 2013 - 13:56:35 CDT

I missed a section of a previous email that I should probably return to. there is a pretty clear theme to my responses. please see below.

Regards,
Christopher Mayne

>
> also i would like to state. how i overcome the previous error maybe it will be helpfull for others.
> 1) one of the atom name Oxygen has been replaced by FFTK to carbon and after doing the RHF calculation the water molecule just bounces out and i got a trajectory of 50 frames for the step so i removed it.
> 2) Aother error is really stupid like the toolkit creates some file with 120a and 120b for the same atom name when you load the optimized file into the next step it creates an error "atom name" has multiple bonds. so i removed that file too.
>

1. It is the responsibility of the user to ensure that the Gaussian optimization files terminate normally, and yield water positions that represent reasonable and useful energy minima. The entire point of the "Load LOG Files" button in the "Water Int." tab is to aid users in visualizing this and catching such problematic interactions.

2. I would argue that the user that discards target data without a clear justification is "really stupid." The toolkit generates these files for reasons that are explained in the resources linked to on the documentation pages. You should read up on CHARMM and CGenFF. Also, overcoming this error is simple--make sure that these target data are assigned to an appropriate atom name (i.e., just delete the 120x from the automatically parsed filename).

A major contribution to your troubles is that you are trying to optimize charges for the entire substituted porphyrin structure that includes 97 input files of target data. That is overwhelming your ability understand where your charge optimization is going off of the rails.

> since quantum calculation computes charges for all the atoms you dont really need to worry placing water molecule for each atom.

This is an ignorant statement within the context of parameterization of CHARMM compatible force fields. Please read up on how charges are properly derived according to the underlying principles of CHARMM and CGenFF force fields.

> but it would be really helpful if its clearly stated in the journal of FFTK how exactly the final charges are computed from each file.
>

We have submitted a manuscript that covers these details. If you perused more of the CHARMM and CGenFF literature, you could probably make an informed guess as to what we are doing. The complete source code is also available in the plugins directory.