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 <ianj...@gmail.com> 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 <shocksofmig...@gmail.com> > 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 <shocksofmig...@gmail.com> >> 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 >>>> >>> >> >> >
