January 2008 - phenixbb - phenix-online.org

Autosol Feedback and questions
by Partha Chakrabarti 04 Jan '08

04 Jan '08

Happy new year everybody, I had quite a bit of difficulty with a SAD dataset which also showed Sulphur. Previously I had tried SHELEX to find sites, MLPHARE to refine, AddSOLVE to find more , and both SOLVE and PHASER to solve but it did not get to a point where I could do manual building. Autosol worked beautifully, the input files were scalepack merged data, ha.pdb (from addsolve step), and the sequence. PHASER to solve and TEXTAL & RESOLVE with through build option. This actually leave me with some confusions / questions: 1. When I compare the other "solutions", they look like the right one, just not good enough. Where exactly is the autosol making a difference? Is it the ability of of TEXTAL to build something more meaningful when the solution is not good or number of iterations? 2. How does PHASER know the different anomalous atoms? Does is use a different scaling factor for SE and S? 3. I see that phenix.refine has been used in the internal runs, I have used phenix.refine earlier. But after playing with the side chains in Coot, when I tried to use the modified pdb file and resolve.mtz, it complained about the good old Free_R flag. However, it ran directly in Refmac. Is it a known problem or maybe I did something stupid? I could do a dry run and change the read mtz and not cns if that would solve the problem. 4. Lastly, is it possible to use multiple processors to run the job? Best regards, Partha -- MRC National Institute for Medical Research Division of Molecular Structure The Ridgeway, NW7 1AA, UK Email: pchakra(a)nimr.mrc.ac.uk Phone: + 44 208 816 2515

2 1

Re: [phenixbb] Using the Same Test Set in AutoBuild and Phenix.Refine
by Thomas C. Terwilliger 03 Jan '08

03 Jan '08

Hi Dale, Can you try something else: phenix.refine AutoBuild_run_12_/overall_best.pdb \ refinement.input.xray_data.file_name=\ AutoBuild_run_12/exptl_fobs_freeR_flags.mtz \ refinement.main.high_resolution=2.2 refinement.main.low_resolution=20 \ /usr/users/dale/geometry/chromophores/bcl_tnt.cif This differs from your run only by substituting AutoBuild_run_12/exptl_fobs_freeR_flags.mtz for your 2 refinement data files. This is the exact file that is used in refinement by AutoBuild. I agree that you should be able to use your original data file instead. A possible reason why this has failed is that the original data file has a couple reflections for which there is no data...and which were tossed by AutoBuild before creating exptl_fobs_freeR_flags.mtz . Two files that differ only in reflections with no data will still give different checksums, I think. All the best, Tom T > Hi Dale, > >>> 1) Why you specify reflection MTZ file twice in phenix.refine script? >>> >>> >> I put the mtz in twice because if I put it in once phenix.refine >> complains that I have no free R flags. It seems to want one file with >> the amplitudes and another with the flags. Since I have both in the >> same file I put that file on the line twice and phenix.refine finds >> everything it needs. >> > > phenix.refine looks for free-R flags in your main data file > (1M50-2.mtz). Optionally you can provide a separate file containing > free-R flags (I have to write about this in the manual). However, if > your 1M50-2.mtz contains free-R flags then you don't need to give it > twice. So clearly something is wrong at this step and we need to find > out what is wrong before doing anything else. Could you send the result > of the command "phenix.mtz.dump 1M50-2.mtz" to see what's inside of your > data file? Or I can debug it myself if you send me the data and model. > >> If the MD5 hash of the test set depends on the resolution then >> certainly >> I could be in trouble. > > No. It must always use the original files before any processing. > >> Does the resolution limit affect the MD5 hash of the test set? >> > > No. If it does then it is a very bad bug. I will play with this myself > later tonight. > >> >>> 3) Does this work: >>> >>> (...) >> >> I'll try these but it will take a bit of time. >> > > Don't run it until completion. Just make sure it passed through the > processing step. > > Pavel. > > _______________________________________________ > phenixbb mailing list > phenixbb(a)phenix-online.org > http://www.phenix-online.org/mailman/listinfo/phenixbb >

3 2

Using the Same Test Set in AutoBuild and Phenix.Refine
by Dale Tronrud 03 Jan '08

03 Jan '08

