- phenixbb - phenix-online.org

Phenix version 1.6.1 released
by Paul Adams 31 Mar '10

31 Mar '10

The Phenix developers are pleased to announce that version 1.6.1 of Phenix is now available. Binary installers for Linux, and Mac OSX platforms are available at the download site: http://phenix-online.org/download/ Just some of the new features in this version (1.6.1) are: - Fast automated rotamer fixing in phenix.refine - Use of atomic charge in calculation of scattering factors - New Graphical User Interfaces for phenix.superpose_pdbs, phenix.get_cc_mtz_mtz, phenix.get_cc_mtz_pdb, and phenix.fmodel - Consolidated validation tool in GUI - New map calculation tool, phenix.maps (also used in GUI) - Rapid loading of structures in GUI selection editor - Improved geometry restraints to maintain amino acid rotameric states - Alpha version of secondary structure restraints - Automated secondary structure analysis with KSDSSP (code from UCSF CGL) For a full list of changes see: http://www.phenix-online.org/documentation/CHANGES Please note that there is a new publication that should be used to cite use of Phenix: PHENIX: a comprehensive Python-based system for macromolecular structure solution. P. D. Adams, P. V. Afonine, G. Bunkóczi, V. B. Chen, I. W. Davis, N. Echols, J. J. Headd, L.-W. Hung, G. J. Kapral, R. W. Grosse-Kunstleve, A. J. McCoy, N. W. Moriarty, R. Oeffner, R. J. Read, D. C. Richardson, J. S. Richardson, T. C. Terwilliger and P. H. Zwart. Acta Cryst. D66, 213-221 (2010). Full documentation is available here: http://www.phenix-online.org/documentation/ There is a Phenix bulletin board: http://www.phenix-online.org/mailman/listinfo/phenixbb/ Please consult the installer README file or online documentation for installation instructions. Direct questions and problem reports to the bulletin board or: help(a)phenix-online.org and bugs(a)phenix-online.org Commercial users interested in obtaining access to Phenix should visit the Phenix website for information about the Phenix Industrial Consortium. The development of Phenix is principally funded by the National Institute of General Medical Sciences (NIH) under grant P01-GM063210. We also acknowledge the generous support of the members of the Phenix Industrial Consortium. -- Paul Adams Acting Division Director, Physical Biosciences Division, Lawrence Berkeley Lab Adjunct Professor, Department of Bioengineering, U.C. Berkeley Vice President for Technology, the Joint BioEnergy Institute Head, Berkeley Center for Structural Biology Building 64, Room 248 Tel: 1-510-486-4225, Fax: 1-510-486-5909 http://cci.lbl.gov/paul Lawrence Berkeley Laboratory 1 Cyclotron Road BLDG 64R0121 Berkeley, CA 94720, USA. Executive Assistant: Patty Jimenez [ PAJimenez(a)lbl.gov ] [ 1-510-486-7963 ] --

1 0

Re: [phenixbb] Citation for xtriage
by Folmer Fredslund 30 Mar '10

30 Mar '10

Dear Mark, On 30 March 2010 19:30, Dr. Mark Mayer <mayerm(a)mail.nih.gov> wrote: > > I'm writing up some results for which we used phenix.xtriage to screen xtals > for twin fraction and would like to know if there is a paper we could/should > cite? > > At the time this work was done we were not using the rest of the phenix > suite for refinement (we are now!). > Going to the phenix FAQS (http://www.phenix-online.org/documentation/faqs.htm#anch2) it would be PHENIX: a comprehensive Python-based system for macromolecular structure solution. P. D. Adams, P. V. Afonine, G. Bunkóczi, V. B. Chen, I. W. Davis, N. Echoo ls, J. J. Headd, L.-W. Hung, G. J. Kapral, R. W. Grosse-Kunstleve, A. J. McCoy, N. W. Moriarty, R. Oeffner, R. J. Read, D. C. Richardson, J. S. Richardson, T. C. Terwilliger and P. H. Zwart. Acta Cryst. D66, 213-221 (2010). Or maybe the developers prefer you cite the CCP4 newletters listed at: http://www.phenix-online.org/documentation/xtriage.htm#anch24 Hope this helps, Folmer Fredslund

