December 2022 - phenixbb - phenix-online.org

map deposition strategy after density modification
by Daniel Larsson 20 Sep '23

20 Sep '23

Hi Phenix community, I’ve been using density modification with some success for my data and am considering the most appropriate way to do model building/refinement and then deposition of my results. Here are some questions/observations: 1) Which map should I refine against (most importantly, do the final minimization using phenix.real_space_refine)? The DM map is the most clear one, so I’m favoring to do it against this one (as long as the geometry/validation is also best for this one). 2) Which map should I deposit as my main map? Is it the autosharpened one or the DM one? Since the DM map looks the best, I want the user who only downloads one map to see this one, so again I favoring this map. 3) Which nominal resolution should I quote for my reconstruction? Since the procedure seems to introduce correlation between the two maps (see point 4 below), it does not seem to be possible to obtain a gold-standard FSC value between two truly independent half-maps. As the DM procedure supposedly actually improves the map (by leveraging knowledge about what solvent and macromolecular maps usually looks like and thereby improves the Fourier coefficients), it feels like it would be misrepresenting the data by quoting the FSC_0.143 from the original reconstruction. Should I use the FSC_0.5 estimated value that phenix.resolve_cryo_em outputs? 4) Which FSC curve should I deposit? When I calculate the FSC between the two density modified half-maps, I get a funny (or rather not so funny) looking curve with a bump at around 3Å and it does not go to zero at Nyquist (which does not agree with the map quality). This must again be due to the induced correlation between the maps, presumably during the masking of solvent and macromolecule density. Phenix.resolve_cryo_em calculates a FSC curve to calculate the FSC_0.5 value, which according to the manual page corrects for the correlation induced between the two maps: "Density modification introduces some correlations between half-maps due to solvent flattening. This can have a small effect on the resolution estimates obtained with half-map FSC. The resolution estimates provided by the program are corrected for this effect." But is this curve good enough? I think OneDeposit wants to have the gold-standard FSC curve, right? 5) Which (nowadays mandatory) half-maps should one deposit? Here I would say that the original half-maps before DM makes more sense, since these are less processed. But if one specify these as the half-maps, there will be inconsistencies during validation, since the DM map will look quite different from the average between the two original half-maps. Also the automatic FSC curve will be very different from the deposited one. So in conclusion, despite what I say above, the most conservative thing would be to deposit the conventionally sharpened map as my main map and use the original half-maps for calculating the FSC-curve and use the 0.143 threshold from this curve to estimate the resolution. The DM map can be used during rebuilding/refinement, but I think final minimization should be against the main map during deposition (with restraints if the geometry gets worse). The DM map can be deposited as an auxiliary map. Do the community and the developers agree? Regards, Daniel När du har kontakt med oss på Uppsala universitet med e-post så innebär det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/ E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: http://www.uu.se/en/about-uu/data-protection-policy

4 4

RapiData at SSRL 2022 - application deadline extended by two weeks!
by Smith, Clyde 12 Jan '23

12 Jan '23

We have extended the deadline for applications for a place at the RapiData 2022 @ SSRL workshop to next Friday, February 4th 2022! There are still a few spots left, so get your application in! The workshop will be held virtually from May 4 - 14 2022. The course will comprise lectures on the following topics: Specimen preparation, data collection strategies, X-ray light sources, X-ray detectors, data reduction, structure solution by MAD, SAD and molecular replacement, complementary methods (spectroscopy, small angle scattering and cryoEM). There will also be several days of software tutorials (HKL3000,XDS, CCP4/DIALS, Phenix, AutoSharp/AutoProc, Shelx, Coot) and you will all get to connect remotely to the SSRL beamlines to collect both monochromatic and MAD/SAD data. There is also an opportunity to ship your own samples to SSRL prior to the workshop, and collect your own data. Please visit https://www-ssrl.slac.stanford.edu/rapidata/rapidata-2022/index.html and use the links on the "registration" page to apply for the course. Successful applicants will be notified later in February 2022 and invited to register at that time (there will be no fee for registration). Regards, Clyde Smith (csmith(a)slac.stanford.edu) and Silvia Russi (srussi(a)slac.stanford.edu) Workshop Organizers

