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 : [log in to unmask]
Date : 23/07/2014 - 16:20 (GMTDT)
To : [log in to unmask]
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
   *   ***      [log in to unmask]
  ***     *
   *   *** 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:[log in to unmask]] Sent: Mittwoch, 23. Juli 2014
>> 15:38 To: [log in to unmask]; [log in to unmask] 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:
>>> [log in to unmask] 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
>>
>>> [log in to unmask]
>>
>>> [log in to unmask]
>>
>>> 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-----
>