[phenixbb] "H" atom refining occupancy with previous altconf residue in sequence

Nathaniel Echols nechols at lbl.gov
Fri Oct 26 11:39:20 PDT 2012

On Thu, Oct 25, 2012 at 8:05 PM, Alexander Scouras <scouras at berkeley.edu> wrote:
> After a series of residues (1+) with alternate conformations, the H atom of the next residue seems to lock its occupancy to that of the final conformation of the previous residue.  Hence I'm getting several H's with 0.1-0.5 occupancy on single conformation residues, where the entire rest of the residue has occupancy 1.  This happens after every altconf series, and showed up in two separate structures I've worked on this week.
> Within a series of 2+ residues with altconfs, the H's refine correctly with their altconf groups.  So it isn't just that all subsequent residue's H's are getting overridden.
> This behavior seems to have started with 1.8.1-1168, or at least previous refinements of the same structure didn't do this.  64 bit build on Retina MBP running OS X 10.8.2.
> I couldn't google any reference to this behavior, so assuming it's a new bug I can send along source files.

Very interesting - this is also reproducible with a simple test case
and the latest code.  Judging from the revision history, it looks like
this probably would have happened with version 1.8 too.  I am not
entirely sure what the code is doing, but I think it is partly based
on the assumption that if you have an alternate conformation for the C
and/or CA atoms of a residue, the H atom for the next residue will
also have alternate conformations.  This is in fact what
phenix.ready_set will do - if you re-run it on your input PDB file,
you will have A/B/C conformations for Met30 H.  So I'm inclined to
suggest simply doing this (it is the most chemically sensible
approach), but the behavior of phenix.refine when no alternate
conformer is present for H does appear to be a bug.


More information about the phenixbb mailing list