VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Wed Sep 25 2019 - 10:14:31 CDT

Hi,
  I have implemented a fix for the problem that prevented AMBER CRD files
(and other trajectory file formats that have an indeterminate atom count)
from being loaded correctly. This fix will go out in the next test builds I
post on the web site later this week.

Best,
  John Stone

On Wed, Sep 25, 2019 at 08:45:14AM -0500, John Stone wrote:
> Hi,
> Upon digging further, this appears to be a side effect of changes made
> for to support hybrid modeling file formats (e.g. new PDBx mmCIF files),
> and is unrelated to the parsing of the AMBER files themselves.
>
> An extra check was made for numatoms > 0 in the core VMD code,
> but the old AMBER trajectory file formats don't actually record
> the atom count in the .mdcrd file itself, so this has to be
> determined by reading the .prmtop file prior to the .mdcrd.
> VMD deals with this using a special MOLFILE_NUMATOMS_UNKNOWN flag
> that is only needed for a couple of the 75+ molfile plugins, and the
> changes to the safety checks in that were made in VMD 1.9.4 test versions
> broke the code path that allows formats like the AMBER .mdcrd files to
> be loaded subject to the ordering requirement I describe above.
>
> The safety checks in VMD were changed to accomodate some wacky new
> file structures arising from hybrid modeling which or may not even
> include atomic structure information. So now I have to come up with
> exactly the right set of tests to catch both the hybrid modeling
> file format case and the old AMBER .mdcrd format case with unknown
> atom counts. I'm hoping to have this corrected later today if all
> goes well.
>
> Best,
> John Stone
> vmd_at_ks.uiuc.edu
>
>
> On Wed, Sep 25, 2019 at 01:32:23AM -0500, John Stone wrote:
> > Hi,
> > FYI, I have reproduced the problem you reported with your old ASCII format
> > AMBER, but I haven't (yet) determined what is causing it.
> >
> > Best,
> > John Stone
> > vmd_at_ks.uiuc.edu
> >
> > On Fri, Sep 20, 2019 at 06:51:17PM +0300, viktor drobot wrote:
> > > No, I haven't mixed up anything (in that case VMD usually alerts me
> > > in console).
> > >
> > >
> > > OK, right now I'm using AmberTools19 + AMBER18 software package. You
> > > can download my testcase from here
> > > (https://ftp.desolve.ru/ftp/viktor/vmd_mdcrd_bug.tar.gz). A brief
> > > explanation/details are below.
> > >
> > >
> > > Testcase is simple alanine dipeptide system solvated with TIP3P
> > > water (10 angstroms buffer from each side, so PBC are here). System
> > > was prepared in tleap, here is config for leap:
> > > source leaprc.protein.ff14SB
> > > source leaprc.water.tip3p
> > > peptide = sequence { ACE ALA NME }
> > > solvatebox peptide TIP3PBOX 10.0
> > > saveamberparm peptide system.prmtop system.inpcrd
> > > quit
> > >
> > > Output files are system.prmtop (according to the VMD terminology
> > > it's "AMBER7 Parm") and system.inpcrd (I can open it in VMD if I
> > > choose "AMBER7 Restart"; "AMBER Coordinates" or "AMBER Coordinates
> > > with Periodic Box" doesn't work), latter is just plain text file (I
> > > can see human-readable structure in text editor). After that I've
> > > made some simple calculations - minimization and heating.
> > >
> > >
> > > Step 1. Minimization
> > >
> > > Config is:
> > > Minimize system
> > >  &cntrl
> > >   imin   = 1,
> > >   maxcyc = 10000,
> > >   ncyc   = 5000,
> > >   cut    = 10.0,
> > >   ntb    = 1,
> > >   ntc    = 1,
> > >   ntf    = 1,
> > >   ntpr   = 10,
> > >   iwrap  = 1,
> > >   ioutfm = 0
> > >  /
> > >
> > > Command to run (actually doesn't matter which executable is used:
> > > sander, sander.MPI, pmemd.cuda etc):
> > > mpirun -n 4 pmemd.MPI -O -i 01_min.in -c system.inpcrd -p
> > > system.prmtop -o 01_min.out -r 01_min.rst
> > >
> > >
> > > Step 2. Heating (and producing actual mdcrd)
> > >
> > > Config is:
> > > Heat system
> > >  &cntrl
> > >   imin      = 0,
> > >   irest     = 0,
> > >   ntx       = 1,
> > >   nstlim    = 50000,
> > >   dt        = 0.002,
> > >   cut       = 10.0,
> > >   ntb       = 1,
> > >   ntc       = 2,
> > >   ntf       = 2,
> > >   ntr       = 1,
> > >   ntt       = 3,
> > >   ntpr      = 1000,
> > >   ntwx      = 1000,
> > >   ntwr      = 1000,
> > >   nscm      = 500,
> > >   gamma_ln  = 3.0,
> > >   tempi     = 0.0,
> > >   temp0     = 300.0,
> > >   restraintmask = '!(:WAT) & !@H=',
> > >   restraint_wt  = 10.0,
> > >   nmropt    = 1,
> > >   iwrap     = 1,
> > >   ig        = -1,
> > >   ioutfm = 0
> > >  /
> > >
> > >  &wt TYPE = 'TEMP0', istep1 = 0, istep2 = 50000, value1 = 0.0,
> > > value2 = 300.0 /
> > >  &wt TYPE = 'END' /
> > >
> > > Command to run:
> > > mpirun -n 4 pmemd.MPI -O -i 02_heat.in -c 01_min.rst -ref 01_min.rst
> > > -p system.prmtop -o 02_heat.out -r 02_heat.rst -x 02_heat.mdcrd
> > >
> > > Please note that it's explicitly requested for old mdcrd format in
> > > both config files (ioutfm = 0). After that I have 02_heat.mdcrd file
> > > - it's just plain text file. However, I can't open it within my
> > > system.prmtop in VMD - the problem is exactly the same as described
> > > in my first post. You can check it by downloading my testcase
> > > archive and trying to visualize trajectory - neither "AMBER
> > > Coordinates" nor "AMBER Coordinates with Periodic Box" option works
> > > (in this particular case the latter option should work because I've
> > > prepared my testcase with PBC; however, even for simple in vacuo
> > > systems without PBCs the former options doesn't work too).
> > >
> > > If I convert my mdcrd to NetCDF with the help of cpptraj:
> > > parm system.prmtop
> > > trajin 02_heat.mdcrd
> > > trajout 02_heat.nc
> > > run
> > > quit
> > >
> > > then I'm able to open converted trajectory with my topology
> > > (converted trajectory is in testcase archive too).
> > >
> > > >Hi,
> > > > Most likely you've mixed up a restart variant vs. a trajectory
> > > >variant. We haven't made any changes to the plugins for reading
> > > >the mdcrd files, so unless you have got the wrong file type or
> > > >something has changed with the file structure in the particular
> > > >version of AMBER you're using, I don't think there's actually a
> > > >"bug" here. To determine what's going on, we would need to have a
> > > >copy of your input files, and much more extensive details about
> > > >how you generated them.
> > > >
> > > >Best regards,
> > > > John Stone
> > > > vmd_at_ks.uiuc.edu
> > > >
> > > >On Fri, Sep 20, 2019 at 05:41:40PM +0300, viktor drobot wrote:
> > > >>Ok, where I can file a bug for this issue?
> >
> > --
> > 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
> > http://www.ks.uiuc.edu/Research/vmd/
>
> --
> 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
> http://www.ks.uiuc.edu/Research/vmd/ 

-- 
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
http://www.ks.uiuc.edu/Research/vmd/