1 0

Citation for xtriage
by Dr. Mark Mayer 30 Mar '10

30 Mar '10

I'm writing up some results for which we used phenix.xtriage to screen xtals for twin fraction and would like to know if there is a paper we could/should cite? At the time this work was done we were not using the rest of the phenix suite for refinement (we are now!). Thanks, Mark --

1 0

shaking a PDB without introducing clashes
by Francois Berenger 30 Mar '10

30 Mar '10

Hello, I recently used "phenix.pdbtools modify.sites.shake=..." in order to have some data from 0.1 to 5A. away from the true structure in order to test some scripts. I think this introduced clashes in the "shaken" PDBs I got. Is there a tool/way to avoid this? Best regards, Francois.

4 5

RMSD Dihedrals
by J. Fleming 30 Mar '10

30 Mar '10

Hi all, I'm working on a ~3 angstrom structure of a protein with approximately 800 residues. The structure is mostly helical with interspersed turns. I've been using Phenix exclusively for the refinements and have a model that I believe to be pretty good with the exception of the dihedrals (see attached). I've looked at and employed some of the general suggestions for low resolution structures here: http://strucbio.biologie.uni-konstanz.de/ccp4wiki/index.php/Refinement#Refi… I tried using "discard_psi_phi=False" but it only resulted in a change dihedrals of +0.10 with minimal changes to Ramachandran outliers. I'm unsure how to proceed and would love to hear any thoughts/opinions/suggestions. Thanks for all the help! -Jon

2 1

Re: [phenixbb] h_bonds restraints
by Maia Cherney 28 Mar '10

28 Mar '10

