Re: [AMBER] problem with chamber & vmd generated psf (line 2349 of file psfprm.F90)

From: Jason Swails <>
Date: Sun, 10 Aug 2014 17:44:19 -0400

On Sun, Aug 10, 2014 at 5:05 PM, Marc van der Kamp <
> wrote:

> On 9 August 2014 22:16, Jason Swails <> wrote:
> >
> > ​Where did this PSF file come from?
> PSF is written by VMD's psfgen, version 1.5 I think.
> > It's missing 3 sections that I haven't
> > seen ​_all_ missing from a PSF file: NUMLP/NUMLPH, and NCRTERM
> (effectively
> > the CMAP section).
> NCRTERM is expected not to be there (or at least unpopulated) in this case,
> as the test-case was without protein (just CGenFF parameterized ligand and
> some water).
> psfgen does write this section (as it should) when protein (and thus CMAP
> terms) are present. But I'm assuming old (pre-CMAP) charmm versions will
> also not write this section.
> As Sarah pointed out already in this thread, when you do "writepsf charmm
> <mypsf>.psf" in psfgen, the following line is 'missing' (but required by
> chamber):

> > If this is a typical example from a standard source, I
> > will probably have to rethink how I parse PSF files in ParmEd to be a bit
> > more flexible to the abuse the PSF file format has taken (reminiscent of
> > what's happened to the PDB format, really...
> >
> I'd say psfgen is reasonably standard, as it is the main option to write
> psf's if you don't have access to or don't want to use charmm.

​I agree. After I sent the email, I realized that NCRTERM is not
necessarily present when CMAPs aren't used. In any case, I was unhappy
with how fragile my PSF parser in ParmEd turned out to be, so I redesigned
it. My initial feeling was that the !LABEL tags next to each section were
comments that could not be relied upon to exist, so I parsed each section
in the order I thought they would always be in. But the more PSFs I see,
the more I realize that the exact ordering and presence of the sections
varies far more than the !LABEL tags for each section.

Long story short, the ParmEd PSF parser now supports your PSF file (at
least the dry one you sent last) if you pull the latest changes from the
ParmEd github repo.

The parameter file did concern me a bit, though. It looks to me like the
NONBONDED parameters for many of the atom types come in the NBFIX section
of the parameter file. So where it starts:

!!! From par_all36_cgenff.prm !!!

!!!!! chmwvdk, 4/08/14 !!!!!


HGA1 0.0 -0.0450 1.3400 ! alkane, igor, 6/05

HGA2 0.0 -0.0350 1.3400 ! alkane, igor, 6/05
the parameter file parser ​still thinks it's reading the NBFIX section from
above, so none of the LJ parameter types from that point down are loaded,
resulting in an error similar to the one you reported originally. If you
cut the NBFIX section out and move it to the bottom (before the END card),
then ParmEd works fine.

How did you make the parameter file? Is that also something I will need to
add support for?


Jason M. Swails
Rutgers University
Postdoctoral Researcher
AMBER mailing list
Received on Sun Aug 10 2014 - 15:00:02 PDT
Custom Search