Re: Strange (very large) atom motions

From: Chris Harrison (charris5_at_gmail.com)
Date: Thu Feb 03 2011 - 18:18:24 CST

Craig,

Two things immediately come to mind:

1) All of your crashes sound like they're occurring due to extremely
high velocities that violate RATTLE limits, produce global exclusions,
etc. These high velocites are resulting b/c of ... let's call them
"wonky" ... interactions between the Fe and your phenanthrolines. It
sounds like your parameterizion is off, perhaps contaminated with a bad
mode that oscillates the Fe and N too close which results in very high
forces pushing them apart too fast. It could also be that you missed a
mode that's crucial to balance and prevent the high oscillations you're
seeing. You don't mention how you handled your charge parameterization,
which could directly influence the strength "wonky" interactions.

2) A second thought is that you're simulating a +2 simulation cell (I'm assuming
standard redox state of ferroin) as a vacuum. Have you tried adding
chlorine to the system to remove the formal charge of your cell?

Best,
Chris

--
Chris Harrison, Ph.D.
Theoretical and Computational Biophysics Group
NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave., Urbana, IL 61801
char_at_ks.uiuc.edu                          Voice: 217-244-1733
http://www.ks.uiuc.edu/~char              Fax:   217-244-6078
Craig Jolley <jolleycraig_at_gmail.com> writes:
> Date: Thu, 3 Feb 2011 16:14:42 -0700
> From: Craig Jolley <jolleycraig_at_gmail.com>
> To: namd-l_at_ks.uiuc.edu
> Subject: namd-l: Strange (very large) atom motions
> 
> Hi everyone...
> 
> I'm trying to use NAMD to simulate metal-organic coordination compounds; and
> I've set up some simple test simulations using ferroin.  I got forcefield
> parameters for ferroin by matching normal modes in CHARMM to normal modes
> obtained from DFT and modifying the parameter file using Metropolis MC to
> improve the mode overlap and frequency agreement; the resulting parameters
> might be a little over-refined at this stage but I think they're pretty much
> OK.
> 
> The problem is that when I run an in vacuo simulation of a single ferroin
> molecule with no solvent (67 atoms), the simulation crashes with the famous
> RATTLE constraint failure error.  I know a lot of people have posted to
> NAMD-l about this error, but in most cases it seems to be related to
> equilibration of a solvated system with periodic boundary conditions; this
> is just 67 atoms all alone in space.  Sometimes they'll run just fine for
> hundreds of ps, then crash with this error.  Once I got a bad global
> exclusion count error instead.  If I set my parameter file to output a DCD
> frame at every step, I can watch what goes wrong near the end -- as a rule,
> the central Fe atom takes a huge jump in one direction, seemingly without
> provocation, and two of the N atoms bonded to it take huge jumps in the
> opposite direction.  They continue this excursion for a few steps, then
> everything starts gyrating around wildly and the simulation crashes.  If I
> output energies at each frame, I don't see any unusual changes in energy
> terms preceding this weird excursion -- it seems completely unprovoked.
> 
> The problem comes up a lot with 2 fs timesteps at 300K; if I shorten the
> timestep to 1 fs then I still get RATTLE failures, but they take longer to
> show up.  If I use the langevinFile and langevinCol parameters to remove
> Langevin coupling from Fe, the failure looks pretty much the same.  If I
> turn off Langevin dynamics entirely, then I still get a RATTLE failure but
> it doesn't seem to be a result of the same kind of big Fe motion; the motion
> just looks really weird from the outset, with very distorted geometries.
> 
> The small ferroin simulations were run on my desktop (NAMD 2.6 under Linux)
> and encountered the RATTLE error in a larger coordination polymer simulation
> on TACC Ranger.  Of course I don't know for a fact that the error I
> encountered in the big simulation was the same as the small one, but that
> seems like a reasonable assumption for now, since the small simulations fail
> every time if I wait long enough.
> 
> Any ideas about what might be happening here?  I've run out of ideas for
> things to try; I'm not eager to re-parameterize my forcefield but that's the
> only thing I can think of that might still be the problem.  My NAMD
> configuration file is pasted below; I can send my coordinate/PSF/parameter
> files upon request.
> 
> Thanks,
> 
> --craig
> 
> structure          3phen-new.psf
> coordinates        3phen-min.pdb
> 
> set temperature    300
> set outputname     3phen_out
> 
> firsttimestep      0
> 
> # Input
> paraTypeCharmm        on
> parameters          /home/craig/Projects/coord_poly/coord_poly.par
> #parameters          3phen.par
> temperature         $temperature
> 
> # Force-Field Parameters
> exclude             scaled1-4
> 1-4scaling          1.0
> cutoff              12.
> switching           on
> switchdist          10.
> pairlistdist        13.5
> 
> # Integrator Parameters
> timestep            2.0
> rigidBonds          all
> nonbondedFreq       1
> fullElectFrequency  2
> stepspercycle       20
> pairlistsPerCycle   2
> 
> # Constant Temperature Control
> langevin            on
> langevinDamping     5
> langevinTemp        $temperature
> langevinHydrogen    off
> 
> # Output
> outputName          $outputname
> 
> restartfreq        500000
> dcdfreq             1
> #dcdfreq             500000
> xstFreq             500000
> outputEnergies      1
> outputPressure      10000
> 
> run 5000000
> 
> -- 
> Craig Jolley
> Postdoctoral Research Associate
> Astrobiology Biogeocatalysis Research Center
> Montana State University
> http://capsid.msu.montana.edu/cjolley

This archive was generated by hypermail 2.1.6 : Mon Dec 31 2012 - 23:19:46 CST