Ok, this advice is very helpful and insightful, but based on the results
I am not yet totally confident in the connectivity information of the new
prmtop file.
I followed your analysis below and I tried putting the FS4 cluster in
different places -- just before or just after the protein, or in the middle
(e.g. next to one of the ligand cyx groups). Putting the FS4 in the middle
of the protein seems to cause xleap to disconnect the protein backbone,
which makes some sense, given your comment below. It seems to work
best if I order the input pdb file as:
protein
TER card
FS4
TER card
DNA strand 1
TER card
DNA strand 2
TER
waters etc.
CONECT cards (which connect each of the FS4 Fe atoms to the ligands)
The TER card before FS4 is necessary in order to get xleap to figure out
that the terminal protein residue is, in fact, terminal.
Then things almost work: According to xleap, the connectivity of the
molecules look fine. If I solvate and write new prmcrd and prmtop files,
then the prmtop file now has the correct sequence of integers in the
ATOMS_PER_MOLECULE section. Using ambpdb with these prmcrd
and prmtop files to write a recovered pdb, I find the following ordering
in the new pdb file:
protein
FS4
TER card
etc
which means that if I load the ambpdb-generated pdb file back into xleap,
the interpreted connectivity is not quite right. [The terminal protein
group
is not correctly identified (SER instead of CSER) and the OXT group of
this residue is not bonded to anything at all. Moreover the FS4 group is
not connected to the protein. Analogous problems arise if I instead put the
FS4 group in front of the protein, in the initial pdb file.] But this
issue is
simply an inconvenience and I'm willing to work around it for the moment.
More importantly, I feel I have lost a diagnostic into the integrity of the
prmtop file. The prmtop is what is ultimately used for simulations so this
file needs to be correct. The initial issue I described in this thread
seemed
to indicate that xleap might show correct connectivity but then write a
corresponding prmtop file that is not quite correct.
Is there a way that I can check the prmtop file directly to see that the
molecule
connectivity is correct? Or, if this is not possible, should I simply
trust the
xleap diagnostics for this case?
(updated pdb and top files have been posted)
Sam
David A. Case wrote:
>On Tue, Dec 27, 2005, Sam wrote:
>
>
>>Indeed, it turns out that the ambpdb-misplacement of TER card
>>only happens after I have solvated the structure. Curious.. This
>>is independent of whether or not I have added K+ ions to the
>>structure (or in which order I do these two steps).
>>
>>
>
>Here is what I think is a resolution of this problem:
>
>First, it is not a bug with ambpdb: the prmtop file is wrong. Look for the
>section labelled ATOMS_PER_MOLECULE, and you will see that the information is
>not quite right there. ambpdb uses this information to put in TER cards.
>[The reason things "work" without solvation is that LEaP only creates
>molecule information for periodic simulations. So for non-periodic stuff,
>ambpdb has to figure out what the molecules are on its own, and it does that
>correctly.]
>
>Second, the problem arises from the FS4 group. Because of the CONECT records
>at the bottom of the pdb file, LEaP is (correctly) treating the FS4 group as a
>part of the first molecule (the protein). But it doesn't know how to put the
>FS4 coordinates up with the first molecule. This is not going to be easy to
>fix in general, but here is the workaround:
>
>Move the HETATM records of the FS4 group (in the protein.pdb file) to the top
>of the file (either before or after the protein). I think the CONECT records
>will all still work correctly, but please double check the connectivities
>(e.g.: I get the FE4 should be bonded to CYS 214 -- make sure that is
>correct.) Then you should be able to use the other commands you have already
>been using.
>
>Basically, each "molecule" needs to have contiguous coordinates in the input
>pdb file. Having the DNA strands in between the protein and its covalently
>linked atoms confuses LEaP. It is unlikely that this restriction will go away
>any time soon. The notion that each molecule has contiguous coordinates
>is pretty deeply embedded into the Amber codes; but we might be able to at
>least get LEaP to check for violations of this requirement and to issue an
>error message; but that is all for the future.
>
>...thanks for the report....dac
>
>-----------------------------------------------------------------------
>The AMBER Mail Reflector
>To post, send mail to amber.scripps.edu
>To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
>
>
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Wed Jan 04 2006 - 18:17:01 PST