Hi Boaz, The problem is with the distance between 2 waters and not the Mg-water distance. These 2 waters belong to the Mg coordination, still they should be at a h_b distance from one another. I got around this problem by setting my custom restraints, but I think the program should take care of this. Maia Boaz Shaanan wrote: > Hi Maia, > > Can I make two comments concerning the distance restraints that you're > struggling with: > 1) I don't know the resolution your structure, nor do I know the way > Phenix treats the distance restraints internally, but I guess it's > similar to the way it is in CNS. That is, there is a value for the > restaint (2.1-2.2 A in your case) and there should be a number for the > tolerance of that distance (or its s.d.) which the user can decide on, > depending on the resolution. It is possible that Phenix is clever > enough to figure out this tolerance from the resolution and the > complete set of restraints, I'm not sure. > > 2) I wouldn't worry too much about the validation (as in fact Pavel > has alluded to). If your water molecules in the Mg+2 coordination > sphere "insist" on being closer to the metal than you expect, despite > all your efforts, then this is it. The RCSBpeople and validation > process should know about standard and deviation and resolution. In > the worst case your deposited structure will have a comment/remark put > in your deposited PDB saying perhaps that the Mg-water distances are > shorter by that much from the norm. > > That's my 2p worth thought. > > Cheers, > > Boaz > > ----- Original Message ----- > From: Maia Cherney <chern(a)ualberta.ca> > Date: Sunday, March 28, 2010 14:14 > Subject: Re: [phenixbb] h_bonds restraints > To: PHENIX user mailing list <phenixbb(a)phenix-online.org> > > > Hi Pavel, > > > > I have waters that are part of the Mg2+ coordination. They > > should be at > > ~2.1A from Mg2+. At the same time, they should be at a hydrogen- > > bonding > > distance from each other (minimum 2.2A otherwise the validation > > at the > > PDB complains). The two waters after refinement without > > restraints had > > closer (2.12A) distance between them, so I managed to restrain > > the > > distance to 2.23A using pdb_interpretation. But my question was, > > should > > not the refinement automatically restrain close distances > > between any > > atoms, including waters? (By the way, I picked them manually). > > > > Maia > > > > Pavel Afonine wrote: > > > Hi Maia, > > > > > > I'm not sure I understand the question. If you have that > > specific > > > water in your structure already (and you run phenix.refine > > with > > > "ordered_solvent=false"), then changing the > > h_bond_min_mac or > > > h_bond_min_sol will not change anything since these parameters > > are > > > used in water update. > > > > > > However, if you are at the stage of water picking and the > > distance > > > between Mg2+ and prospective water peak is 2.2A then the water > > will be > > > placed there (providing that the corresponding peak satisfies > > the > > > other criteria). > > > > > > Could you please explain what exactly the problem is, and then > > I will > > > try my best to give you the solution? > > > > > > Thanks! > > > Pavel. > > > > > > > > > On 3/27/10 5:23 PM, Maia Cherney wrote: > > >> Hi Pavel, > > >> what is h_bond_min_mac and h_bond_min_sol. > > >> > > >> which one should I change to 2.2 so that it will not affect > > the > > >> coordination distances of Mg2+ (around 2A)? > > >> > > >> Maia > > >> > > >> Pavel Afonine wrote: > > >>> Hi Maia, > > >>> > > >>>> I have done the things that you suggested, > > >>> > > >>> great! > > >>> > > >>>> and I have all the restraints for the Mg2+ and I see those > > 2 > > >>>> waters, but they are at 2.12A distance. > > >>> > > >>> Are these two waters located in the centers of corresponding > > density > > >>> peaks? If this is the case then I don't see the subject of > > your > > >>> worries. If this is not the case (these waters are off the > > peaks) > > >>> then edit the file that defines restraints for water-Mg2+ > > interactions.>>> > > >>>> I think there should be some general restraints that should > > keep > > >>>> h_bonds at least at > 2.2A. > > >>> > > >>> Yes. You wrote it yourself in your previous email: > > >>> > > >>> h_bond_min_mac = 1.8 > > >>> h_bond_min_sol = 1.8 > > >>> h_bond_max = 3.2 > > >>> > > >>> Just change the values to what you like! > > >>> > > >>>> That is why I asked you about those defaults (1.8A etc). > > Why are > > >>>> they at 1.8A? Should not they be at least at 2.2A? > > >>> > > >>> Honestly, I don't remember why I put these values (this is > > pretty > > >>> old code in phenix.refine that I wrote several years ago). > > All I > > >>> recall is that I had a reason for this. I probably need to > > run > > >>> through the whole PDB and see how the density peaks (actual, > > >>> residual, omit-residual) are distributed w.r.t. > > macromolecule, and > > >>> write it somewhere for the future reference. This could be a > > project > > >>> for a few weeks, but it will definitely yield a rock-solid > > >>> conclusion about "good" distances. Meanwhile feel free to > > edit the > > >>> available parameters. > > >>> > > >>> By the way, this is what CNS is using: > > >>> > > >>> {* minimum distance between water and any atom *} > > >>> {===>} min=2.6; > > >>> {* maximum distance between water and any atom *} > > >>> {===>} max=4.0; > > >>> > > >>> {* minimum hydrogen bonding distance between water and O or > > N *} > > >>> {===>} hmin=2.0; > > >>> {* maximum hydrogen bonding distance between water and O or > > N *} > > >>> {===>} hmax=3.2; > > >>> > > >>> Pavel. > > >>> > > >>> _______________________________________________ > > >>> phenixbb mailing list > > >>> phenixbb(a)phenix-online.org > > >>> http://phenix-online.org/mailman/listinfo/phenixbb > > >>> > > >>> > > >> _______________________________________________ > > >> phenixbb mailing list > > >> phenixbb(a)phenix-online.org > > >> http://phenix-online.org/mailman/listinfo/phenixbb > > > _______________________________________________ > > > phenixbb mailing list > > > phenixbb(a)phenix-online.org > > > http://phenix-online.org/mailman/listinfo/phenixbb > > > > > > > > _______________________________________________ > > phenixbb mailing list > > phenixbb(a)phenix-online.org > > http://phenix-online.org/mailman/listinfo/phenixbb > > > > > Boaz Shaanan, Ph.D. > Dept. of Life Sciences > Ben-Gurion University of the Negev > Beer-Sheva 84105 > Israel > Phone: 972-8-647-2220 ; Fax: 646-1710 > Skype: boaz.shaanan > > ‎

