Well - most refinement procedures output the Fobs and the Fcalc on the same (more-or-less) absolute scale..
After data processing the observations are on a more or less arbitrary scale, so that seems sensible. It gets more problematic when you start correcting for anisotropy.. Eleanor On 17 July 2013 15:59, Phoebe A. Rice <pr...@uchicago.edu> wrote: > EEK, it seems to me that anything called simply "FP" should be > unadulterated FP. If the software modifies a column in some way, it should > give it a new label, shouldn't it? > > ++++++++++++++++++++++++++++++++++++++++++ > > Phoebe A. Rice > Dept. of Biochemistry & Molecular Biology > The University of Chicago > > 773 834 1723; pr...@uchicago.edu > http://bmb.bsd.uchicago.edu/Faculty_and_Research/ > > http://www.rsc.org/shop/books/2008/9780854042722.asp > ------------------------------ > *From:* CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Eleanor > Dodson [eleanor.dod...@york.ac.uk] > *Sent:* Wednesday, July 17, 2013 6:05 AM > *To:* CCP4BB@JISCMAIL.AC.UK > *Subject:* Re: [ccp4bb] TLS refinement refmac > > Oh dear - you should always start refinement against the original > processed data - but others have told you that already.. > > The TLS files will not be appropriate for the rescaled FPs - it is > surprising that the Rfactor actually goes down though! > Or are you doing several cycles of refinement in thesecond pass too - in > that case one would hope the Rfactor would continue to fall. > Eleanor > > > > > On 17 July 2013 11:00, Guenter Fritz <guenter.fr...@uni-konstanz.de>wrote: > >> Am 17.07.2013 11:59, schrieb Guenter Fritz: >> >>> Hi Stefan and Gottfried, >>> thanks a lot for the answers. This is the point. Wouldn't it make more >>> sense to add an extra column that contains the changed Fs? >>> Best, Guenter >>> >>> Hi, >>>> >>>> it is strongly advised to use the original mtz e.g. scala.mtz as the >>>> refmac input mtz in all refmac runs, >>>> as this contains the original Fs - Refmac applies some aniso >>>> corrections to the Fs and puts them into the output.mtz. >>>> >>>> so the output Fs are not the same as in the input F - therefore one >>>> should use the scala.mtz >>>> >>>> cheers >>>> Stefan >>>> >>>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von >>>> Guenter Fritz >>>> Gesendet: Mittwoch, 17. Juli 2013 10:39 >>>> An: CCP4BB@JISCMAIL.AC.UK >>>> Betreff: [ccp4bb] TLS refinement refmac >>>> >>>> >>>> Dear all, >>>> >>>> one gets different R values, if you re-read in the mtz written out by >>>> refmac after TLS refinement. I think this issue had been a while ago in >>>> ccp4bb, but I can't find the right track. >>>> >>>> Here are the details. >>>> >>>> 1st run: >>>> If we do TLS + restr. refinement in refmac we get: >>>> Initial Final >>>> R factor 0.3010 0.2170 >>>> R free 0.3175 0.2695 >>>> >>>> 2nd run: >>>> Now, if we use the same input pdb and the same input tls paramter file, >>>> but use the mtz written out by the first run, we get: >>>> Initial Final >>>> R factor 0.2274 0.1903 >>>> R free 0.2482 0.2540 >>>> >>>> >>>> Apparently in the mtz file written out by the 1st refmac must contain >>>> some information that is re-read in the 2nd run. But one just defines >>>> FP, SIGFP and Rfree flags. Do FPs change in the output mtz after TLS >>>> refinement?? >>>> >>>> Any help to clarify this is appreciated. >>>> >>>> Thanks, Guenter >>>> >>> >>> >
