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