- phenixbb - phenix-online.org

Re: [phenixbb] Problem with AutoBuild and Alternative Conformations
by Thomas C. Terwilliger 17 Dec '07

17 Dec '07

Hi again Dale, I spoke too quickly...it is not so easy to change the code as I hoped. However here is a work-around that may be preferable anyhow: 1. Remove your ligand from the PDB file to be rebuilt and put it in "lig.pdb" 2. add to your commands for autobuild: input_lig_file_list=lig.pdb This will put all the contents of lig.pdb at the end of all PDB files just before refinement. All the best, Tom T Hi Dale, Your hypothesis: "I suspect that the coder assumed that all alternative conformations mutually exclusive and involve the same subset of the residue." is quite correct. (I am the coder in question). I think that I may be able to fix this particular problem and take care of the cases you have in this structure by simply allowing all conformations of ligands in the input file to be kept during rebuilding. With luck, this will work and will be in the final 1.3b version due out very shortly. The autobuild wizard still will not know how to build multiple conformations into a structure. For the time being it will have to stick with building one conformation. Thanks very much for the suggestion! -Tom T > Hi, > > I desire to resolve a crystal, who's structure factors I've downloaded > from the PDB, using my new high resolution model of this protein from a different species. I have decided to use the AutoMR wizard from Phenix for the chore. The MR seems to work just find, but I've run into a problem with the follow-up AutoBuild. > > This protein has a peptide chain that I would like rebuilt with the > proper amino acid sequence and seven Bchl-a molecules that I would like to be carried through to the end. Since the probe is from a high res refinement it contains quite a few groups with alternative conformations. This is not a problem in the protein part as it is being rebuilt and comes back with a single conformation for each residue. The Bchl-a molecules, however, are being horribly mutilated. > > In the Bchl-a groups, the "A" conformation is being promoted to > be the "main" (and only) conformation and the "B", "C", "D", "E", and, yes, the "F" conformations are lost. A Bchl-a molecule is much larger than an amino acid so it is quite possible, and reasonable, for one part to have a "A" and "B" pair of conformations, another part to have a "C" and "D" pair, and somewhere else for there to be a "E" and "F" pair. When conformation "C", "D", "E", and "F" are discarded whole sections of the Bchl-a molecule disappear > completely. This is bad. > > I suspect that the coder assumed that all alternative conformations > mutually exclusive and involve the same subset of the residue. I would prefer a more careful analysis to uncover the fact that "A" and "B" go together, and "C" and "D" go together. If there is a need to reduce the complexity of the model, (and I would prefer that all the alternatives make it through to the end) could the program keep "A", "C", and "E", or whatever makes sense for any particular residue? Better yet, instead of always keeping the first alternative of a set, could it keep the one with the highest occupancy? > > I'm using phenix-1.3b-rc6 on a Fedora 6 PC. > > Thanks, > Dale Tronrud >

2 1

Re: [phenixbb] Problem with AutoBuild and Alternative Conformations
by Thomas C. Terwilliger 17 Dec '07

17 Dec '07

Hi Dale, Your hypothesis: "I suspect that the coder assumed that all alternative conformations mutually exclusive and involve the same subset of the residue." is quite correct. (I am the coder in question). I think that I may be able to fix this particular problem and take care of the cases you have in this structure by simply allowing all conformations of ligands in the input file to be kept during rebuilding. With luck, this will work and will be in the final 1.3b version due out very shortly. The autobuild wizard still will not know how to build multiple conformations into a structure. For the time being it will have to stick with building one conformation. Thanks very much for the suggestion! -Tom T > Hi, > > I desire to resolve a crystal, who's structure factors I've downloaded > from the PDB, using my new high resolution model of this protein from a > different species. I have decided to use the AutoMR wizard from Phenix > for the chore. The MR seems to work just find, but I've run into a > problem with the follow-up AutoBuild. > > This protein has a peptide chain that I would like rebuilt with the > proper amino acid sequence and seven Bchl-a molecules that I would like > to be carried through to the end. Since the probe is from a high res > refinement it contains quite a few groups with alternative conformations. > This is not a problem in the protein part as it is being rebuilt and > comes back with a single conformation for each residue. The Bchl-a > molecules, however, are being horribly mutilated. > > In the Bchl-a groups, the "A" conformation is being promoted to > be the "main" (and only) conformation and the "B", "C", "D", "E", > and, yes, the "F" conformations are lost. A Bchl-a molecule is much > larger than an amino acid so it is quite possible, and reasonable, > for one part to have a "A" and "B" pair of conformations, another > part to have a "C" and "D" pair, and somewhere else for there to > be a "E" and "F" pair. When conformation "C", "D", "E", and "F" > are discarded whole sections of the Bchl-a molecule disappear > completely. This is bad. > > I suspect that the coder assumed that all alternative conformations > mutually exclusive and involve the same subset of the residue. I > would prefer a more careful analysis to uncover the fact that "A" and > "B" go together, and "C" and "D" go together. If there is a need to > reduce the complexity of the model, (and I would prefer that all the > alternatives make it through to the end) could the program keep "A", > "C", and "E", or whatever makes sense for any particular residue? > Better yet, instead of always keeping the first alternative of a set, > could it keep the one with the highest occupancy? > > I'm using phenix-1.3b-rc6 on a Fedora 6 PC. > > Thanks, > Dale Tronrud >

