VMD-L Mailing List
From: Juan R. Perilla (juan_at_ks.uiuc.edu)
Date: Thu Nov 21 2013 - 17:12:21 CST
Great to hear from you. I believe Josh's is not facing the same issue as
you as he is only using water for his test case. In your case, I think you
probably have a large solute therefore the PSF might be breaking not
because of the water, but because of your solute. In general, for a large
structure, it is not advised to let solvate deal with the solute, as it
does several atom selection evaluations under the hood that result in
terrible performance (e.g. solvating a large structure can take up to a
day). In general I would suggest that you first create a water box as josh
is suggesting, and then load solute and solvent together. You will end up
with a lot of clashes, but you can fix them later on by deleting the
overlapping atoms; this procedure will take at most an hour in my
experience. Finally, as Josh suggested you should try to use the JS
format, which is widely used by us in the lab. We not only use it for big
simulations, but also for non-standard parameters and topologies as the
file format itself is more flexible than your typical psf/pdb paradigm. You
should be able to easily generate JS files by using the stand-alone version
of PSFGEN (included with NAMD), or the nightly build version of VMD
# It should look something like this to remove the atoms from the clashed
mol new overlap.js
set good [atomselect top "not same residue as exwithin 2.4 of not segname
puts "final atom count: [$good num]"
puts [measure minmax $good]
$good writejs final.js
$good writenamdbin final.coor
TIP3P water models in CHARMM36 and CHARMM22 are essentially identical. As
Josh points out, explicit h-bonds have not been used for a very long time
in the MD community. I suggest you be careful if you are trying to use
CHARMM36 with your simulations, as it requires a few technical details that
differ from C22; you can browse the literature for more details. In my
experience, for large simulations you will face several difficulties far
much more complicated than simply solvating. I would suggest, given that
you are very close to us, that you consider attending one of our
workshops. We are hosting one in January
Juan R. Perilla
NIH Biomedical Technology Center for Macromolecular Modeling and
Theoretical and Computational Biophysics Group (http://www.ks.uiuc.edu/)
University of Illinois at Urbana-Champaign
3143 Beckman Institute for Advanced Science and Technology
405 N. Mathews
Urbana, IL 61801
Phone: +1 (217) 244 - 7403
On Mon, Nov 18, 2013 at 1:41 PM, John Grime <jgrime_at_uchicago.edu> wrote:
> Hello John,
> Thanks for the help on this - I appreciate it's a weird situation, and a
> little out of the ordinary vs the common use-cases.
> Juan and I have actually met a couple of times in the past, so: hi, Juan!
> I hope all is well with you, mate.
> From: John Stone [johns_at_ks.uiuc.edu]
> Sent: Friday, November 15, 2013 4:17 PM
> To: John Grime
> Cc: vmd-l_at_ks.uiuc.edu; Jim Phillips; Juan Roberto Perilla
> Subject: Re: vmd-l: Problems with large solvation boxes
> Hi John,
> Sorry for the slow reply. I've been swamped finishing things before
> I fly out to SC2013 early tomorrow morning. As you're discovering,
> there are a number of challenges involved with the construction of very
> simulations. The tools we have built-into VMD work fine for "normal"
> sized simulations, but for very large structures some of the GUI-based
> tools don't perform as well as they could because they use old techniques
> that worked fine when they were originally written, but that don't perform
> well on huge structures with tens or hundreds of millions of atoms. The
> other factor aside from the performance of the tools is that some of the
> file formats (e.g. PDB and PSF) were never designed to be used for
> in this size range, and the file formats can break in various ways, and/or
> the file readers in various other programs may not like certain variants
> of the file formats.
> What we have done in VMD and NAMD to overcome these problems is
> to make slightly non-standard variants of the PSF format that use
> space-delimited fields, which are readable by NAMD, but not necessarily
> by anything else. Another approach we have taken is to begin using
> a experimental combined structure and trajectory format I named ".js"
> (guess who) that should handle structures into the two-billion-atom
> size range before problems start to crop up. This 'js' format can
> be read and written by VMD and NAMD and psfgen, so that covers the
> basics, although it won't help you if you're using other programs.
> The area where things remain complicated even with just VMD/NAMD/psfgen
> is that several of the VMD GUI-based structure building tools like
> solvate, autoionize, etc predate any of these issues, and they haven't
> been completely updated to do things the "new" way. For example, the
> newest version of psfgen can do a pretty good job of generating a solvent
> box without much help from the rest of VMD, but the current solvate
> plugin doesn't yet take advantage of this feature of psfgen. So, at
> the moment, several of the people in our lab that work on huge structures
> end up writing their own custom scripts for some of the structure building
> work rather than using the canned GUI-based plugins that you see in the
> VMD extensions menu. We are working on updating the GUI-based structure
> building tools in VMD for large systems, but since these issues only
> affect a very small number of VMD users so far, we have chosen to
> focus on developing the low level infrastructure and files formats
> in VMD, NAMD, and psfgen, and leave the updates to the GUI plugins
> until we're satisfied with how these things are working based on our
> experiences with doing things the "new way".
> To help you (and others) that may run into issues like this, I've asked
> a couple of the people in our lab to share some of the scripts and
> and this should help you get past some of these minor hurdles using VMD
> to build your water box and subsequent steps. I'm CCing Jim Phillips who
> works on NAMD+psfgen and Juan Perilla who has done several large
> and has written a bunch of his own scripts for some of these things.
> We should be able to help you get your problem solved with a few
> Once I get back from SC2013 late next week I should have more time to
> answer remaining questions you may have.
> John Stone
> On Mon, Nov 11, 2013 at 03:04:24PM +0000, John Grime wrote:
> > Hello,
> > I'm trying to create a large solvation box using VMD 1.9.2a33 for
> > Linux/AMD64, and while the solvation script appears to work, VMD is
> > to load the resultant PDB file.
> > The "solvate.psf" file appears to be okay, but the "solvate.pdb" file
> > produces the following error when read into VMD:
> > Info) Using plugin pdb for coordinates from file /home/solvate.pdb
> > ERROR) Incorrect number of atoms (10445941) in
> > ERROR) coordinate file /home/solvate.pdb
> > There should be around 50,000,000 atoms in the PDB file (this value is
> > correctly reported when reading "solvate.psf").
> > Can anyone help me to figure out what I can do, here?
> > Also, the topology file which seems to accompany the solvate plugin
> has a
> > somewhat different set of data for the TIP3 water compared to the
> > of "toppar_water_ions.str" in the CHARMM36 force field set that I'd
> > to use. As the difference seems to only be the presence of "DONOR"
> > in "toppar_water_ions.str" ("wat.top" in the solvate plugin only has
> > "ACCEPTOR" entry), I guess this difference is not significant as NAMD
> > typically ignores thes H-bond entries?
> > Thanks!
> > J.
> NIH Center for Macromolecular Modeling and Bioinformatics
> Beckman Institute for Advanced Science and Technology
> University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> http://www.ks.uiuc.edu/~johns/ Phone: 217-244-3349