1 3

staraniso/phenix.refine
by Andrea Piserchio 22 Dec '22

22 Dec '22

Dear all, I am trying to validate and then (hopefully) deposit a structure generated using the autoproc/staraniso staraniso_alldata-unique.mtz file as input for phenix.refine. Autoproc also produces a cif file ( Data_1_autoPROC_STARANISO_all.cif) specifically for deposition. Long story short, the PDB validation server complains about the lack of a freeR set for both files. I realized that, at least for the cif file, the r_free_flag is missing (but why does the .mtz for the isotropic dataset work??),so I then tried to use for validation the *.reflections.cif file that can be generated by phenix.refine. This file can actually produce a validation report, but I still have some questions: 1) Is it proper to use the .reflections.cif file for this purpose? During the upload I do see some errors (see pics); also, the final results show various RSRZ outliers in regions of the structure that look reasonably good by looking at the maps on coot, which seems odd ... 2) In case the *.reflections.cif is not adequate/sufficient for deposition (I sent an inquiry to the PDB, but they did not respond yet), can I just add a _refln.status column to the autoproc cif file (within the loop containing the r_free_flag) where I insert “f” for r_free_flag = 0 and “o” everywhere else? Thank you in advance, Andrea

5 7

Labeling centric and acentric reflections
by Andre LB Ambrosio 22 Dec '22

22 Dec '22

Hi, Is there a way to label centric and acentric reflections in the .mtz file and output an additional column, let's say, with values 0 (acentric) and 1 (centric), similar to R_free flags? Many thanks for your attention. -- Andre LB Ambrosio Associate Professor, IFSC/USP - Brazil www.ifsc.usp.br/alba

2 4

Re: [phenixbb] staraniso/phenix.refine
by Gerard Bricogne 21 Dec '22

21 Dec '22