1 0

[Fwd: Auto-discard notification]
by Paul Adams 17 Dec '07

17 Dec '07

-- Paul Adams Deputy Division Director, Physical Biosciences Division, LBL 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: 510-486-4225, Fax: 510-486-5909 http://cci.lbl.gov/paul Lawrence Berkeley Laboratory 1 Cyclotron Road, BLDG 64R0121 Berkeley, CA 94720, USA. --

1 0

relative pathnames in .def or .eff files for phenix.refine?
by Schubert, Carsten [PRDUS] 14 Dec '07

14 Dec '07

Hi, would it be possible to add the option of using relative pathnames instead of full pathnames when .def and .eff files are written by phenix.refine? Would make transfer of files/projects easier. Cheers Carsten

1 0

Re: [phenixbb] Very very small Phaser Bug
by Tom Terwilliger 11 Dec '07

11 Dec '07

Hi James, Yes this sounds like a bug to me. I think it is a mis-communication between the automr wizard and phaser. We'll check it out. Thank you! -Tom T At 10:05 PM 12/10/2007, you wrote: >This is a fairly trivial bug, but I thought I'd report it anyway (I'm >not sure whether the problem is with the phenix.automr (rc6 build) or >with all phaser implementations (the one included is: 2.1.1 so I've >emailed both lists): > >when running phaser in data that was scaled in P 31 2 1, I used >phenix.automr to automate MR searches in all spacegroups that are >indistinguishable by systematic absences with: > >phenix.automr template.pdb final_P3121.sca RMS=1 mass=17000 >rebuild_after_mr=False copies=1 use_all_plausible_sg=True > >The program correctly finds the solution in P3221 with a log >likelihood gain of 1000 vs 20 for P3121, everything is fine in the >outputted PDB CRYST1 line and MTZ; however the log file annoyingly >mentions the spacegroup for the last time with "Final space group:P 31 >2 1" even though elsewhere in the log file it correctly lists >"SpaceGroup of Solution: P 32 2 1". I've excerpted the log file >below. If this is the intended behaviour and not a bug, then I >apologize but find it quite counterintuitive. > >Just a small bug, haven't seen if this behaviour occurs in other >systematic absence-equivalent space groups. > >Best, > >jf > >**BEGIN LOG > > SpaceGroup of Solution: P 32 2 1 > > SINGLE solution > > Solution written to PDB file: /Users/jfraser/data/AutoMR_run_7_/MR.1.pd >b > Solution written to MTZ file: /Users/jfraser/data/AutoMR_run_7_/MR.1.mt >z > Solution log-likelihood gain: 1056.73 > Solution annotation (history): RFZ=11.9 TFZ=27.5 PAK=0 LLG=850 LLG=1057 > > > >AUTOMR RUN: 7 > >Files in directory : AutoMR_run_7_ > > > >CRITERIA FOR PHASER MR RUN: >selection_criteria_rot : Percent_of_best >selection_criteria_rot_value : 75 >use_all_plausible_sg : Yes >overlap_allowed : > >List of space groups tested: >['P 3 2 1', 'P 31 2 1', 'P 32 2 1'] > >Final space group:P 31 2 1 > >CURRENT ENSEMBLES: > >ENSEMBLE ID: ensemble_1 >FILE: template.pdb RMS = 1.0 >ENSEMBLES USED IN SEARCH: ensemble_1 > >**************** SOLUTION MR ******* > > Log likelihood gain for solution MR: 1056.7344 > Output PDB files for solution MR: MR.1.pdb > Output MTZ files for solution MR: MR.1.mtz > >**END LOG > > >-- >James Fraser >jamesfraser(a)berkeley.edu >Alber Lab >356 Stanley Hall, QB3 >UC Berkeley >Berkeley, CA 94720 >http://ucxray.berkeley.edu/~jfraser/ >_______________________________________________ >phenixbb mailing list >phenixbb(a)phenix-online.org >http://www.phenix-online.org/mailman/listinfo/phenixbb Thomas C. Terwilliger Mail Stop M888 Los Alamos National Laboratory Los Alamos, NM 87545 Tel: 505-667-0072 email: terwilliger(a)LANL.gov Fax: 505-665-3024 SOLVE web site: http://solve.lanl.gov PHENIX web site: http:www.phenix-online.org ISFI Integrated Center for Structure and Function Innovation web site: http://techcenter.mbi.ucla.edu TB Structural Genomics Consortium web site: http://www.doe-mbi.ucla.edu/TB

1 0

Very very small Phaser Bug
by James Fraser 11 Dec '07

11 Dec '07