Hi all, I have another problem, I'm afraid. I have built a model using phenix.autobuild and now want to run some refinement. While in the long run I'll do some manually rebuilding using Coot I just wanted to run a test of phenix.refine to ensure I have the script right and have a baseline to compare against later. My autobuild script is: phenix.autobuild model=AutoMR_run_4_/MR.1-protein.pdb data=1M50-2.mtz \ input_refinement_labels="FP SIGFP None None None None None None FreeR_flag" \ map_file=AutoMR_run_4_/MR.MAP_COEFFS.1.mtz \ seq_file=../fmo-ct.pir \ resolution=2.2 dmax=20 refinement_resolution=2.2 \ cif_def_file_list=/usr/users/dale/geometry/chromophores/bcl_tnt.cif \ input_lig_file_list=AutoMR_run_4_/MR.1-Bchl-a.pdb \ rebuild_in_place=Yes My refine script is phenix.refine AutoBuild_run_12_/overall_best.pdb \ refinement.input.xray_data.file_name=1M50-2.mtz 1M50-2.mtz \ refinement.main.high_resolution=2.2 refinement.main.low_resolution=20 \ /usr/users/dale/geometry/chromophores/bcl_tnt.cif As you can guess, my test set flags are in the same mtz file as the amplitudes. I'm feeding exactly the same file into both runs. Despite this I get in my output ******************************************************************************* ******************************************************************************* The MD5 checksum for the R-free flags array summarized above is: 785fd03f6881898dcd91bc5f8c3e5b26 The corresponding MD5 checksum in the PDB file summarized above is: 6f86ee71dbcd2dc1f5282cf18547c79b These checksums should be identical but are in fact different. This is because the R-free flags used at previous stages of refinement are different from the R-free flags summarized above. As a consequence, the values for R-free will be biased and misleading. It is best to avoid this situation by consistently using the same R-free flags throughout the refinement of a model. If the previously used R-free flags are still available run this command again with the name of the file containing the original flags as an additional input. If the original R-free flags are unrecoverable, remove the REMARK r_free_flags.md5.hexdigest 6f86ee71dbcd2dc1f5282cf18547c79b record from the input PDB file to proceed with the refinement. In this case the values for R-free will become meaningful only after many cycles of refinement. ******************************************************************************* ******************************************************************************* Sorry: Please resolve the R-free flags mismatch. While I'm glad that Phenix is checking to ensure that I haven't goofed and tried to switch test sets, I believe I'm being unjustly accused. Why does phenix.refine think I'm a bad boy? Dale Tronrud

2 5

Re: [phenixbb] Autosol Feedback and questions
by Ralf W. Grosse-Kunstleve 02 Jan '08

02 Jan '08

Hi Partha, > 3. I see that phenix.refine has been used in the internal runs, I have used > phenix.refine earlier. But after playing with the side chains in Coot, when > I tried to use the modified pdb file and resolve.mtz, it complained about > the good old Free_R flag. Is this the MD5 error message? > However, it ran directly in Refmac. Is it a known > problem or maybe I did something stupid? I could do a dry run and change > the read mtz and not cns if that would solve the problem. I'm not sure what's going wrong. To be sure, I'd need a reproducer, or at least an exact description of what happened in which order. > 4. Lastly, is it possible to use multiple processors to run the job? No, sorry. Parallelization is a big, complex project. The Cambridge group has started some work in this direction, but it is still very experimental. Ralf

1 0

Fatal Error: Incomplete libtbx environment!
by Yong-Fu Li 01 Jan '08

01 Jan '08

Hi, I just installed Phenix 1.3b, however got this error message when I tried to run phenix. ******************************************* Fatal Error: Incomplete libtbx environment! ******************************************* Please re-run the libtbx/configure.py command. My system is: 2.6.23.8-34.fc7 i686 Here is what I did: 1) downloaded phenix-installer-1.3b-rc6-intel-linux-2.6.tar 2) tar -xvf ... 3) In directory: phenix-installer-1.3b/, execute ./install 4) moved phenix-1.3b-rc6/ from /usr/local to /usr/local/progs where all of my programs dwell 5) source phenix_env in: /usr/local/progs/Phenix/phenix-1.3b-rc6 6) then run: ./phenix, and got the above message 7) as root go to /libtbx, chmod +x configure.py, and ./configure.py (I don't know about python, and my Python is 2.5), it hangs there for very long (>10 min) with another error: ./configure.py: line 3: syntax error near unexpected token `(' ./configure.py: line 3: `def run():' I checked the bb for help but didn't find any useful info (not finished reading all the messages). I wonder whether someone could help! Thanks and happy new year! Yongfu

3 2