Dear Andrea, As Clemens Vonrhein is not not subscribed to the phenixbb, I am sending the message below on his behalf. With best wishes, Gerard. ---------------------------------------------------------------------------- Dear Andrea, Besides the paragraph in the Release Notes of our latest BUSTER release that Luca directed you to, you may find it useful to consult the following Wiki page: https://www.globalphasing.com/buster/wiki/index.cgi?DepositionMmCif Although it has not yet been updated so as to mention explicitly the cases where refinement was done with REFMAC or phenix-refine, the procedure and commands given there will work in these two cases as well. Our intention was to get feedback from our users first, then to announce the extended capability of aB_deposition_combine more broadly - but your question clearly shows that we should make that announcement sooner rather than later. Getting back to your message: although uploading either the phenix-generated mtz file or the mmCIF file generated by aB_deposition_combine would be acceptable to the OneDep system, we would highly recommend using those from aB_deposition_combine for several reasons. First of all, these files should already contain the data from Phenix but also provide additional data blocks with richer reflection data (and metadata!), going right back to the scaled and unmerged data without any cut-off applied. Furthermore, it should ensure that the correct data quality metrics (i.e. merging statistics) are included into the mmCIF files uploaded during deposition. Of course, you don't need to use aB_deposition_combine to generate such a set of mmCIF files (model and reflection data) - these are after all just text files - but the devil is often in the details. It may be useful to add some fairly general background information in order to avoid misunderstandings and false impressions - so here are some relevant points you may wish to consider. (a) The deposition of model and associated data into the PDB should allow for two things: (1) the validation of the current model and of its parametrisation on their own, as well as a check against the data used during refinement, and (2) the provision of additional data to allow further analysis of, and improvements to, the data handling as well as the model itself. For the first task one needs to deposit the data exactly as used by the depositor to arrive at the current model, i.e. the input reflection data (as used as input to the refinement program) plus all available Fourier coefficients (as output by that refinement program) needed to compute the maps used in modeling. The second task requires deposition of less and less "processed" versions of the experimental data - ultimately going back to the raw diffraction images. This might involve several sets of reflection data, e.g. (i) scaled, merged and corrected reflection data, (ii) scaled and merged data before correction and/or cutoff, and (iii) data scaled and unmerged before outlier rejection - plus additional variants. (b) When going from the raw diffraction images towards the final model, a lot of selection and modification of the initial integrated intensities takes place - from profile fitting, partiality scaling, polarization correction, outlier rejection, empirical corrections or analytical scale determination and error model adjustments, all the way the application of truncation thresholds (isotropically, elliptically or anisotropically), conversion to amplitudes (and special treatment of weak intensities) and anisotropy correction. There are often good reasons for doing all or some of these (with sound scientific reasons underpinning them - not just waving some "magic stick"), even if under special circumstances a deviation from standard protocols is advisable. What is important from a developer's viewpoint is to provide users with choices to influence these various steps and to ensure that as many intermediate versions of reflection data as possible are available for downstream processes and deposition. (c) At deposition time, the use of a single reflection datablock is often not adequate to provide all that information (e.g. refinement programs might output not the original Fobs going in, but those anisotropically rescaled against the current model - so a second block might be needed to hold the original Fobs data, free from that rescaling). If different types of map coefficients are to be provided, they too need to come in different mmCIF datablocks (2mFo-DFc and mFo-DFc for observed data only; 2mFo-DFc filled in with DFc in a sphere going out to the highest diffraction limit; 2mFo-DFc filled in with DFc for only the reflections deemed "observable" by STARANISO; F(early)-F(late) map coefficients for radiation damage analysis; coefficients for anomalous Fourier maps etc). So ultimately we need to combine (going backwards): the refinement output data, the refinement input data and all intermediate versions of reflection data (see above) ... ideally right back to the scaled+unmerged intensities with a full description of context (image numbers, detector positions etc). This is what the "Data Processing Subgroup" of the PDBx/mmCIF Working Group has been looking at extensively over the last months, and about which a paper has just been submitted. (d) autoPROC (running e.g. XDS, AIMLESS and STARANISO) and the STARANISO server provide multi-datablock mmCIF files to simplify the submission of a rich set of reflection data. autoPROC provides two versions here: one with traditional isotropic analysis, and the another for the anisotropic analysis done in STARANISO. It is up to the user to decide which one to use for which downstream steps. To help in combining the reflection data from data processing with that from refinement, and in transferring all relevant meta data (data quality metrics) into the model mmCIF file, we provide a tool called aB_deposition_combine: it should hopefully work for autoPROC (with or without STARANISO) data in conjunction with either BUSTER, REFMAC or Phenix refinement results. At the end the user is provided with two mmCIF files for deposition: (1) a model file with adequate data quality metrics, and (2) a reflection mmCIF file with multiple datablocks all the way back to the scaled+unmerged reflection data. (e) It is important at the time of deposition to not just select whatever reflection data file happens to be the first to make it through the OneDep system, as this can often lead to picking up the simplest version of an MTZ or mmCIF file, but to choose, if at all possible, the most complete reflection data file containing the richest metadata. Otherwise we simply increase the number of those rather unsatisfying PDB entries whose reflection data files contain only the very minimum of information about what they actually represent and what data quality metrics (such as multiplicity, internal consistency criteria etc) would have been attached to them in a richer deposition. *** Please note that the current OneDep system seems to complain about the fact that unmerged data blocks come without a test-set flag column: this looks to us like an oversight, since test-set flags are attributes belonging to the refinement process, so that it makes no logical sense to require them for unmerged data. This will probably requires some rethinking/clarification/changes on the OneDep side. A final remark: Instead of trying to give the impression that there is only one right way of doing things, and therefore only a single set of reflection data that should (or needs to) be deposited, it would seem more helpful and constructive to try and provide a clear description of the various "views" of the same raw diffraction data that can be provided by the various approaches and data analysis methods we have at our disposal. Together with more developments regarding the PDBx/mmCIF dictionary, and coordinated developments in the OneDep deposition infrastructure, this will enable better and richer depositions to be made, helping future (re)users as well as software developers. Cheers, Clemens ---------------------------------------------------------------------------- -- On Mon, Dec 19, 2022 at 05:42:24PM -0500, Andrea Piserchio wrote: > So, > > Both the phenix-generated mtz file (silly me for not checking this first) > and the cif file generated by aB_deposition_combine can be uploaded on the > PDB server. > > Thank you all for your help!! > > Andrea > > On Sat, Dec 17, 2022 at 5:06 PM Pavel Afonine <pafonine(a)lbl.gov> wrote: > > > Hi, > > > > two hopefully relevant points: > > > > - phenix.refine always produces an MTZ file that contains the copy of > > all inputs plus all is needed to run refinement (free-r flags, for > > example). So if you use that file for deposition you have all you need. > > > > - Unless there are strongly advocated reasons to do otherwise in your > > particular case, you better use in refinement and deposit the original > > data and NOT the one touched by any of available these days magic sticks > > (that "correct" for anisotropy, sharpen or else!). > > > > Other comments: > > > > > - However, CCP41/Refmac5 does not (yet) read .cif reflection files. As > > > far as I know, Phenix Refine does not (yet) neither. > > > > Phenix supports complete input / outputs of mmcif/cif format. For > > example, phenix.refine can read/write model and reflection data in cif > > format. It's been this way for a long time now. > > > > Pavel > > > > > > On 12/16/22 17:32, Andrea Piserchio wrote: > > > Dear all, > > > > > > > > > I am trying to validate and then (hopefully) deposit a structure > > > generated using the autoproc/staraniso staraniso_alldata-unique.mtz > > > file as input for phenix.refine. > > > > > > Autoproc also produces a cif file ( Data_1_autoPROC_STARANISO_all.cif) > > > specifically for deposition. > > > > > > Long story short, the PDB validation server complains about the lack > > > of a freeR set for both files. I realized that, at least for the cif > > > file, the r_free_flag is missing (but why does the .mtz for the > > > isotropic dataset work??),so I then tried to use for validation the > > > *.reflections.cif file that can be generated by phenix.refine. This > > > file can actually produce a validation report, but I still have some > > > questions: > > > > > > 1) Is it proper to use the .reflections.cif file for this purpose? > > > During the upload I do see some errors (see pics); also, the final > > > results show various RSRZ outliers in regions of the structure that > > > look reasonably good by looking at the maps on coot, which seems odd ... > > > > > > 2) In case the *.reflections.cif is not adequate/sufficient for > > > deposition (I sent an inquiry to the PDB, but they did not respond > > > yet), can I just add a _refln.status column to the autoproc cif file > > > (within the loop containing the r_free_flag) where I insert “f” for > > > r_free_flag = 0 and “o” everywhere else? > > > > > > > > > Thank you in advance, > > > > > > > > > Andrea > > > > > > _______________________________________________ > > > phenixbb mailing list > > > phenixbb(a)phenix-online.org > > > http://phenix-online.org/mailman/listinfo/phenixbb > > > Unsubscribe: phenixbb-leave(a)phenix-online.org > > > _______________________________________________ > phenixbb mailing list > phenixbb(a)phenix-online.org > http://phenix-online.org/mailman/listinfo/phenixbb > Unsubscribe: phenixbb-leave(a)phenix-online.org

