[phenixbb] rfree checksums version 1.3 and 1.4

hari jayaram harijay at gmail.com
Fri Apr 24 08:19:22 PDT 2009


Please disregard my previous message . The mistake was entirely mine
I had switched pdb files midstream and so the checksums got tangled up.

The checksum in the pdb came from an earlier round of refinement when I had
asked phenix to generate an rfree .

How does one get at the rfree flags that phenix uses when you ask it to
generate it. That way I can go back to these values and carry out step two
of my refinement.

Thanks for your help..and sorry for the confusion
Hari



On Fri, Apr 24, 2009 at 10:55 AM, hari jayaram <harijay at gmail.com> wrote:

> Hello Ralf and eversone else
> Thanks for your email concerning checksums.
>
> Here is what I am seeing
>
> I started with mymodel (model_mon19), ran one round of refinement against
> newdatadmm2_unique1.mtz in phenix 1.4.3 with command line like the one below
> .
> Using the output pdb , I rebuilt a lot and renamed pdb to model-fri24.pdb ,
> Now when I try refine using the same input mtz ..phenix complains about
> rfree checksum mismatch again.
>
> I am assuming that phenix does use the rfree from the mtz file
> (newdatadmm2_unique1.mtz) and the checksum for the rfree entered in the pdb
> should have come during round 1 from  newdatadmm2_unique1.mtz , so I  am a
> little concerned that it complains.
>
> The command lines I am using are given below: I only change the model , the
> ncs definition file and the directory in which the refinement is run.
> between runs.
>
> Hari
>
> phenix.refine newdatadmm2_unique1.mtz model-fri24.pdb
> simulated_annealing=true simple_ncs_from_pdb.ncs refinement.main.ncs=true
> refinement.input.xray_data.r_free_flags.generate=False --overwrite
> ordered_solvent=true main.number_of_macro_cycles=10
> strategy=rigid_body+group_adp+individual_sites
> refinement.ncs.excessive_distance_limit=None
> refinement.input.experimental_phases.labels=newdatadmm2_unique1.mtz:HLAC,HLBC,HLCC,HLDC>phenix_fri24.log
>
> Command that wrote the checksum is same as above with model replaced with a
> model that represented my initial build , untouched by phenix.
>
>
>
> On Tue, Apr 21, 2009 at 8:38 PM, Ralf W. Grosse-Kunstleve <
> rwgk at cci.lbl.gov> wrote:
>
>> > Most other things weere the same including the resolution cutoff used
>> and
>> > the input mtz.
>> > But phenix tells me that the md5checksums dont match.
>>
>> Sorry, that's unexpected. The cutoff doesn't matter. The checksum is
>> computed on the input data, before the cutoff is applied.
>> The checksum is just a safety guard to avoid accidents. If you are
>> sure the test set has not changed, simply remove the remark with
>> the checksum from the pdb file.
>> Let me know if the problem happens again and I'll take a closer look.
>> In that case I will need all the input files and the sequence of
>> commands to reproduce the problem (including the command that wrote
>> the pdb file with the checksum).
>>
>> Ralf
>> _______________________________________________
>> phenixbb mailing list
>> phenixbb at phenix-online.org
>> http://www.phenix-online.org/mailman/listinfo/phenixbb
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/phenixbb/attachments/20090424/feba7ad3/attachment-0003.htm>


More information about the phenixbb mailing list