- phenixbb - phenix-online.org

alternative conformations
by Dr. Colin W. Levy 13 Feb '08

13 Feb '08

Hi, What is the correct procedure in phenix for dealing with alternative conformations of side chains? Thanks Colin

3 2

Clashes problem
by Simon Kolstoe 11 Feb '08

11 Feb '08

Dear Phenix community, I am using phenix.refine version 2007_08_18_1856 to refine a 2.65A structure (with individual_sites, group_adp, TLS & NCS, wxc_scale=0.1). After refinement I am running the pdb file through the Molprobity server. Molprobity gives a clash score of 33.78 indicating the number of steric clashes (within 0.4A) per 1000 atoms. I am slightly concerned that a refinement program seems happy to allow such clashes. Is this a problem with the version of phenix.refine I am running, or is there a more obvious explanation that I have missed? Thanks, Simon

7 7

Making GDP (non-polymer) into an RNA monomer
by Francis E Reyes 09 Feb '08

09 Feb '08

All I need to attach a 5' modification, a diphosphate guanosine to my RNA. I figure GDP (from the monomer library) has everything I need. However, what needs to be done to make a connection with the next nucleotide in the chain (in both phenix.refine and coot) ? Thanks FR --------------------------------------------- Francis Reyes M.Sc. 215 UCB University of Colorado at Boulder gpg --keyserver pgp.mit.edu --recv-keys 67BA8D5D 8AE2 F2F4 90F7 9640 28BC 686F 78FD 6669 67BA 8D5D

2 3

Re: [phenixbb] Making GDP (non-polymer) into an RNA monomer
by Ralf W. Grosse-Kunstleve 09 Feb '08

09 Feb '08

Hi Francis, > However, what's the etiquette for how the residue should be named in > the PDB? I have it right now as GDP, though Gr seems much more > sensible? Or should I name it something completely custom? If the monomer library GDP matches what you have in the PDB I'd stick with the name. I'd rename the residue only if modifications are necessary. Gr would be a problematic alternative because the monomer library uses that already for RNA Guanosine (mon_lib/g/GR.cif). Ralf

1 0

Re: [phenixbb] lower case chain IDs
by Engin Ozkan 08 Feb '08

08 Feb '08

Thanks, Ralf. We will have the latest CCI Apps installed in our upcoming February software update (which should include your December update), and give it another try. That will probably fix it. Engin Quoting "Ralf W. Grosse-Kunstleve" <rwgk(a)cci.lbl.gov>: > Hi Engin, > >> which, I guess, is the CCI Apps version from August 2007. > > Yes, that explains it. Sorry, when I saw your first message > I should have thought of this immediately. > > To resolve your problem, you'll need the latest CCI Apps. > Multiple CCI Apps versions can co-exist and the installation > takes only seconds. Could you try that? > > http://www.phenix-online.org/download/cci_apps/ > > You can install it under your home directory, i.e. you don't need > special privilleges. > Just make sure you source the setpaths of the version you want to use. > > Ralf >

1 0

lower case chain IDs
by Engin Ozkan 08 Feb '08

08 Feb '08

Hi everyone, We have a case with 32 molecules/asu, and have been using lower-case chain IDs. But we could not figure out how to describe lower-case chain IDs for NCS purposes? In CNS, quotation marks around the segID in ncs.def does it, but that trick does not seem to work in phenix.refine. Thanks, Engin

2 1

A few questions
by Rife, Christopher L 07 Feb '08

07 Feb '08

