Carlos,
It seems that there is a kind of misunderstanding.
I didn't load in the VMD a pdb file.
I wrote in my previous email that I used the command with the
intrinsic Amber function ambpdb:
ambpdb -p mc.prmtop < mc.inpcrd > mc_init.pdb
ambpdb uses the generated topology file: mc.prmtop.
For my understanding, if the mc.prmtop is corrupted
the ambpdb cannot generate correct pdb file mc_init.pdb.
In fact the mc_init.pdb is correct. I have visualized the generated
mc_init.pdb by two different software: USCF Chimera and Yasara.
In both cases the structure of the protein is correct.
Your comments appreciated.
Michael
*****************************
Michael Shokhen, PhD
Associate Professor
Department of Chemistry
Bar Ilan University,
Ramat Gan, 52900
Israel
email: shokhen.mail.biu.ac.il<https://webmail.biu.ac.il/owa/redir.aspx?C=a160ef9b9a6b4d06992402715d3ee465&URL=mailto%3ashokhen%40mail.biu.ac.il>
________________________________
From: Carlos Simmerling <carlos.simmerling.gmail.com>
Sent: Wednesday, October 25, 2017 10:59:28 PM
To: AMBER Mailing List
Subject: Re: [AMBER] disulfide bonds braking during MD simulation
No this is not correct. If you load a pdb file, VMD uses distances to
determine bonds. This will not tell you if the prmtop is correct. Load the
prmtop first in order for VMD to use bind information from the prmtop.
On Oct 25, 2017 3:39 PM, "Michael Shokhen" <michael.shokhen.biu.ac.il>
wrote:
> Dear Carlos,
>
>
> I have examined by VMD the generated by tleap the mc.prmtop and mc.inpcrd
>
> files of my protein. The VMD version on my computer has the Amber7 Parm
>
> option for the new molecule loading. The structure of the protein
>
> generated by VMD was corrupted .
>
> I have used another option by the Amber function:
>
>
> ambpdb -p mc.prmtop < mc.inpcrd > mc_init.pdb
>
>
> Now the protein structure was correct and all disulfide bonds were intact.
>
> Your comment appreciated.
>
>
> Michael
>
>
>
> ________________________________
> From: Carlos Simmerling <carlos.simmerling.gmail.com>
> Sent: Wednesday, October 25, 2017 9:44:55 PM
> To: AMBER Mailing List
> Subject: Re: [AMBER] disulfide bonds braking during MD simulation
>
> No it is not the case that ff14SB does not work for disulfide bonds. There
> is no problem with the force field for that. You should look carefully at
> the leap.log file in the section where it is making the bonds and see what
> messages you get. Does it find the residue/atom pairs you specify? Using
> restraints will NOT give you the correct behavior since the atoms do not
> have covalent structure that way (with correct angles and dihedrals, and
> nonbonded exclusions).
>
> Load your prmtop and inpcrd into a program like VMD and you should see the
> disulfide bonds drawn. If not, you do not have the correct prmtop yet.
>
> On Oct 25, 2017 2:38 PM, "Michael Shokhen" <michael.shokhen.biu.ac.il>
> wrote:
>
> Dear David,
>
>
> Thank you for your email.
>
> Yes there were a typo error you have identified.
>
> I have corrected it but some disulfide bonds were anyway
>
> broken even by the first minimization.
>
> I have decided to use the disulfide bonds restraints.
>
> After some faults with the input file construction for the minimization
>
> I got the correct result - all disulfide bonds remained intact.
>
> Nevertheless, the principal question remains.
> Could the reason of the broken disulfide bonds is a pitfall of the ff14SB
> force field parametrization and therefore one needs to use
> an artificial tool of the restraint bond distances in order to keep intact
> disulfide bonds during minimization and MD simulations?
>
>
> Thank you,
>
> Michael
>
>
>
>
> ________________________________
> From: David A Case <david.case.rutgers.edu>
> Sent: Wednesday, October 25, 2017 3:39:09 AM
> To: AMBER Mailing List
> Subject: Re: [AMBER] disulfide bonds braking during MD simulation
>
> On Tue, Oct 24, 2017, Michael Shokhen wrote:
> >
> > I have observed braking of disulfide bonds between CYX residues
>
> This implies that the bonds were never properly created.
> >
> >
> > source leaprc.protein.ff14SB
> > source leaprc.water.tip3p
> > mc = loadPDB 1fle_nh.pdb
> > bond mc.31.SG mc.47.SG
> > bond mc.128.SG mc.195.SG
> > bond mc.159.SG prot.175.SG
> ^^^^ ???
>
> What is "prot"? It doesn't seem to have been defined, and it would not
> be surprising if the expected bond were breaking.
>
> As Carlos pointed out, this problem is almost certainly noted in the tleap
> output, and it's good to learn what to look for. Another good idea (TM)
> is to use the "checkvalidity" command in parmed: it searches for missing
> disulfide bonds.
>
> But to developers: this points up two genuine problems with tleap:
>
> 1. The output is so voluminous that people understandably have a hard
> time reading it.
> 2. tleap really should quit when errors like this are encounterd. I
> understand that this would break some existing scripts, but the
> benefits are likely to outweigh the disadvantages.
>
> I suppose I should be the one to attack this, but it would be really great
> if someone would step up to the plate (this being World Series time....)
> It's really pretty trivial coding to find these and other error messages
> and make them fatal. Removing un-needed messages is more of an art, but
> is still super-straightforward.
>
> ...dac
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Oct 25 2017 - 13:30:05 PDT
