I created .prmtop topology and .inpcrd coordinate files in tleap, and then I ran minimization, heating, and equilibration steps, and then 10 ns of production with pmemd in AMBER 14 and created .rst and .mdcrd files for my protein-ligand complexes, I noticed when trying to view the trajectory in VMD, it looked like my complex went out of the box during some steps, and I just want to make sure I'm looking at the files correctly since I'm new to MD simulations. In VMD, I used the command "vmd complex.pdb", and then loaded the complex.prmtop file and then the complex.inpcrd file, and then the min.rst, heat.rst, and equil.rst files, and then the production.rst files for each of the 10 nanoseconds. Is this the correct way to view trajectories in VMD? What is the purpose of visualizing the trajectory for MD simulations?
When trying to load the files for one of my complexes in VMD, I noticed that my complex.inpcrd, min.rst, and equil.rst files jumped around on the screen into different positions, but after the prod.rst files, it stayed relatively in place. I also noticed that for some of my complexes, the RMSD didn't converge completely after 10 ns because there were very sharp sudden peaks in my RMSD graphs that I created with cpptraj, so I was wondering if the issue could just be my settings during the MD simulations, or if I'm selecting the wrong files to load into VMD. Should I load the .mdcrd files instead of .rst, or would there not be a difference?
Hey,
This is probably the imaging problem, you can use 'autoimage' command in cpptraj (part of ambertools) to get rid of the imaging artifacts (RMSD plots should not have peaks after this operation) before looking at your results in VMD or cpptraj. After that, the most straightforward way to load a trajectory to VMD is to first load the topology (it contains the atom and connectivity info) and then load 'autoimaged' trajectory (or trajectories) and alinging it according to CA or backbone atoms to remove translation and rotation. I would not load restart files (this is just a single snapshot which also contain velocities which is useful when you want to extend the simulation further) unless you have a specific interest in that.
Hope that'll help.
Best,
Janek
Jan Ludwiczak Thanks so much for your response! I will try that! So the autoimage command basically will make the all the mdcrd files that I load in during cpptraj to align to the first mdcrd file? So when I use the autoimage command, for the parameters should I select my whole complex as the mask, or just the receptor part or just the ligand?
Here are all the commands that I entered in cpptraj:
parm complex3solvated.prmtop
list parm
parminfo 0
trajin prod3.mdcrd
trajin prod3-extend2ns.mdcrd
trajin prod3-extend3ns.mdcrd
trajin prod3-extend4ns.mdcrd
trajin prod3-extend5ns.mdcrd
trajin prod3-extend6ns.mdcrd
trajin prod3-extend7ns.mdcrd
trajin prod3-extend8ns.mdcrd
trajin prod3-extend9ns.mdcrd
trajin prod3-extend10ns.mdcrd
trajin prod3-extend11ns.mdcrd
trajin prod3-extend12ns.mdcrd
trajin prod3-extend13ns.mdcrd
trajin prod3-extend14ns.mdcrd
trajin prod3-extend15ns.mdcrd
trajin prod3-extend16ns.mdcrd
trajin prod3-extend17ns.mdcrd
trajin prod3-extend18ns.mdcrd
trajin prod3-extend19ns.mdcrd
trajin prod3-extend20ns.mdcrd
trajin prod3-extend21ns.mdcrd
trajin prod3-extend22ns.mdcrd
trajin prod3-extend23ns.mdcrd
trajin prod3-extend24ns.mdcrd
trajin prod3-extend25ns.mdcrd
trajin prod3-extend26ns.mdcrd
trajin prod3-extend27ns.mdcrd
trajin prod3-extend28ns.mdcrd
trajin prod3-extend29ns.mdcrd
trajin prod3-extend30ns.mdcrd
trajin prod3-extend31ns.mdcrd
trajin prod3-extend32ns.mdcrd
trajin prod3-extend33ns.mdcrd
trajin prod3-extend34ns.mdcrd
trajin prod3-extend35ns.mdcrd
list trajin
trajout 35ns_com3_CACN.trj
strip :WAT
reference complex3solvated.inpcrd
rms reference out CACN35nscomplex3.rmsd :1-207@CA
rms reference out CACN35nsligand3.rmsd :208
rms reference out CACN35nscomplex3.gnu :1-207@CA
rms reference out CACN35nsligand3.gnu :208
list actions
run
quit
Should I be using the "autoimage" command right before the "trajin prod3.mdcrd" line?
Everything that people measure in the lab are ensemble averages. Molecular dynamics is one approach to estimating the ensemble average numerically; the other is the Monte Carlo method. If you are seeing odd behaviors in your simulations, it is (almost) always your fault. The MD trajectory will not be fluid, because one typically only saves coordinates every picosecond. Hence the VMD view will be jittery. (If you save every frame, the jitter goes away.) If you are seeing large jumps, then that is an unnatural occurrence and needs to be investigated. In my view, the MD method's greatest advantage is that it is easier to debug: if the trajectories don't look right, they aren't right. If the whole protein shifts to the left from one frame to the next, that is unphysical and is the result of you doing something. You (inadvertently) shifted the coordinates or cause the center of mass to move. Unfortunately, this means that you'll have to take the time to understand what all of the myriad parameters in the simulation software mean. You really cannot treat it as a black box.
I don't know what you mean by equilibration but, generally, one starts a simulation with the protein backbone harmonically constrained. This holds everything close to the position that was found in the crystal structure, while the water solvates the protein. When you release the constraints, there is nothing holding the protein in the box other than the water bath. If the protein is drifting out of the box, you may need to increase the size of the box. Remember that the structure was solved in the crystal and that the solution structure may be somewhat different Additionally, in a "diffuse limit" solution, you do not want the protein to interact with periodic images of itself. With a 13 A cutoff for electrostatic interactions, you need at least 7 A of water buffer between your protein and the edge of the box. This means that you will be pushing around a lot of water, more than protein, but that is the current limitation of simulation. Fortunately computers are much faster now.
- Badges
- Science topic