It seems this happens at the level of the refinement programs. Both seem 
to convert to C2, but use the I2 cell parameters. They are somewhat 
older versions, so perhaps it is an old bug and not a new one? I've 
confirmed that the input mtz I used for both refmac and phenix.refine 
was in I2 with the appropriate cell parameters. Here are the versions 
and relevant log output:

Refmac 5.8.0124:

Cell from mtz :    25.970    46.960    35.974    90.000 101.152    90.000
Space group from mtz: number -    5; name - C 1 2 1

phenix.refine  1.9.1692:

Working crystal symmetry after inspecting all inputs:
   Unit cell: (25.97, 46.96, 35.9742, 90, 101.152, 90)
   Space group: C 1 2 1 (No. 5)
Removing 9971 systematic absences:
   Average absolute value of:
     Absences: 12548.1
       Others: 12340.5
        Ratio: 1.01683

Other versions of programs used:
Phaser 2.5.7
Pointless 1.9.33
Aimless 0.5.12

C2 cell: 40.08   46.97   25.98        90  118.27      90


--paul

On 11/04/2016 08:05 AM, Phil Evans wrote:
> Where does this problem arise? I was under the impression that I2 was acceptable everywhere (which is why Pointless follows the IUCr guidelines in preferring I2 over C2 if the beta angle is smaller)
>
> Everything should work in I2: if it doesn’t it’s a bug (similarly with space groups such as P 2 21 21 with a<b<c)
>
> Phil
>
>
>> On 4 Nov 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