Hello,
I've put my comments below where they're most applicable
On Mon, Dec 13, 2010 at 4:36 PM, Bozell, Joseph John <jbozell.utk.edu>wrote:
> These may be very basic questions normally answered with "it depends", but
> I am wondering if the list can point me toward any information regarding
> rules of thumb for setting some of the more common .mdin file parameters.
> Some specific questions:
>
You probably will see a lot of "it depends" :)
>
> 1) With the following .mdin file:
>
>
> &cntrl
>
> imin = 0,
>
> irest = 1,
>
> ntx = 7,
>
> ntb = 2,
>
> pres0 = 1.0,
>
> ntp = 1,
>
> taup = 2.0
>
> cut = 12,
>
In my opinion, this is too large for CUT for periodic systems. The default
value of 8 is typically satisfactory for PME simulations. Note that this is
really only a cutoff for VDW interactions, which scale as R^-6. Full
electrostatics are handled as a combination of direct space sums and
reciprocal space sums, so there is no actual truncation of EEL interactions.
>
> ntr = 0,
>
> ntc = 2,
>
> ntf = 2,
>
> tempi = 380.0,
>
> temp0 = 300.0,
>
> ntt = 3,
>
> gamma_ln = 1.0,
>
> nstlim = 1000000, dt = 0.002,
>
> ntpr = 1000, ntwx = 100, ntwr = 1000
>
I strongly recommend setting ioutfm=1 in your input file as well to write
NetCDF format trajectory files. Dan Roe had a good post on the list
recently about all the advantages of using NetCDF (which ptraj and VMD both
recognize and process much faster). There is almost no advantage to using
ASCII trajectory files.
You may also want to consider using "iwrap=1" unless you want to study
diffusion properties. Just realize that as particles diffuse to adjacent
boxes, eventually they will move *too far* for the fixed-format files to
handle the super-large coordinates. This issue has come up numerous times
on the list in the past.
>
> /
>
>
> I end up generating an immense .mdcrd file (6.2 GB) that crashes VMD on my
> MacBook pro after loading about 85% of the generated frames (with the
> standard Mac error message "VMD 1.8.7 quit unexpectedly"). Is reducing the
> file size by lowering the number of writes to that file acceptable (i. e.,
> for scrutiny by others) via modifying
You are printing out frames every 200 ps over the course of 2ns of
simulation. This is far too frequent, especially for a fully solvated
system. In my simulations, I typically write out snapshots every 1000
steps. It's a balancing act -- you want enough frames to get statistics
from without having *too* much data that's difficult to analyze.
> ntwx to, say, 1000, or 10000? I note that from the manual I could also set
> ntwprt to limit the .mdcrd file to only
ntwprt will print out the coordinates of atoms 1 to ntwprt only. If you're
not concerned with the coordinates of the water molecules, then you can set
ntwprt = last atom you are interested in. Your prmtop file has all atom
names, etc. What I would suggest doing, if you want to use ntwprt, is to
open up your prmtop file, figure out which residue is the first WAT (search
for %FLAG RESIDUE_LABEL in your prmtop file), and find out which atom number
that starts on (it is the corresponding number in %FLAG RESIDUE_POINTER).
If it starts on atom 28, then set ntwprt=27. Note that you will have to
create a new prmtop file that has only atoms 1 to 27 in order to analyze
and/or visualize your trajectory.
> the portions of interests. However, I am examining an array of 5 small
> organics in a water box. Are the atom numbers referred to for setting ntwprt
> those listed in the first column of the .prepin file? That would not seem to
> be the case, as there aren't enough atoms to account for all 5 molecules
> being modeled.
>
>
> 2) The term "production dynamics" gets used frequently…however, the
> literature reports setting nstlim for "long" runs at anywhere from 2 to 40
> nanoseconds. Is there any consensus on what defines a production run?
>
It depends :). Sadly, the smaller your system, the less time is needed to
explore conformational space, and the faster it is done. The bigger your
system, the more degrees of freedom you have, and the longer it takes to
explore conformational space, and it is done slower. One thing that may be
helpful to test convergence is to break your simulation up into large
chunks, and check that the properties you're interested in are the same for
each chunk (i.e. your system is not moving to another place along your free
energy surface). Explicit solvent simulations also typically take longer to
explore conformational space due to the noise caused by the waters. So
depending on how small your organic molecules are, perhaps 5-10 ns are
sufficient. Maybe you need more, maybe less (how many atoms are in your
system).
Hope this helps,
Jason
>
> An understanding of typical baseline parameters for average runs would be a
> big help in then understanding the types of values more outside of the norm.
> Any guidance is greatly appreciated.
>
>
> Joe Bozell
>
> University of Tennessee
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Graduate Student
352-392-4032
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Mon Dec 13 2010 - 15:00:03 PST