1 0

Re: [phenixbb] Twinning Refinement
by Eric Larson 28 Mar '10

28 Mar '10

Dear Joe, It is not uncommon for proteins to crystallize in different crystal forms when in complex with different substrates or inhibitors. Trust that the absurdly high R factors (38% in the lowest resolution shell!?!?) despite the great lengths you went through with error models, etc. and the fact that scalepack is trying to throw out 20% of your data is a hint that you may be in the wrong spacegroup. Also, most of your "systematic absences" have an I/sig >2.5 and so probably are not absent. Were the predictions falling on spots during integration? This may provide another clue. I think you need to go back to HKL and reprocess pretending that you don't know that the crystals are "well characterized". You may have a new crystal form. good luck, Eric __________________________ Eric Larson, PhD MSGPP Consortium Department of Biochemistry Box 357742 University of Washington Seattle, WA 98195 > Date: Fri, 26 Mar 2010 05:13:07 +0000 > From: Joseph Brock <joeylives2ride(a)hotmail.com> > To: <phenixbb(a)phenix-online.org> > Subject: [phenixbb] Twinning Refinement > Message-ID: <SNT120-W557FCF7E111C0FEA167769B230(a)phx.gbl> > Content-Type: text/plain; charset="iso-8859-1" > > Dear Phenix Users, > > I'm currently using version: > Version: 1.4 > Release tag: 3 > cctbx tag: 2008_12_07_1353 > Platform: mac-intel-osx osx-10.5.6 > > I am working on characterising substrate/inhibitor interactions of a protein, the structure has been solved many times so its unit cell dimensions, contents (1 molecule per ASU) and space group (P3121) are well characterized. > > However, I have recently encountered several crystals that appear exhibit merohedral twinning, and am having trouble converging the R-factors to reasonable levels. The details of one such data set is described below: > > Diffraction to ~1.9A was recorded using a high and low resolution pass of 180? each. When processed with HKL2000 separately or together, Scalepack wanted to reject huge amounts of my data (~20%). I was forced to increase the error scale factor to 2 and adjust my error model to the very high R-factors of the low-resolution shells. The summary table from my final round of scalepack is: > Shell Lower Upper Average Average Norm. Linear Square > limit Angstrom I error stat. Chi**2 R-fac R-fac > 50.00 4.09 7648.3 1498.7 182.7 1.030 0.376 0.424 > 4.09 3.25 3885.1 568.9 64.1 1.410 0.416 0.480 > 3.25 2.84 1609.7 225.0 26.1 1.227 0.451 0.517 > 2.84 2.58 807.9 97.1 25.3 1.958 0.439 0.561 > 2.58 2.39 496.6 59.7 22.0 1.060 0.257 0.268 > 2.39 2.25 335.5 53.0 18.1 0.717 0.275 0.238 > 2.25 2.14 221.7 19.0 17.4 2.389 0.354 0.298 > 2.14 2.05 143.1 19.5 17.5 1.537 0.459 0.351 > 2.05 1.97 87.0 20.2 17.1 1.079 0.663 0.480 > 1.97 1.90 54.6 20.3 16.7 1.073 0.990 0.696 > All reflections 1588.3 269.2 41.9 1.350 0.400 0.444 > > In addition, many systematic absences appear to be present: > > Intensities of systematic absences > h k l Intensity Sigma I/Sigma > > 0 0 5 177.7 56.7 3.1 > 0 0 7 255.5 70.6 3.6 > 0 0 8 264.8 73.2 3.6 > 0 0 10 595.0 164.2 3.6 > 0 0 11 2343.5 1289.9 1.8 > 0 0 13 321.3 125.4 2.6 > 0 0 14 66.5 21.8 3.1 > 0 0 16 238.0 76.3 3.1 > 0 0 17 394.3 109.1 3.6 > 0 0 19 13.0 7.1 1.8 > 0 0 20 650.1 179.5 3.6 > 0 0 22 199.6 55.6 3.6 > 0 0 23 953.9 372.0 2.6 > 0 0 25 192.2 62.2 3.1 > 0 0 26 1038.7 405.0 2.6 > 0 0 28 96.3 28.9 3.3 > 0 0 29 2303.0 897.0 2.6 > 0 0 31 12.0 11.5 1.0 > 0 0 32 1622.4 516.5 3.1 > 0 0 34 11.5 13.8 0.8 > 0 0 35 22.8 14.8 1.5 > 0 0 37 27.9 18.0 1.5 > 0 0 38 154.3 45.6 3.4 > 0 0 40 55.8 27.8 2.0 > 0 0 41 35.5 23.7 1.5 > 0 0 43 -25.3 34.4 -0.7 > 0 0 44 67.7 32.1 2.1 > > > > The data has an overall completeness of 99.7%. > > When I run the data trough xtriage, it tells me: > > Statistics depending on twin laws > ----------------------------------------------------------------- > | Operator | type | R obs. | Britton alpha | H alpha | ML alpha | > ----------------------------------------------------------------- > | -h,-k,l | M | 0.307 | 0.301 | 0.256 | 0.022 | > ----------------------------------------------------------------- > > Patterson analyses > - Largest peak height : 5.288 > (corresponding p value : 0.86552) > > > The largest off-origin peak in the Patterson function is 5.29% of the > height of the origin peak. No significant pseudotranslation is detected. > > The results of the L-test indicate that the intensity statistics > are significantly different than is expected from good to reasonable, > untwinned data. > As there are twin laws possible given the crystal symmetry, twinning could > be the reason for the departure of the intensity statistics from normality. > It might be worthwhile carrying out refinement with a twin specific target function. > > I also estimated the twin fraction with the following server: > > http://nihserver.mbi.ucla.edu/Twinning/ > > And found it to about 20% (using data from 6-3A). > > After phasing the data with rigid body refinement in Refmac with intensity based twin refinement (brings both R-factors to ~36%), I have tried doing a twin refinement with Phenix: > > %phenix.refine model.pdb data.mtz twin_law="-h,-k,l" strategy=rigid_body+individual_sites+group_adp > > > The R_factors consistently diverge to the following values: > > Final R-work = 0.3392, R-free = 0.4360 > > Simulated annealing/TLS/ordered solvent/messing with wxc/wxu weights does not seem to improve the situation. I have also tried this with and without prior detwinning with the CCP4 program "Detwin", with similar results. > > Reindexing to -h,-k,l gives similar R-factors after rigid body refinement but after refinement with Phenix, things get even worse: > Final R-work = 0.3919, R-free = 0.5059 > > I was surprised to see that the fit to the map using both indexing conventions are comparable even though this should effectively reverse the hand of the structure. I assume this is because twin refinement is basically doing the job of "partial reindexing" on those parts of the lattice which are twinned? > > I have been working on this for about a week now and can't for the life of me find a way forward. If anyone can offer any suggestions It would greatly be appreciated. Im slowly beginning to lose my sanity.... > > BTW I don't think my problems stem from misindexing, although the beam was wondering all over the place during this block of data collection, I have previously solved another structure at the same d and xbeam ybeam values without any trouble. > > Sorry about the v.long post. Thought it would be better to give too much information rather than not enough =) > > Many thanks for all your suggestions in advance and for everything I > have learned from this community in the past. Cheers, > > Joe > PhD student. > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > Get personal with Windows. Download a free gift for your PC. > http://experience.windows.com >

