[phenixbb] Using the Same Test Set in AutoBuild and Phenix.Refine

Dale Tronrud det102 at uoxray.uoregon.edu
Wed Jan 2 16:31:13 PST 2008

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
>> phenixbb at phenix-online.org
>> http://www.phenix-online.org/mailman/listinfo/phenixbb
> _______________________________________________
> phenixbb mailing list
> phenixbb at phenix-online.org
> http://www.phenix-online.org/mailman/listinfo/phenixbb

More information about the phenixbb mailing list