-----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-----
|