Re: [AMBER] PMEMD does not support intermolecular PRFs

From: Maura Catherine Mooney <mmooney05.qub.ac.uk>
Date: Mon, 6 Jun 2011 16:10:50 +0100

Hi Ross,

Many Thanx for the reply. I'll try to explain the prmtop building protocol as concisely as possible, then perhaps you can advise where to go next.

Firstly, the problem is occurring with two systems; one is the protein in question (X) and the other is the protein in question, complexed to another protein (Y). Protein X is available on the PDB and complex (X-Y) is an in-house generated model, using structures from the pdb. Before any work with amber, these 2 systems were prepd and minimized using another commercial software (as AMBER wasn't available at the time). The systems in question contain a region which, from the previous protocol, you can see that I intend on studying with QM. According to the tutorial (written by yourself) I have optimized the geometries in gaussian 03 and calculated the RESP charges using the resp module (following the same protocol as in the tutorial). This was successful and the respective RESP charges were output. The system was then loaded into leap and charges edited for the qm atoms in question. Following this, the system was solvated, and neutralized and then the lib file was saved. I closed leap, then re-opened
and reloaded the files, then used 'check UNIT' to verify the system was ok. After this I saved the prmtop and inpcrd.

I'm relatively new to amber to I've no idea the source of this error, however, one thinks it may possibly have something to do with the qm system. There is a ligand and an ion in my qm system. For the two systems, each qm region contains this ligand and ion, but also a few amino acid residues...in system X, I have a lysine residue included (as I thought this would have a significant electrostatic contribution), in addition to a Thr residue and 4 water molecules. In system X-Y, I have the ligand, ion, 4 waters, Thr, Lys residue and also, two Asn residues and a charged Asp residue. For the initial G03 GO calculation all residues were included in the qm system, and all residues were included in the resp calculation. As I understand, when we load xleap, with a forcefield (ff99.SB in my case), xleap will assign all standard amino acids with the type/charge as defined in this forcefield. In my case, I loaded xleap with the ff99.SB FF but edited the charges to the qm region according to my RESP calc output.
As you can probably imagine, this gave some discrepancy in the neutrality of the system and so I edited the 'truncated' atoms so they were as close to my RESP charges and the ff99.SB charges as possible (i've seen simulation output files which 'force neutrality' if there are tiny discrepancies here). My thought process behind this was the fact that upon the lengthy protocol, the charges will undoubtedly fluctuate and so small changes in the truncated qm region would be rectified in the subsequent simulations.

Only after the resp charges were modified did I solvated, neutrallize and save prmtop and inpcrd files. Is this enough detail to debug this? Also, I understand this is a problem relating to system topology, but is the actual problem with my system or just the way in which prmtop records the topology?

Now, for the use of sander...what is pmemd and sander seeing differently in the prmtop? Why is it that pmemd doesn't support intermolecular PRFs, but assumingly sander does? Also, how reliable is the sander simulation? I can use sander to run the NPT equilibration, but is it valid to 'mix and match' sander and pmemd, throughout one protocol? FYI, I checked the energies of various sander and pmemd simlations and they are similar, so it definately implies some sort of coherence.

Apologies for the lengthy email and many thanx for the support.

P.S I noticed in the amber 11 bugfixes, there is a few issues with the CUDA implementation of amber - but I am not using CUDA enabled pmemd, just pmemd.MPI and sander.MPI.

Cheers,

Maura
________________________________________
From: Ross Walker [ross.rosswalker.co.uk]
Sent: 06 June 2011 06:12
To: 'AMBER Mailing List'
Subject: Re: [AMBER] PMEMD does not support intermolecular PRFs

Hi Maura,

The problem is NOT with your simulation protocol but with your underlying
prmtop. PMEMD does not support intermolecular PRF's (for NPT simulations)
because you should not be able to build a prmtop file with such a setup. So
the question is how EXACTLY did you build this prmtop file? - This is what
we need to debug since leap should not be building such prmtops.

A workaround for now is to run the NPT part in sander and then switch to NVT
with PMEMD once you have the density equilibrated. Although the correct
approach is to figure out how you are building such a system in the first
place.

All the best
Ross

> -----Original Message-----
> From: Maura Catherine Mooney [mailto:mmooney05.qub.ac.uk]
> Sent: Sunday, June 05, 2011 8:45 AM
> To: amber.ambermd.org
> Subject: [AMBER] PMEMD does not support intermolecular PRFs
>
> Hi all,
>
> Perhaps someone could provide some advice on the following issue. I've
> only come across one instance of this on the mailing list and, as far
> as I can see, the issue wasn't resolved. I'll try to briefly explain.
> I'm running some MD simulations. The protocol I'm intending to run is
> basically,5000steps solvent restrained minimization,7500steps full
> system minimization, 50ps heating MD (classical), 1ns classical
> equilibration MD, then switch to qmmm MD for 1ns equilibration and
> finally 10ns qmmm production... (equil and prod will be run longer, if
> necessary). Using the pmemd module of amber the mini1, mini2 and cmd1
> are successful, but the cmd2 fails with error 'PMEMD does not support
> intermolecular PRFs'. The issue I read previously on the mailing list
> mentioned input problems, but would the problem not arise in either the
> mini1, mini2 or cmd1 before this? An interesting point to note is the
> fact that this cmd2 job runs using sander. Both pmemd and sander use
> the same input files (*.prmtop, *.in and *.inpcrd/*.rst). Also, both
> sander and pmemd are run using the *.MPI version.
>
> Here is the input file for the cmd2 job:
>
> #title
> &cntrl
> imin=0, irest=1, ntx=5,
> ntb=2, ntp=1,
> taup=2.0,
> cut =12.0,
> ntc=2, ntf=2,
> tempi=300.0, temp0=300.00,
> ntt=3, gamma_ln=2.0,
> nstlim=500000, dt =0.001,
> ntpr=5000, ntwx=5000, ntwr=5000,
> /
>
> Is the protocol and input file reasonable? Why does the pmemd job, but
> not the sander job fail? If the pmemd job fails, how reliable is the
> sander job? Could anyone provide any advice on the pmemd issue, as 1)
> my other simulations are run using pmemd, and 2) of, course, we see the
> large speed up!
>
> Thanking you in advance.
>
> Maura
> _______________________________________________
> 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 Mon Jun 06 2011 - 08:30:02 PDT
Custom Search