I was wondering if something like that was the idea, though I guess I might have expected the main chain nitrogen to also get an alternate conformation. Hydrogens are just second class atoms I guess, and that dihedral would be more important than actually moving the N. When running iterative refinement between Phenix and Coot, adding altconfs as they come up, should you regularly be running ready_set (or anything else) after? I always just save the coordinates and then load that pdb in the next round of phenix.refine. It looks like my previous refinements of these structures were using the 1.7 branch, so it could have been introduced in 1.8.0 indeed. Running phenix.ready_set did not initially correct the hydrogens, probably because it didn't know what to do with hydrogens in partial occupancies. It worked fine after I removed all hydrogens from the structure though. On Oct 26, 2012, at 11:39 AM, Nathaniel Echols wrote:

On Thu, Oct 25, 2012 at 8:05 PM, Alexander Scouras 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.

-Nat _______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

Sorry for not getting back to you sooner. I'm working at better than 1.0A resolution for some structures, so am able to determine histidine protonation state in some cases. So yes, I turned off the automatic hydrogen additions. Now that I understand the behavior, I can work with it. Clearing up the histidines can wait until the end of refinement, after I've worked out the altconfs anyway. Jeff: If you still want my refinement history, I can send it along, but it sounds like (according to Pavel) this is the expected behavior and I just need to change my refinement routine a little bit. On Oct 26, 2012, at 1:20 PM, Nathaniel Echols wrote:

On Fri, Oct 26, 2012 at 1:06 PM, Alexander Scouras wrote:

...

I was wondering if something like that was the idea, though I guess I might have expected the main chain nitrogen to also get an alternate conformation. Hydrogens are just second class atoms I guess, and that dihedral would be more important than actually moving the N.

When running iterative refinement between Phenix and Coot, adding altconfs as they come up, should you regularly be running ready_set (or anything else) after? I always just save the coordinates and then load that pdb in the next round of phenix.refine.

I would continually run phenix.ready_set in this case - actually, if you're using the phenix.refine GUI I think you can just click "Automatically add hydrogens to model" and everything else will be done automatically. (If not, that's a bug too!) Unless you are performing neutron refinement or some very specialized high-resolution enzymology, it is unlikely that you will actually care about preserving the hydrogen positions from round to round anyway.

-Nat _______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

Hi, I did not look closely yet but my understanding is that its position is dictated by the next to it residue that has non-blank altlocs, and therefore this hydrogen inherits the conformers. So this behavior is expected. I hoped Jeff will comment on this as he was the first who explained it to me. Pavel On 10/26/12 11:39 AM, Nathaniel Echols 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

On Thu, Oct 25, 2012 at 8:05 PM, Alexander Scouras wrote: 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.

-Nat _______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

The current behavior is intended one and asserted by regression test: phenix_regression/refinement/tst_refinement_occ_of_h3.py If you remove hydrogens from that PDB file, and then add them back, Reduce will add H on MET30, and its occupancy will be inherited from atoms in MET29 that define its position. phenix.refine in turn will pick up that for occupancy refinement according it its default behavior. Jeff: the occupancy of H in MET30 does match the occupancy of relevant atoms in preceding residue (MET29). I verified this with this specific example, and also this is asserted in the above test. We discussed this multiple times in the past and current behavior is the consensus one. If this is not what we want then we need to fix Reduce. Pavel On 10/26/12 1:17 PM, Nathaniel Echols wrote:

On Fri, Oct 26, 2012 at 1:07 PM, Pavel Afonine wrote:

...

I did not look closely yet but my understanding is that its position is dictated by the next to it residue that has non-blank altlocs, and therefore this hydrogen inherits the conformers. So this behavior is expected. I hoped Jeff will comment on this as he was the first who explained it to me. This explains the behavior of phenix.ready_set, but not the change to occupancy made by phenix.refine.

-Nat _______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb