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 <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

Reply via email to