Hi, We are working on a refinement at 1.14A which was suffering from lots of NPD atoms when refined anisotropically with refmac5 and/or shelx. We followed the guidelines recently posted to this BB, and initially the results looked pretty good, but upon close inspection we have a few questions. We are using Version: 2008_01_09_2058. 1. In our model we have a few solvent ligands, and these show up in the log file as: Unusual residues: {'EDO': 11, ' CL': 1, 'SO4': 1} Classifications: {'undetermined': 13, 'water': 437} We've used a cif file for EDO with H's when needed, but still see this message. Is this normal? What is unusual? 2. When choosing "indivdual_occupancies" for the refinement, all the atoms within an alt-conf are refined to different occupancies- is this expected? It seems that all atoms in the A conf should have the same value, and the occ of all atoms in the B conf should also be the same. Instead, we see this: ATOM 232 CA AGLU A 28 26.163 7.163 4.422 0.77 6.73 C ATOM 233 CB AGLU A 28 24.851 7.269 3.672 0.80 9.27 C ATOM 234 CG AGLU A 28 24.978 6.767 2.259 0.66 12.91 C ATOM 235 CD AGLU A 28 23.662 6.717 1.554 1.00 16.51 C ATOM 236 OE1AGLU A 28 22.874 7.667 1.757 0.71 18.78 O ATOM 237 OE2AGLU A 28 23.429 5.733 0.803 0.60 16.77 O ATOM 240 CA BGLU A 28 26.140 7.156 4.424 0.23 6.33 C ATOM 241 CB BGLU A 28 24.794 7.230 3.713 0.20 6.48 C ATOM 242 CG BGLU A 28 24.877 6.766 2.280 0.34 6.55 C ATOM 243 CD BGLU A 28 23.536 6.702 1.598 0.00 7.53 C ATOM 244 OE1BGLU A 28 23.497 7.014 0.381 0.29 7.85 O ATOM 245 OE2BGLU A 28 22.543 6.341 2.280 0.40 8.40 O 3. Adding hydrogens during anisotropic refinement results in the Parvati server giving "Illegal Biso" errors for many of the hydrogens. I can make the files available if that will help. Thanks, Chris ----------------------------------------- Structure Determination Core Joint Center for Structural Genomics Stanford Synchrotron Radiation Laboratory

9 14

Re: [phenixbb] Question/enhancement request for automated datafile conversion
by Ralf W. Grosse-Kunstleve 07 Feb '08

07 Feb '08

Hi Carsten, > The .sca file (or dtrek .ref) file gets automatically converted to a > mtz file with I-obs and SIGI-obs and refinement proceeds as expected. I > just noticed that in the following ...002.def file and in the 001.eff > file the parameter xray_data.observation_type is set to amplitude > instead of intensities. What is going on there, is phenix smart enough > to know when it deals with amplitudes vs. intensities? Did not seem to > have much effect on the refinement though when I switched this around, > which is surprising. That parameter wasn't actually used. I just removed it completely. Thanks for alerting us to this. > As an enhancement request: Would it be possible that the autoconversion > writes out a mtz file which contains BOTH amplitudes and intensities > instead of intensities and R-flags alone? OK, done! You will see the change in the next release (hopefully very soon). Ralf

1 0

Question/enhancement request for automated datafile conversion
by Schubert, Carsten [PRDUS] 06 Feb '08

06 Feb '08

Hi, I noticed that there is a possible inconsistency in the handling of xray datafiles in phenix. For instance, we usually invoke phenix like this: phenix.refine my.sca my.pdb my.def The .sca file (or dtrek .ref) file gets automatically converted to a mtz file with I-obs and SIGI-obs and refinement proceeds as expected. I just noticed that in the following ...002.def file and in the 001.eff file the parameter xray_data.observation_type is set to amplitude instead of intensities. What is going on there, is phenix smart enough to know when it deals with amplitudes vs. intensities? Did not seem to have much effect on the refinement though when I switched this around, which is surprising. As an enhancement request: Would it be possible that the autoconversion writes out a mtz file which contains BOTH amplitudes and intensities instead of intensities and R-flags alone? Sometimes it happens that I need to go back to running phaser when the initial rigid body refinement does not grip. Since phaser just runs on amplitudes I need to add a couple of extra steps to get a file, which is useful for both programs. I think the underlying philosophy should be that once data has been imported into the phenix suite, from whichever entry point, it should be usable w/o conversion in all applications. Cheers, Carsten

