 |
 |
OK yes it's Phaser: the version you are using is not writing the correct CCP4 space group number in the MTZ header (i.e. the one listed in syminfo.lib), which will confuse many downstream programs using the CCP4 symmetry library. Phaser is using the space group number shown in ITC-A, but that does not distinguish alternate settings. This will clearly also affect other alternate settings. Presumably that's an old version you're using, my understanding is that's been fixed: could the Phaser developers clarify this? But even so I thought we had moved away from using the CCP4 SG number to using either the space group name (which would be my preference), or the general equivalent positions to recognise the space group (indeed for this very reason!). Could someone in the CCP4 development team clarify this? Cheers -- Ian On 4 November 2016 at 15:23, Paul Paukstelis <[log in to unmask]> wrote: > Ian, > > I think I found the issue just by looking through mtzdmp output, but there > was a clue from the response I got yesterday: > > Hi Paul, > > I have come across this problem before, suddenly what was complete data is > only 50% complete. I seem to recall its because I2 is also called space > group 5 (same as C2), which confuses some programs. > > I tracked spacegroup number in the mtz headers. Pointless, aimless, > ctruncate use 4005 for I2. After Phaser (v 2.5.7), the spacegroup number is > just 5. That seemed to be the thing that is bothering refmac and > phenix.refine. For whatever reason I was using the phaser output for the > initial refinement. > > --paul > > > > On 11/04/2016 10:58 AM, Ian Tickle wrote: > > > Paul, mtzdump may not give the full header. The best way to get this is > to use a text editor on the MTZ file (yes I know it looks like garbage!), > scroll to the end where you will find the header starting at 'VERS > MTZ:V1.1'. Then copy/paste everything from there to the end (don't worry > about formatting it). > > Hopefully this will give a clue. > > Cheers > > -- Ian > > > On 4 November 2016 at 14:49, Ian Tickle <[log in to unmask]> wrote: > >> >> Hi Paul >> >> I just tried Refmac 5.8.0135 (which must be very similar to the version >> you are using) with an I2 dataset and I don't see this "conversion to C2". >> I doubt very much that the refinement programs need to convert to C2: I'm >> pretty sure they can do the refinement perfectly well in I2. >> >> I think it's much more likely that your MTZ header has somehow got >> corrupted with inconsistent space group info so you need to track back in >> the history list in the MTZ header and see which program was responsible >> for the corruption. Can you post the MTZ header so we can see the history >> list and the cell/space group info? >> >> Cheers >> >> -- Ian >> >> >> On 4 November 2016 at 14:39, Paul Paukstelis <[log in to unmask]> >> wrote: >> >>> Refmac and phenix.refine versions I used both seem to be problematic. >>> Both are I2 in and C2 out. >>> >>> --p >>> >>> On 11/04/2016 08:25 AM, Ian Tickle wrote: >>> >>> >>> Hi Paul >>> >>> This sounds like there might be a recently-introduced bug which should >>> be reported to the author. I have several structures in I2 & I haven't >>> noticed anything like this. Can you tell which program is introducing this >>> error, e.g. by looking at the mtzdump outputs? >>> >>> Cheers >>> >>> -- Ian >>> >>> >>> On 4 November 2016 at 12:00, Paul Paukstelis <[log in to unmask]> >>> wrote: >>> >>>> Thanks to all that responded. I sorted this out. >>>> >>>> It all appears to stem from the C2->I2 conversion. Forcing everything >>>> in processing to stick with C2 fixes all the issues! >>>> >>>> >>>> Thanks again, >>>> >>>> --paul >>>> >>>> >>>> >>>> On 11/03/2016 12:39 PM, Paul Paukstelis wrote: >>>> >>>>> CCP4BB, >>>>> >>>>> I posted some time back about a DNA oligonucleotide structure we were >>>>> working on. I had difficulty phasing it despite strong signal from >>>>> bromines, but finally managed to get reasonable enough maps from a few >>>>> datasets to build, only to find that despite the density looking quite >>>>> good, it simply wouldn't refine past R/Rfree of around 28/32. With help >>>>> from ccp4bb it began to become clear that this might be a candidate for a >>>>> lattice with translocation defects. >>>>> >>>>> I had my student make a variant in which two 3' nucleotides that >>>>> weren't involved in base pairing contacts were removed. This crystallized >>>>> under the same conditions in a different space group and was now >>>>> diffracting to ~1.0 A (from about 2.2 in the previous space group). Images >>>>> overall looked good, though we collected on some crystals that clearly had >>>>> more than one lattice that made indexing more difficult. The best looking >>>>> data still had some tails on spots, but was easily indexed in C2, which >>>>> Pointless quite happily changed to I2 to minimize the beta angle. There are >>>>> no clear alternating strong/weak intensities. Phaser finds a strong >>>>> solution using the previously built dimer, but notes a 25% over origin peak >>>>> in native Patterson. Maps look very good, though after the first round of >>>>> refinement it is apparent that there is another dimer in the ASU, but it is >>>>> clearly overlapping the first. If I'm not mistaken, all these clues suggest >>>>> lattice translocation defects. Question 1: any thoughts on how likely it >>>>> would be for a molecule to intrinsically pack in such a way that it results >>>>> in lattice translocation defects? >>>>> >>>>> I thought it would be worthwhile pressing on given the high resolution >>>>> it would be possible to do grouped occupancy refinement of the dimers >>>>> without taking too huge a hit in observation/parameters. Refinement with >>>>> refmac using occupancy groups leads to a best R/Rfree of 18/24, though >>>>> geometry could be better in some spots. Curiously, refmac (or >>>>> phenix.refine) in the PDB header reports only 50% completeness in the >>>>> resolution range, though all the data reduction and analysis (aimless, >>>>> xtriage) report 99% completeness. Question 2: Why is this? Phenix logfile >>>>> says something about removing about half the reflections as systematic >>>>> absences. I have been working with everything in I2 after Pointless >>>>> switched it over. >>>>> >>>>> Question 3: Any other suggestions on how to proceed with refinement in >>>>> a case like this? My gut instinct tells me that it would be better to not >>>>> do intensity correction due to the high resolution, but perhaps that's >>>>> something to pursue? >>>>> >>>>> Thank you in advance. >>>>> >>>>> --paul >>>>> >>>> >>> >>> >> > >