Fortran programs start counting at 1, not at 0. So without looking at the
procheck source code I would not be surprised to see the residue number as
a multiplier or e.g. a flag in an if-condition which leads to this
behaviour.
I could reproduce the very same behaviour, by the way.
Cheers, Tim
--
Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen
GPG Key ID = A46BEE1A
On Sat, 29 Dec 2007, Engin Ozkan wrote:
> Hi, CCP4bb'ers,
>
> I am having some trouble with Procheck. I am using two different
> installations, one that came with CCP4-6.0.2 and the other is procheck 3.5.4
> (I think they are the same versions).
> Anyway, I can reproducibly get the .out file to correctly report many bad
> contacts; however, the .sum file, which is what most of us quickly checks,
> always reports zero bad contacts with certain (CNS-type) pdb files. After a
> gazillion test runs with procheck, I figured out that all I need is to have
> the first residue number to be '0' to get a false report of zero bad contacts
> in the .sum file.
>
> All I do is, add this line as the first line in the pdb (presence or absence
> of REMARKS makes no difference):
> ATOM 1 C GLY A 0 27.769 17.185 79.547 1.00186.88 A
> and I get a report of zero bad contacts no matter what the rest of the file
> is. If I make the first residue number '1', .sum report is accurate. And it
> doesn't matter having/not having overlapping atom numbers in the pdb, either.
> Coordinates also do not matter. I went back to files from another project,
> and changing the first residue number to '0' in an unrelated file resulted in
> the same outcome/bug. Just adding that line above, does not make it for the
> unrelated pdb, however.
>
> The question is: Is this possible, and can anyone reproduce it, or have I
> gone completely mad?
>
> Happy holidays,
>
> Engin
>
> P.S. Another issue I observed before with procheck was, I think, that MSE
> (selenomethionine) was giving bad contacts with the neighboring residues (not
> with the neighboring main chain atoms, but the ones after them - not exactly
> sure, though).
|