1 0

Question abount B-factor refinement - B-factors = 0
by Schubert, Carsten [PRDUS] 04 Feb '08

04 Feb '08

Hi, I have a question about B-factor refinement in phenix. This is a reiteration of one or two of threads with the same subject dating back to September last year: Initially, I noticed that the B-factors within a residue have quite a large spread, when one runs a temperature factor variance analysis as implemented in coot (Yes I read Pavel's response about this ...). This prompted me to actually look at the B-factors in the PDB file. I noticed that actually for quite a few residues one or more of the B-factors refines to 0.00 For instance one of the less extreme examples: ATOM 118 N HIS A 21 -28.768 35.430 2.317 1.00 4.73 N ATOM 119 CA HIS A 21 -27.357 35.565 2.625 1.00 0.00 C ATOM 120 C HIS A 21 -27.124 35.408 4.116 1.00 2.25 C ATOM 121 O HIS A 21 -28.072 35.360 4.902 1.00 7.73 O ATOM 122 CB HIS A 21 -26.853 36.940 2.186 1.00 8.10 C ATOM 123 CG HIS A 21 -27.610 38.078 2.799 1.00 11.18 C ATOM 124 ND1 HIS A 21 -28.733 38.624 2.216 1.00 17.18 N ATOM 125 CD2 HIS A 21 -27.418 38.759 3.955 1.00 13.28 C ATOM 126 CE1 HIS A 21 -29.194 39.600 2.979 1.00 25.70 C ATOM 127 NE2 HIS A 21 -28.414 39.701 4.041 1.00 12.79 N As background the data extends to 1.8A, with an I/I(s) of ~15 and ~2.5 in the highest shell, CHI^2 are all around 1+/ 0.1. The Wilson B is 11.3A^2 and R/Rfree 16.8/19.8%. This is homesource date, at the synchrotron I could probably push the resolution further out to better than 1.6A. No hydrogens were added, nor was TLS used. In order to get around the problem I initally reset all B-values to the Wilson-B, enabled wxc refinement (latest CCI-APPs) and refined ADPs only for 10 macrocycles. After a couple of cycles the B-factor distribution settled into the following, which looks fairly reasonable to me, except for the min values of 0.00: |-ADP statistics (Wilson B = 11.289)------------------------------------------| | Atom | Number of | Isotropic or equivalent| Anisotropy lmin/max | | type |iso aniso | min max mean | min max mean | | - - - - |- - - - - - -| - - - - - - - - - - - -| - - - - - - - - - - | | all : 2659 0 0.00 129.99 13.58 None None None | | all(noH): 2659 0 0.00 129.99 13.58 None None None | | Sol. : 390 0 0.35 56.99 27.75 None None None | | Mac. : 2269 0 0.00 129.99 11.14 None None None | | Hyd. : 0 0 None None None None None None | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | Distribution of isotropic (or equivalent) ADP for non-H atoms: | | Bin# value range #atoms | Bin# value range #atoms | | 0: 0.000 - 12.999: 1778 | 5: 64.993 - 77.991: 17 | | 1: 12.999 - 25.997: 492 | 6: 77.991 - 90.990: 9 | | 2: 25.997 - 38.996: 210 | 7: 90.990 - 103.988: 4 | | 3: 38.996 - 51.994: 124 | 8: 103.988 - 116.987: 2 | | 4: 51.994 - 64.993: 19 | 9: 116.987 - 129.985: 4 | | =>continue=> | |-----------------------------------------------------------------------------| B-factors of 0 indicate to me that there is a problem, not sure how to tackle this in phenix at this point. Could there be a problem with the bulk-solvent scaling? Should I restrict the minimum B-factor to 1.0 (ugggh)? Or should I tighten the B-factor restraints? Cheers, Carsten

2 3