1 0

Re: [phenixbb] centered triclinic lattice
by Cathy Lawson 15 Dec '22

15 Dec '22

Many thanks to all those who followed up with me both on and off the list. I notice now that 1LKS structure factors include hkl indices that violate reflection rules for A1 (general: k + l = 2n). The reflections in violation would have to be removed in order to reindex to the well-known primitive triclinic for lysozyme. Knowing this, reindexing is not a viable option, so the update will need to be P1 with ncs (either via explicit coordinates or matrix set).

1 0

anomalous signal to ~5.1 - 4.5Å
by Damon Wei 15 Dec '22

15 Dec '22

Dear colleagues, During the past few days, I have been trying to perform Experimental Phasing (SAD) using AutoSol. I am really curious to know if any of you have ever had any successful experience for phasing with anomalous signal only to ~5.1 - 4.5Å. In this scenario, will you use the default value (2.38 Å) in the “high-resolution limit” option in AutoSol, or a higher value like ~ 3-4 Å? How will you set the options including NCS copies, thoroughness, and resolution for running HySS? Any replies and help will be greatly appreciated! Best, Damon

2 3

centered triclinic lattice
by Cathy Lawson 14 Dec '22

14 Dec '22

Looking for suggestions — cctbx/phenix seems not to be able to handle a triclinic lattice with centering. Specific Example: PDB entry 1LKS with cell parameters/space group “A 1”: CRYST1 31.970 65.080 27.250 94.57 111.56 82.98 A 1 2 A 1 diagram: http://img.chem.ucl.ac.uk/sgp/large/001bz1.htm <http://img.chem.ucl.ac.uk/sgp/large/001bz1.htm> Are there any other options for working with this data in phenix other than creating an explicit 2nd copy of the coordinates at x, 1/2+y,1/2+z and setting space group to primitive lattice P 1? Thanks in advance.

