[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