4 11

Re: [phenixbb] pointer distances
by Maia Cherney 26 Mar '10

26 Mar '10

Thank you, Paul. There is also difference in recording water. Should it be ATOM or HETATM? Phenix makes it HETATM, but coot makes it ATOM. Here is an example that was saved after adding one water molecule in coot (after refinement in phenix). HETATM10472 O HOH S1252 75.727 6.379 70.023 1.00 31.17 O HETATM10473 O HOH S1253 40.692 -0.062 54.840 1.00 37.64 O TER 10474 HOH S1253 ATOM 10475 O HOH S1254 75.842 2.043 56.024 1.00 35.64 O TER 10476 HOH S1254 END Maia Paul Emsley wrote: > Maia Cherney wrote: >> Hi Paul, >> >> Coot saves pdb files with TER card. The problem is the TER card takes >> the next atom number. >> >> >> ATOM 2303 C4 ADP A 288 33.070 4.240 14.161 1.00 >> 11.08 C TER 2304 ADP A 288 ATOM 2305 O >> SER B -1 >> >> The same model after phenix gives no number to the TER card. >> >> ATOM 2303 C4 ADP A 288 33.070 4.240 14.161 1.00 >> 11.08 C >> TER >> ATOM 2304 O SER B -1 >> >> >> As a result, the number of atoms in the pdb files is different. That >> is confusing. Could you please fix this problem. >> >> Maia >> >> > > > Hi Maia, > > It seems to us that this is an issue with Phenix, not Coot or mmdb. > > Have a look here: > > http://www.wwpdb.org/documentation/format32/sect9.html#TER > > "The serial number of the TER record is one number greater than the > serial number of the ATOM/HETATM preceding the TER" > > Regards, > Paul. > > > > >