4 5

Computational Crystallography Newsletter (CCN) submissions
by Nigel Moriarty 05 Dec '22

05 Dec '22

Folks The deadline for submissions to the Computational Crystallography Newsletter (CCN) is 11 JAN 2023. Please consider writing an article of general interest to the community. The Computational Crystallography Newsletter (CCN) is an electronic newsletter for structural biologists, and is published online every 6 months. Feature articles, meeting announcements and reports can be submitted to me at any time for consideration. Submission of text by email or word-processing files using the CCN templates is requested. Cheers Nigel --- Nigel W. Moriarty Building 33R0349, Molecular Biophysics and Integrated Bioimaging Lawrence Berkeley National Laboratory Berkeley, CA 94720-8235 Email : NWMoriarty(a)LBL.gov Web : CCI.LBL.gov ORCID : orcid.org/0000-0001-8857-9464

1 0

Reminder - 3rd CCP4/BGU workshop on Data Collection and Structure Determination
by Anat Shahar 05 Dec '22

05 Dec '22

Dear All, We would like to remind you that the registration deadline for the 3rd CCP4/BGU workshop on Data Collection and Structure Determination is on 20th December. You are all welcome to hurry up and ensure your place. The 3rd CCP4/BGU Workshop on Data Collection and Structure Determination, will take place at Ben-Gurion University of the Negev (BGU) in Beer-Sheva, Israel, between 26th February to 1st March, 2023. The workshop is limited to 25 participants, and everybody who is interested is welcome to apply. The workshop program will be suitable for last-year PhD students, as well as postdoctoral researchers and young scientists in their first years of research. The workshop will concentrate on practical aspects of data collection, structure solution, model building, refinement and validation. Modern methods, benefiting from structure prediction with AlphaFold-2, as well as more traditional approaches to Molecular Replacement and Experimental Phasing will be considered in detail. In addition, all participants will have an opportunity to carry out remote data collection at Diamond Light Source on their own samples. A team of leading structural biology software developers from around the world will present lectures and tutorials and will also be available to help participants with their own projects, such as processing own data and solving structures during hands-on sessions of the workshop. More information, including “how to apply”, registration form and tentative program, can be found at: https://lifewp.bgu.ac.il/wp/ccp4workshop/ Best wishes, Anat Shahar & Eugene Krissinel [cid:[email protected]] Anat Shahar, PhD Macromolecular Crystallography Research Center (MCRC) Ilse Katz Institute for Nanoscale Science & Technology Ben-Gurion University of the Negev Beer-Sheva, Israel Tel: +972-8-6461807 Web: www.bgu.ac.il/crystallography<http://www.bgu.ac.il/crystallography>

1 0