Nick What you describe is (almost) exactly the way we have always done it at Astex & I'm surprised to hear that others are not routinely doing the same. The difference is that we don't generate a free R flag MTZ file to ultra-high resolution as you suggest, since there's never any need to. What we do is generate by default a 1.5 Ang. free R flag file using UNIQUE, FREERFLAG and MTZUTILS whenever a new apo structure for a given target/crystal form is solved and keep that with the intial apo data as a reference dataset for auto-re-indexing (so that all the protein-ligand datasets are indexed the same way). When a dataset is combined with the higher resolution free R flag file we would of course cut the resolution to that of the data (still keeping the original free R flag file), mainly in order to save space in the database.
Obviously if the initial apo data were higher resolution than 1.5 Ang, the processing script would generate an initial free R flag file also correspondlingly higher (say to 1 Ang.). If a ligand dataset comes along later at higher resolution than 1.5 Ang. the script would do the same thing, but then it would use the MTZUTILS UNIQ option to merge the old free R flags up to 1.5 Ang. with the new ones between 1.5 and 1 Ang. Then it would combine the data file with the free R flag file as before and cut the resolution of the combined data file to the actual resolution of the data. The script would then replace the old free R flag file with the new one and use the latter for all subsequent datasets from that target/crystal form. The users are completely unaware that any of this is happening (unless they want to dig into the scripts!). We enforce use of 'approved' scripts for all the processing and refinement essentially by using an Oracle database with web-based access authentication which means that if you don't use the approved scripts to process your data then you can't upload your data to the database, which then means that no-one else will get to see and/or use your results! Our scripts make full use of CCP4 and Global Phasing programs (autoPROC, autoBUSTER, GRADE etc): however using CCP4i or other programs from the command line to process the data and only uploading the final results to the database is severely deprecated (and totally unsupported!), mainly because there will then be no permanent traceback in the database of the user's actions for others to see. On Gerard's final point of the effect on non-isomorphism, we find that isomorphism is the exception rather than the rule, i.e. the majority of our datasets would fail the Crick-Magdoff test for isomorphism (i.e. no more than 0.5% change for all cell lengths for 3 Ang. data and a correspondingly lower threshold at more typical resolution limits of 2 - 1.5 Ang.). This is obviously very target and crystal form-dependent, some targets/crystal forms give more isomorphous crystals than others. So I suspect that most of our efforts in maintaining common free R flags are for nothing; however it saves arguments with referees when it comes to publication! Cheers -- Ian On 4 June 2015 at 16:00, Nicholas Keep <n.k...@mail.cryst.bbk.ac.uk> wrote: > I agree with Gerard. It would be much better in many ways to generate a > separate file of Free R flags for each crystal form of a project to some > high resolution that is unlikely to ever be exceeded eg 0.4 A that is a > separate input file to refinement rather than in the mtz. > > > The generation of this free set could ask some questions like is the data > twinned, do you want to extend the free set from a higher symmetry free > set. eg C2 rather than C2221 (symmetry is close to the higher symmetry but > not perfect- seems to happen not infrequently). > > Could some judicious selection of sets of related potentially related hkls > work as a universal free set????? (Not thought this through fully) > > This would get around practical issues like I had yestserday in refining > in "another well known package" where coot drew the map as if it was 0.5 A > data even though there were only observed data to 2.1 the rest just being a > hopelessly overoptimistic guess of the best ever dataset we might collect. > > I agree you CAN do this with current software- it is just not the path of > least resistance, so you have to double check your group are doing this. > > Best wishes > Nick > > > > > > -- > Prof Nicholas H. Keep > Executive Dean of School of Science > Professor of Biomolecular Science > Crystallography, Institute for Structural and Molecular Biology, > Department of Biological Sciences > Birkbeck, University of London, > Malet Street, > Bloomsbury > LONDON > WC1E 7HX > > email n.k...@mail.cryst.bbk.ac.uk > Telephone 020-7631-6852 (Room G54a Office) > 020-7631-6800 (Department Office) > Fax 020-7631-6803 > If you want to access me in person you have to come to the crystallography > entrance > and ring me or the department office from the internal phone by the door >
