Pavel Afonine wrote:
Hi Dale,
1) Why you specify reflection MTZ file twice in phenix.refine script?
2) Try exactly the same Autobuild and phenix.refine runs but without any resolution limits. Is it still crashing in this case? The guess is that it could be a bug somewhere that causes MD5 calculation on processed data file (with resolution cutoffs applied) and then this "wrong" MD5 record goes into overall_best.pdb and causes inconsistency when compared with native 1M50-2.mtz when you start phenix.refine. Again, this is just a guess...
3) Does this work:
a) phenix.refine MR.1-protein.pdb 1M50-2.mtz output.prefix=junk phenix.refine junk_001.pdb 1M50-2.mtz
These command run.
b) phenix.refine MR.1-protein.pdb 1M50-2.mtz output.prefix=junk xray_data.high_res=2.2 xray_data.low_res=20 phenix.refine junk_001.pdb 1M50-2.mtz
The result is: Processing inputs. This may take a minute or two. Sorry: Unknown command line parameter definition: high_res = 2.2 Instead I tried: phenix.refine AutoMR_run_4_/MR.1-protein.pdb 1M50-2.mtz output.prefix=junk refinement.main.high_resolution=2.2 refinement.main.low_resolution=20 phenix.refine junk_001.pdb 1M50-2.mtz This runs w/o error messages, although the resolution limits are not passed to the second phenix.refine. It uses all the data in the mtz.
c) phenix.refine MR.1-protein.pdb 1M50-2.mtz output.prefix=junk phenix.refine junk_001.pdb 1M50-2.mtz xray_data.high_res=2.2 xray_data.low_res=20
phenix.refine AutoMR_run_4_/MR.1-protein.pdb 1M50-2.mtz output.prefix=junk phenix.refine junk_001.pdb 1M50-2.mtz refinement.main.high_resolution=2.2 refinement.main.low_resolution=20 These run w/o error messages. The first run uses all the data while the second uses the restricted resolution limits, as requested. Given these results I don't know why my attempt to run phenix.refine following autobuild is failing. Then again, I didn't write the thing.
Pavel.
PS> I will be away Dec, 30 - Jan, 1. I will have no email access during this time. Tom is unreachable Jan 1 - 21.
Dale Tronrud wrote:
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 _______________________________________________ phenixbb mailing list [email protected] http://www.phenix-online.org/mailman/listinfo/phenixbb
_______________________________________________ phenixbb mailing list [email protected] http://www.phenix-online.org/mailman/listinfo/phenixbb