Hi,
It does appear that mmpbsa.py makes use of the "autoimage" feature,
and imaging can certainly affect your energies if the distances used
are not properly imaged. I don't know if there is a way to pass
'autoimage' arguments to mmpbsa.py - hopefully one of the devs can
comment on this.
-Dan
On Wed, Feb 1, 2017 at 8:09 AM, Eiros Zamora, Juan
<j.eiros-zamora14.imperial.ac.uk> wrote:
> Dear Amberists,
>
> I’ve ran a 1500ns simulation (75000 frames) of a ligand binding to a protein. I’ve succesfully used MMPBSA.py.MPI to get the DeltaG of binding and I’ve got two questions I haven’t been able to figure out myself.
>
> For clarity, here is the input file and command I’ve used to run the analysis:
>
> Input file for running PB and GB
> &general
> verbose=2,
> strip_mask=:Na+,Cl-,
> ligand_mask=:LIG,
> netcdf=1,
> interval=10
> /
> &gb
> igb=5,
> saltcon=0.150
> /
>
> $ mpirun -np 4 MMPBSA.py.MPI -O -i mmgbsa.in -sp ../../salted.prmtop \
> -cp complex.prmtop -rp receptor.prmtop -lp ligand.prmtop -eo energies.csv -y ../trajs*.nc
>
> The calculation ran without problems, except for a couple of warnings:
>
> Loading and checking parameter files for compatibility...
> cpptraj found! Using /usr/local/amber16/bin/cpptraj
> mmpbsa_py_energy found! Using /usr/local/amber16/bin/mmpbsa_py_energy
> Preparing trajectories for simulation...
> 7500 frames were processed by cpptraj for use in calculation.
>
> Running calculations on normal system...
>
> Beginning GB calculations with /usr/local/amber16/bin/mmpbsa_py_energy
> calculating complex contribution...
> calculating receptor contribution...
> calculating ligand contribution...
>
> Timing:
> Total setup time: 0.000 hr.
> Creating trajectories with cpptraj: 0.026 hr.
> Total calculation time: 2.652 hr.
>
> Total GB calculation time: 2.633 hr.
>
> Statistics calculation & output writing: 0.000 hr.
> Total time taken: 2.679 hr.
>
>
> MMPBSA.py Finished! Thank you for using. Please cite us if you publish this work with this paper:
> Miller III, B. R., McGee Jr., T. D., Swails, J. M. Homeyer, N. Gohlke, H. and Roitberg, A. E.
> J. Chem. Theory Comput., 2012, 8 (9) pp 3314--3321
> /usr/local/amber16/lib/python3.5/site-packages/MMPBSA_mods/main.py:604: UserWarning: ligand_mask overwritten with default
>
> warnings.warn('ligand_mask overwritten with default\n')
> /usr/local/amber16/lib/python3.5/site-packages/MMPBSA_mods/main.py:604: UserWarning: ligand_mask overwritten with default
>
> warnings.warn('ligand_mask overwritten with default\n')
> /usr/local/amber16/lib/python3.5/site-packages/MMPBSA_mods/main.py:604: UserWarning: ligand_mask overwritten with default
>
> warnings.warn('ligand_mask overwritten with default\n')
> /usr/local/amber16/lib/python3.5/site-packages/MMPBSA_mods/main.py:604: UserWarning: ligand_mask overwritten with default
>
> warnings.warn('ligand_mask overwritten with default\n’)
>
> Autoimage issue
> Now, my first question is regarding the use of autoimaging within the MMPBSA code. When I made the system’s PDB and prepared it with tleap, I placed the LIG residue before the protein. This gave me some problems with cpptraj’s autoimage command when I post processed the trajectories: since the LIG is the :1 molecule, autoimage used it as the anchor, and the resulting trajectory ‘broke’ the protein, as it went outside the simulation box and entered through the other side. I managed to fix it though, by manually specifying the anchor as such: “autoimage anchor :2-162”. Now, the problem is that in MMPBSA I think the ‘autoimage’ command is being used again, with the defaults. So if I visualise the receptor.prmtop with the corresponding _MMPBSA_receptor.nc.* files, the protein is again broken (see attached picture, the three coloured proteins should be together). [cid:4B0025D5-6B92-45CE-83EA-F8C9E7EF33F6.ch.ic.ac.uk]
> Does this affect the energy calculations in MMPBSA? (Maybe the autoimage changes the distances between the atoms, affecting the energies?). If so, is there a way to manually specify which molecule to use for anchor in the autoimage command?
>
> Parsing multiple output files
> My second problem comes from the multiple output files that are generated from the MPI version of the program. In total, 7500 frames are to be processed. Since I use four processors, I have four _MMPBSA_complex.gb.mdout files. Two of them have processed 1875 frames, another one 1874 and the other 1876, so in total it’s 7500. The problem is that these files always number the frames starting from one, so I have no way of knowing which processor was analysing which of the 7500 original frames. Can I assume that processor 0 analyses frames 1 to 1876, then processor 1 analyses from 1877 to 3752 and so on?
>
>
> Sorry for the long email, but I haven’t found anything related to this in the manual.
>
> Thanks in advance for any comments,
>
> Juan Eiros
>
>
>
>
>
>
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
--
-------------------------
Daniel R. Roe
Laboratory of Computational Biology
National Institutes of Health, NHLBI
5635 Fishers Ln, Rm T900
Rockville MD, 20852
https://www.lobos.nih.gov/lcb
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Feb 02 2017 - 07:00:03 PST
