Dear Vincent The STARANISO server option you allude to and were planning to use in order to "also include the original data in the final output" without any trimming by a mask does not really exist: the actual option currently on the server was not intended for preparation of data for deposition since although it outputs the original intensities, the anisotropic cut-off is still applied. There didn't seem to be a good reason at the time to carry forward the excluded data into subsequent processing (but maybe there is now an argument for doing that?).
We advise against deposition of _any_ of the server outputs, in fact we recommend that the following 2 datasets be deposited (see also http://staraniso.globalphasing.org/deposition_about.html): 1) The recommended merged _input_ file to the server, i.e. all merged data, from AIMLESS (or similar) before _any_ resolution cut-off (isotropic or anisotropic) is applied. If autoPROC/AIMLESS are used, the batch scaling is performed with the anisotropic cut-off obtained using the merged data then applied to the unmerged data, the batch scales so obtained are applied to the full unmerged data without a cut-off, and the merging is redone. This results in the 'aimless_alldata.mtz' file in the server download tarball which we recommend for deposition (after conversion to mmCIF obviously). 2) The output from the refinement program containing Fobs, Fcalc, phases and map coefficients converted to mmCIF (so that the maps in any publication can be _exactly_ reproduced). I will change the description of the server option to keep the "original data" to make it clearer what it does. Regards -- Ian On Thu, 27 Sep 2018 at 09:30, vincent Chaptal <[email protected]> wrote: > Hi Jude, > > thank you for your effort to desposit the untouched data. > > I was actually wondering how to do this myself as I am getting close to > the deposition stage with my anisotropic data. Thank you for sharing your > concerns, it will be useful to other users. > > Since Randy is asking for user's experience, what I've done in the past > was to dialog with the PDB and ask them to also include the original data > in the cif format. If I recall correctly, I've sent them the original mtz > file in the validation stage of the deposition, as the web site only allows > for one mtz file. Also, depending on how strong your anisotropy is..., > there was some "dialog" about data quality according to standards, and > other various concerns that we addressed in the publication, but couldn't > be accounted for in the deposition. So they ended up accepting the data, > with Author's comments. > What I was planning on doing for the current dataset, was to ask staraniso > to also include the original data in the final output. There is a box to > tick on the website, unticked by default. You can also modify the labels > there, asking for the modified data to be called I_SA/SIGI_SA for example > for StarAniso. > > Hope it helps > Vincent > > On 27/09/2018 09:56, Randy Read wrote: > > Dear Kevin, > > I’ve just been working through the issue myself of how to deposit both the > pruned data needed to reproduce the refinement and the unmassaged data. The > advice I got from the people at PDBe was to prepare an mmCIF file with two > reflection loops. The validation pipeline expects the first one to contain > the data actually used in refinement, so I prepared one in which the second > loop contained the full set of intensities. It should also be possible to > have a third loop containing unmerged original-index (but probably scaled) > intensity data, and this would be a good intermediate ground between the > worst option of just depositing French & Wilson (truncate) amplitudes and the > ideal-world case of depositing the raw diffraction images. > > Like you, I used the sf-tool at wwPDB, but I’ve just double-checked and the > mmCIF file I got has the same free flags for both reflection loops. In case > this helps to narrow down why you had a problem and I didn’t, the data I > submitted were in a single MTZ file, and the R-free flags had been prepared > with the CCP4 convention, with values from 0 to 19, and not a binary > convention with just values of 0 and 1. > > I’ve also been wondering about when you get to label the different intensity > sets! The mmCIF standard doesn’t have data types that distinguish different > kinds of observed intensities. We haven’t yet deposited the structure with > the data, and I’ve been hoping that you’re asked to provide labels during the > deposition process. Perhaps someone from one of the wwPDB sites, or someone > who has gotten as far as depositing such data, can comment! > > Best wishes, > > Randy Read > > ----- > Randy J. Read > Department of Haematology, University of Cambridge > Cambridge Institute for Medical Research Tel: +44 1223 336500 > Wellcome Trust/MRC Building Fax: +44 1223 336827 > Hills Road E-mail: > [email protected] > Cambridge CB2 0XY, U.K. > www-structmed.cimr.cam.ac.uk > > On 26 Sep 2018, at 19:34, Kevin Jude <[email protected]> > <[email protected]> wrote: > > I am preparing to deposit several structures that I refined against > anisotropic data that I truncated with STARANISO. I will of course be > depositing the original data with spherical resolution limits, but it seems > that I should also deposit the ellipsoidally truncated data that I actually > refined against. To be clear, these are the same dataset but in the second > case the unmerged reflections have been rescaled and I/SIGIs that fall > outside the ellipsoid are set to empty values. I have a technical problem > with preparing the mmcif and a broader question about presenting the data. > > I've tried to create an mmcif file from my mtz using > http://sf-tool.wwpdb.org, treating the two sets of I/sigI as two datasets. > For some reason, in the output file the test set flags are reversed for the > second "dataset" (whichever I choose to be second); ie, o becomes f and f > becomes o. This is a technical problem that I can correct with a text editor, > but still irritating. > > More importantly, is there a way to distinguish in the file between the > spherically complete dataset and the truncated dataset that was used in > refinement in a way that is useful to future users? I have not worked with > mmcif before and am not sure what column names are permissible, nor what > would be recognizable to other users or software. I'm interested to hear the > thoughts and experiences of the community on this. > > Best wishes > Kevin > > -- > Kevin Jude, PhD > Structural Biology Research Specialist, Garcia Lab > Howard Hughes Medical Institute > Stanford University School of Medicine > Beckman B177, 279 Campus Drive, Stanford CA 94305 > Phone: (650) 723-6431 > > > To unsubscribe from the CCP4BB list, click the following > link:https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1 > > ######################################################################## > > To unsubscribe from the CCP4BB list, click the following > link:https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1 > > > -- > > Vincent Chaptal, PhD > > MMSB -UMR5086 > > Drug Resistance and Membrane Proteins Laboratory > > 7 passage du Vercors > > 69007 LYON > > FRANCE > > +33 4 37 65 29 01 > > http://mmsb.cnrs.fr/en/ > > > > ------------------------------ > > To unsubscribe from the CCP4BB list, click the following link: > https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1 > ######################################################################## To unsubscribe from the CCP4BB list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
