- phenixbb - phenix-online.org

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 29 Mar '10

29 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 26 Mar '10

26 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

FreeR label?
by J. Fleming 25 Mar '10

25 Mar '10

Hello all, I used AutoSol to generate a model from my Se-Met crystal. I then used this output model, overall_best.pdb, for AutoBuild1 in which I extended the data to include a set of native data. At this point I took the exptl_fobs_phases_freeR_flags.mtz output and used it with a different model that I believe to be accurate to carry out AutoBuild2. The problem I'm having is that I can't run Refmac/Phenix refinements on the output from AutoBuild2: overall_best.pdb and overall_best_denmod_map_coeffs.mtz. Both pieces of software say the FreeR labels are missing although in the AutoBuild2 output PDB there is a FreeR test set count of ~2,000. When I list all labels in Refmac I see: F FP P PHIM W FOMM Using these labels doesn't work for refinement. I used default settings for AutoSol/AutoBuild except for the number of Se-Met sites and of course the f' and f'' etc. I'm assuming the problem is with the MTZ but I'm not sure where to troubleshoot. Does anyone have any thoughts? Thanks in advance, Jon

2 1

OS X PowerPC builds
by Ben Eisenbraun 25 Mar '10

25 Mar '10

Hi PHENIXians, I'm updating our nightly build, and I noticed that there are no current builds for OS X PowerPC. Are the PowerPC builds going to be discontinued? I searched the mailing list, but I didn't see an announcement. Thanks. -ben -- | Ben Eisenbraun | Software Sysadmin | | Structural Biology Grid | http://sbgrid.org | | Harvard Medical School | http://hms.harvard.edu |

3 2

Bulk solvent scaling & unstructured protein
by Mads Beich-Frandsen 25 Mar '10

25 Mar '10

Hi all, I have a P1-crystal and data (quite anisotropic to 2.85Å, 90% complete) of a partly unstructured protein, of which some 35% of the sequence is intrinsically unstructured. The structure has been solved by molecular replacement, and it has been refined to Rw/Rf 20/26 with Phenix. As expected, not much of the predicted unstructured region show clear density. The oligomeric protein packs in layers facing oneanother, leaving the unstructured parts 'packing' towards eachother, in what appears as huge solvent-channels. My question is now: Is there an approach to optimizing bulk solvent scaling in Phenix, keeping with the thought, that 30-35% of my protein sequence should be present where Phenix assigns bulk solvent. Thank you! -And any other tricks and tips will much appreciated! Rgds., Mads ------------------------------ Mads Beich-Frandsen Department of Structural and Computational Biology Max F. Perutz Laboratories University of Vienna Campus Vienna Biocenter 5 A-1030 Vienna Austria E-mail: mads.beich-frandsen(a)univie.ac.at Phone: +43-1-4277-52225 Fax: +43-1-4277-9522 Web: http://www.mfpl.ac.at/index.php?cid=58

2 1

where to find phenix.phaser 2.2.3 documentation on keywords
by Bjørn Panyella Pedersen 24 Mar '10

24 Mar '10

Dear list I am struggling to find the documentation for Phaser 2.2.3 (as part of phenix.phaser v1.6.289), and more specifically the list of allowed keywords and what their significance is. In my hands the PACK keyword is no longer allowed in v2.2.3 (works fine in v2.1.4) while two alternatives: SELECT CUTOFF DISTANCE and QUICK are suggested instead. However I cannot find any details on what these do. Ultimately I want to allow packing clashes beyond the default of 10. A google-search only give me hits on the Phaser homepage with documentation for v.2.1 (http://www-structmed.cimr.cam.ac.uk/phaser/documentation/index.html), and the phenix.phaser documentation (http://www.phenix-online.org/documentation/phaser.htm) does not include a keyword-list. Hope somebody can help with this simple problem. Best Bjørn -- Bjørn Panyella Pedersen, PhD Postdoc PUMPKIN, Centre for Membrane Pumps in Cells and Disease University of Aarhus, Dept. Molecular Biology Gustav Wieds Vej 10C DK-8000 Aarhus C, Denmark Phone: +45 89425261 E-mail: bjopp(a)bioxray.au.dk http://www.bioxray.au.dk

3 2