VMD-L Mailing List

From: surya narayanan chandrasekaran (sonofsunsurya_at_gmail.com)
Date: Thu May 30 2013 - 14:43:57 CDT

Hi,

Thank you for the reply. I have kept the files in my drop box below link.
three files ChargeOptScript.tcl, ChargeOpt.log and ChargeOpt.debug.log
https://www.dropbox.com/sh/6klo7fzbgshgtnk/LpfqxDz-Pf/forcefield?n=106188702

On Thu, May 30, 2013 at 2:56 PM, Mayne, Christopher G
<cmayne2_at_illinois.edu>wrote:

> 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.
>
>
>
> 

-- 
Suryanarayanan C
M.S Chemist
+94-01794019116