I think there has been historically some glitch in the deposition of some
refmac altloc waters
So for example 4a9x from Buster is annotated correctly
REMARK 3 PROGRAM : BUSTER 2.11.2
HETATM 9407 O HOH A2517 -22.429 1.144 -35.218 1.00 29.73 O
HETATM 9408 O AHOH A2518 -18.933 -9.507 -28.753 0.50 3.00 O
HETATM 9409 O BHOH A2518 -20.467 -9.093 -29.900 0.50 16.03 O
so the A and B altloc retained.
But
for example in 4ac7
REMARK 3 PROGRAM : REFMAC 5.6.0117
where these two waters look like they originally were deposited as altloc waters
HETATM 6205 O HOH A2043 -3.612 86.934 100.843 0.50 25.12 O
ANISOU 6205 O HOH A2043 2630 2166 4747 -153 68 1496 O
HETATM 6206 O HOH A2044 -3.506 85.122 100.190 0.50 22.20 O
ANISOU 6206 O HOH A2044 3710 2476 2248 862 188 16 O
and these two
HETATM 6328 O HOH B2073 -1.182 117.989 73.544 0.50 15.63 O
ANISOU 6328 O HOH B2073 2509 1684 1745 408 173 289 O
HETATM 6329 O HOH B2074 -0.561 117.641 72.161 0.50 14.37 O
ANISOU 6329 O HOH B2074 2023 1187 2247 107 123 -211 O
These waters also end up being annotated as close contacts in Remark 500 -
which would not have happened if they had retained their altlocs.
REMARK 500 THE FOLLOWING ATOMS ARE IN CLOSE CONTACT.
...
REMARK 500 O HOH A 2043 O HOH A 2044 1.93
REMARK 500 O HOH B 2073 O HOH B 2074 1.56
Probably other examples can be retrieved but this latter file dates from my
time at the PDBe and so may have been mangled at my hands.
In my defence I think it is owing to the annotation step when the waters are
renumbered to fit with the associated macromolecule N to C (for proteins). I
think the script that was originally developed for this was not able to deal
with waters with the same number but differing altlocs. Also alternate
positions in this step can be associated with different residues by reason of
being closer to one or other bit of chain. In this case they can have very
different numbers - or chains.
I think this can be handled better in the new mmCif-based annotation system
with the cooperation of refinement program authors.
all the best
Martyn
Martyn Symmons
Cambridge
----Original message----
>From : f...@bernstein-plus-sons.com
Date : 23/07/2014 - 16:20 (GMTDT)
To : CCP4BB@JISCMAIL.AC.UK
Subject : Re: [ccp4bb] correlated alternate confs - validation?
I agree that it would be excellent to be able to associate
alternate conformations (beyond the individual residue) but
when we defined the "PDB" format we had an 80-column limitation
per atom and so only one column was allowed for alternate
conformations. In an ASCII world only 36 characters were available
to define alternate conformations. This is inadequate to allow
for many residues with independent alternate conformations -
one residue with three conformations would use up 3 of the 36
characters. Thus there was no way to say that alternate
conformation A in one residue is or is not associated with
alternate conformation A in another residue.
Frances
=====================================================
**** Bernstein + Sons
* * Information Systems Consultants
**** 5 Brewster Lane, Bellport, NY 11713-2803
* * ***
**** * Frances C. Bernstein
* *** f...@bernstein-plus-sons.com
*** *
* *** 1-631-286-1339 FAX: 1-631-286-1999
=====================================================
On Wed, 23 Jul 2014, Tim Gruene wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Bernhard,
>
> That's right, the definition is not in the PDB, but REFMAC sensibly
> handles it this way. It is certainly a short-coming if not bug in the
> PDB (definition).
>
> Best,
> Tim
>
> On 07/23/2014 04:49 PM, Bernhard Rupp wrote:
>> ?? Refmac knows because of the group definition, otherwise I cannot
>> force grouped occupancy refinement. There is no definition in PDB
>> that eg ALTLOC A (of whatever residue) belongs to ALTLOC A of
>> (whatever) residue/water.
>>
>> BR
>>
>> -----Original Message----- From: Tim Gruene
>> [mailto:t...@shelx.uni-ac.gwdg.de] Sent: Mittwoch, 23. Juli 2014
>> 15:38 To: b...@hofkristallamt.org; CCP4BB@JISCMAIL.AC.UK Subject: Re:
>> [ccp4bb] correlated alternate confs - validation?
>>
>> Hi Bernhard,
>>
>> do you refer to the PDB who, according to Martyn, remove the altloc
>> indicator? That's certainly a serious bug that should be fixed as
>> quickly as possible.
>>
>> Within refmac the preservation is fine and as you would expect it
>> to be: altA only sees atoms in altA and those witout altLoc, etc,
>> which makes sure you PDB file is interpreted correctly by refmac5.
>> That's how I refmac works.
>>
>> Best, Tim
>>
>> On 07/23/2014 03:26 PM, Bernhard Rupp wrote:
>>>> I would probably make the two waters alternates of each other.
>>
>>
>>
>>> Quite possible, but the group definition, i.e. to which alt
>>> conf. side chain they belong,
>>
>>> would need to be preserved, too.
>>
>>
>>
>>> BR
>>
>>
>>
>>
>>
>>> Cheers, Robbie
>>
>>> Sent from my Windows Phone
>>
>>> _____
>>
>>> Van: Bernhard Rupp Verzonden: 23-7-2014 10:19 Aan:
>>> CCP4BB@JISCMAIL.AC.UK Onderwerp: [ccp4bb] correlated alternate
>>> confs - validation?
>>
>>> Hi Fellows,
>>
>>
>>
>>> something that may eventually become an issue for validation and
>>> reporting in PDB headers:
>>
>>
>>
>>> using the Refmac grouped occupancy keyword I was able to form and
>>> refine various networks of correlated
>>
>>> alternate conformations - it seems to works really well at least
>>> in a 1.6 and 1.2 A case I tried.
>>
>>> Both occupancy and B-factors refine to reasonable values as
>>> expected/guessed from e-density and environment.
>>
>>> Respect & thanks for implementing this probably underutilized
>>> secret.
>>
>>
>>
>>> This opens a question for validation: Instead of pretty much
>>> ignoring any atoms below occupancy of 1, one
>>
>>> can now validate each of the network groups geometry and density
>>> fit separately just as any other
>>
>>> set of coordinates. I think with increasing data quality,
>>> resolution, and user education such refinements will become more
>>
>>> frequent (and make a lot more sense than arbitrarily setting
>>> guessed independent hard occupancies/Bs
>>
>>> that are not validated). Maybe some common format for
>>> (annotating) such correlated occupancy groups might
>>
>>> eventually become necessary.
>>
>>
>>
>>> Best, BR
>>
>>
>>
>>> PS: Simple example shown below: two alternate confs of residue
>>> 338 which correlate with one
>>
>>> water atom each in chain B, with corresponding partial occupancy
>>> (grp1: A338A-B5 ~0.6, grp2: A338B-B16 ~0.4).
>>
>>
>>
>>> occupancy group id 1 chain A residue 338 alt A
>>
>>> occupancy group id 1 chain B residue 5
>>
>>> occupancy group id 2 chain A residue 338 alt B
>>
>>> occupancy group id 2 chain B residue 16
>>
>>> occupancy group alts complete 1 2
>>
>>> . more similar
>>
>>> occupancy refine
>>
>>
>>
>>> AfaIct this does what I want. True?
>>
>>
>>
>>> ----------------------------------------------------------------------
>>>
>>>
> - ------------------
>>
>>> Bernhard Rupp
>>
>>> k.-k. Hofkristallamt
>>
>>> 001 (925) 209-7429
>>
>>> b...@ruppweb.org
>>
>>> b...@hofkristallamt.org
>>
>>> http://www.ruppweb.org/
>>
>>> ----------------------------------------------------------------------
>>>
>>>
> - -
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> - --
> - --
> Dr Tim Gruene
> Institut fuer anorganische Chemie
> Tammannstr. 4
> D-37077 Goettingen
>
> GPG Key ID = A46BEE1A
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>
> iD8DBQFTz85KUxlJ7aRr7hoRAoeqAKCGBTg8nowXCCFfbp9kfZsCYr2fHgCgoJhp
> CPPMzM1r6DEZv2DJi4vwXmI=
> =bMXr
> -----END PGP SIGNATURE-----
>
