VMD-L Mailing List

From: viktor drobot (linux776_at_gmail.com)
Date: Wed Sep 25 2019 - 10:16:20 CDT

Thank you a lot for your efforts!

-------- Original message --------
> 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/