1 1

Twinning Refinement
by Joseph Brock 26 Mar '10

26 Mar '10

Dear Phenix Users, I'm currently using version: Version: 1.4 Release tag: 3 cctbx tag: 2008_12_07_1353 Platform: mac-intel-osx osx-10.5.6 I am working on characterising substrate/inhibitor interactions of a protein, the structure has been solved many times so its unit cell dimensions, contents (1 molecule per ASU) and space group (P3121) are well characterized. However, I have recently encountered several crystals that appear exhibit merohedral twinning, and am having trouble converging the R-factors to reasonable levels. The details of one such data set is described below: Diffraction to ~1.9A was recorded using a high and low resolution pass of 180º each. When processed with HKL2000 separately or together, Scalepack wanted to reject huge amounts of my data (~20%). I was forced to increase the error scale factor to 2 and adjust my error model to the very high R-factors of the low-resolution shells. The summary table from my final round of scalepack is: Shell Lower Upper Average Average Norm. Linear Square limit Angstrom I error stat. Chi**2 R-fac R-fac 50.00 4.09 7648.3 1498.7 182.7 1.030 0.376 0.424 4.09 3.25 3885.1 568.9 64.1 1.410 0.416 0.480 3.25 2.84 1609.7 225.0 26.1 1.227 0.451 0.517 2.84 2.58 807.9 97.1 25.3 1.958 0.439 0.561 2.58 2.39 496.6 59.7 22.0 1.060 0.257 0.268 2.39 2.25 335.5 53.0 18.1 0.717 0.275 0.238 2.25 2.14 221.7 19.0 17.4 2.389 0.354 0.298 2.14 2.05 143.1 19.5 17.5 1.537 0.459 0.351 2.05 1.97 87.0 20.2 17.1 1.079 0.663 0.480 1.97 1.90 54.6 20.3 16.7 1.073 0.990 0.696 All reflections 1588.3 269.2 41.9 1.350 0.400 0.444 In addition, many systematic absences appear to be present: Intensities of systematic absences h k l Intensity Sigma I/Sigma 0 0 5 177.7 56.7 3.1 0 0 7 255.5 70.6 3.6 0 0 8 264.8 73.2 3.6 0 0 10 595.0 164.2 3.6 0 0 11 2343.5 1289.9 1.8 0 0 13 321.3 125.4 2.6 0 0 14 66.5 21.8 3.1 0 0 16 238.0 76.3 3.1 0 0 17 394.3 109.1 3.6 0 0 19 13.0 7.1 1.8 0 0 20 650.1 179.5 3.6 0 0 22 199.6 55.6 3.6 0 0 23 953.9 372.0 2.6 0 0 25 192.2 62.2 3.1 0 0 26 1038.7 405.0 2.6 0 0 28 96.3 28.9 3.3 0 0 29 2303.0 897.0 2.6 0 0 31 12.0 11.5 1.0 0 0 32 1622.4 516.5 3.1 0 0 34 11.5 13.8 0.8 0 0 35 22.8 14.8 1.5 0 0 37 27.9 18.0 1.5 0 0 38 154.3 45.6 3.4 0 0 40 55.8 27.8 2.0 0 0 41 35.5 23.7 1.5 0 0 43 -25.3 34.4 -0.7 0 0 44 67.7 32.1 2.1 The data has an overall completeness of 99.7%. When I run the data trough xtriage, it tells me: Statistics depending on twin laws ----------------------------------------------------------------- | Operator | type | R obs. | Britton alpha | H alpha | ML alpha | ----------------------------------------------------------------- | -h,-k,l | M | 0.307 | 0.301 | 0.256 | 0.022 | ----------------------------------------------------------------- Patterson analyses - Largest peak height : 5.288 (corresponding p value : 0.86552) The largest off-origin peak in the Patterson function is 5.29% of the height of the origin peak. No significant pseudotranslation is detected. The results of the L-test indicate that the intensity statistics are significantly different than is expected from good to reasonable, untwinned data. As there are twin laws possible given the crystal symmetry, twinning could be the reason for the departure of the intensity statistics from normality. It might be worthwhile carrying out refinement with a twin specific target function. I also estimated the twin fraction with the following server: http://nihserver.mbi.ucla.edu/Twinning/ And found it to about 20% (using data from 6-3A). After phasing the data with rigid body refinement in Refmac with intensity based twin refinement (brings both R-factors to ~36%), I have tried doing a twin refinement with Phenix: %phenix.refine model.pdb data.mtz twin_law="-h,-k,l" strategy=rigid_body+individual_sites+group_adp The R_factors consistently diverge to the following values: Final R-work = 0.3392, R-free = 0.4360 Simulated annealing/TLS/ordered solvent/messing with wxc/wxu weights does not seem to improve the situation. I have also tried this with and without prior detwinning with the CCP4 program "Detwin", with similar results. Reindexing to -h,-k,l gives similar R-factors after rigid body refinement but after refinement with Phenix, things get even worse: Final R-work = 0.3919, R-free = 0.5059 I was surprised to see that the fit to the map using both indexing conventions are comparable even though this should effectively reverse the hand of the structure. I assume this is because twin refinement is basically doing the job of "partial reindexing" on those parts of the lattice which are twinned? I have been working on this for about a week now and can't for the life of me find a way forward. If anyone can offer any suggestions It would greatly be appreciated. Im slowly beginning to lose my sanity.... BTW I don't think my problems stem from misindexing, although the beam was wondering all over the place during this block of data collection, I have previously solved another structure at the same d and xbeam ybeam values without any trouble. Sorry about the v.long post. Thought it would be better to give too much information rather than not enough =) Many thanks for all your suggestions in advance and for everything I have learned from this community in the past. Cheers, Joe PhD student. _________________________________________________________________ Get personal with Windows. Download a free gift for your PC. http://experience.windows.com

4 4

project defaults ncs.params not read or overridden/overwritten by GUI?
by hari jayaram 25 Mar '10

25 Mar '10

Hi I am quite sure I am doing something wrong , but the refinement seems to always re-determine the NCS definitions despite it being set in the ncs.params file in the project defaults directory. Here is what I did: 1. I set the NCS groups definition in the GUI to go from residues 35:445 , 2. I check that using the view pick . Everything looks fine 3. I click the Green update and exit button 4. I look at the ncs.params file in the project defaults directory and it indeed reflects the changes . 5. I start the refinement from the GUI and the ncs section seems to have been reset to 26:450 . I even tried adding the ncs.params file to the Input files section, but to no avail. The ncs seems to always get re-determined and I end up getting an excessive distance stoppage of refinement. I even made sure I dont have the Find NCS restraints automatically button checked. Any idea why I cannot get the gui run refinement to remember my ncs definitions. Thanks in advance Hari

4 7