This is a fairly trivial bug, but I thought I'd report it anyway (I'm not sure whether the problem is with the phenix.automr (rc6 build) or with all phaser implementations (the one included is: 2.1.1 so I've emailed both lists): when running phaser in data that was scaled in P 31 2 1, I used phenix.automr to automate MR searches in all spacegroups that are indistinguishable by systematic absences with: phenix.automr template.pdb final_P3121.sca RMS=1 mass=17000 rebuild_after_mr=False copies=1 use_all_plausible_sg=True The program correctly finds the solution in P3221 with a log likelihood gain of 1000 vs 20 for P3121, everything is fine in the outputted PDB CRYST1 line and MTZ; however the log file annoyingly mentions the spacegroup for the last time with "Final space group:P 31 2 1" even though elsewhere in the log file it correctly lists "SpaceGroup of Solution: P 32 2 1". I've excerpted the log file below. If this is the intended behaviour and not a bug, then I apologize but find it quite counterintuitive. Just a small bug, haven't seen if this behaviour occurs in other systematic absence-equivalent space groups. Best, jf **BEGIN LOG SpaceGroup of Solution: P 32 2 1 SINGLE solution Solution written to PDB file: /Users/jfraser/data/AutoMR_run_7_/MR.1.pd b Solution written to MTZ file: /Users/jfraser/data/AutoMR_run_7_/MR.1.mt z Solution log-likelihood gain: 1056.73 Solution annotation (history): RFZ=11.9 TFZ=27.5 PAK=0 LLG=850 LLG=1057 AUTOMR RUN: 7 Files in directory : AutoMR_run_7_ CRITERIA FOR PHASER MR RUN: selection_criteria_rot : Percent_of_best selection_criteria_rot_value : 75 use_all_plausible_sg : Yes overlap_allowed : List of space groups tested: ['P 3 2 1', 'P 31 2 1', 'P 32 2 1'] Final space group:P 31 2 1 CURRENT ENSEMBLES: ENSEMBLE ID: ensemble_1 FILE: template.pdb RMS = 1.0 ENSEMBLES USED IN SEARCH: ensemble_1 **************** SOLUTION MR ******* Log likelihood gain for solution MR: 1056.7344 Output PDB files for solution MR: MR.1.pdb Output MTZ files for solution MR: MR.1.mtz **END LOG -- James Fraser jamesfraser(a)berkeley.edu Alber Lab 356 Stanley Hall, QB3 UC Berkeley Berkeley, CA 94720 http://ucxray.berkeley.edu/~jfraser/

1 0

automr with muti components (NMR models)
by ming lu 09 Dec '07

09 Dec '07

Hi everyones I am trying automr to solve the structure of my protein. It has three domains, each domain has NMR structure available. So the sequence identity of my search model is 100%. I tried use mutiple components as search models, but I had a hard time to obtain a interpretable solution. Any suggestions on the use of mutiple components as search models? or suggestions on how to use NMR structure as search models? Thanks for your help. Ming

3 3

Can geometry restraints include non-ideal target values?
by Joe Krahn 07 Dec '07

07 Dec '07

I see that phenix is using the same kind of simplistic statistical restraints as CCP4. Are there plans to improve the geometry restraints once the rest of phenix is stable? The problem with simple statistical restraints as used by CCP4 is that they completely ignore correlations due to interactions of multiple restraints. This is particularly bad for puckered rings like proline and nucleic acids. Nucleic acids get around this by using a fixed sugar pucker, which results in a lot of bad geometries for non-helical nucleic acids (many of which make it in to the PDB). However, if you consider the geometries "ideal value" and "ideal value esd" as just another way to write a harmonic restraint, then it is possible to make an improved restraint library. In this case, some individual geometry restraints will have target values that restrain towards non-ideal values in order to produce the correct result when all terms are combined. The problem is that these terms will give higher RMSD values, which would probably confuse software like REFMAC, which is designed to tweak restraint weights based on RMSDs. So, does phenix have any built-in restraint adjustments that is based on current rmsds? If so, is there a way to disable it? Joe Krahn

3 4

Hydrogens of ligands generated in elbow explode in coot realspace refinement
by Schubert, Carsten [PRDUS] 06 Dec '07

06 Dec '07

Hi, when I refine a ligand with hydrogens in coot using realspace refinement, the hydrogens explode into the surrounding density. This only happens with ligand/cif files generated in elbow and not libcheck. Coot apparently needs and additional loop in the .cif file: _chem_comp_tree.xxxx, which is missing from the elbow output. Unfortunately the geometry generated by libcheck is pretty dismal, so I can probably get around this by running libcheck on the refined coords from elbow ... Nigel, is it possible to fix elbow for the next rc? PS I am running the latest phenix (rc6) and coot 0.33 if that helps. Cheers Carsten

2 1

Question about adding hydrogrens with reduce -- parameters for phenix.refine
by Schubert, Carsten [PRDUS] 06 Dec '07

06 Dec '07

Hi I am trying to generate a model with all hydrogens placed using reduce. To my surprise it only applies hydrogens to a selected few residues. How do I coax reduce to add ALL hydrogens to my model, according to the Richardson Lab paper this should be possible? The help from reduce was not helpful in that regard. Or is adding all hydrogens a bad idea? Along those lines. If I would use another tool to generate the hydrogens, like CNS(X) or Maeastro, how compatible are the parameter files? Thanks for any input Carsten

3 4