- phenixbb - phenix-online.org

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

IUCr meeting in 2023
by Tom Peat 22 Nov '22

22 Nov '22

Hello All, Some of you may have noticed that the deadline for abstract submission for the IUCr meeting in Melbourne, Australia passed just recently. There are reasons for the early deadline, but please forgive us for that. There is an extension/ second call for abstracts which will be advertised in the near future. In the meantime, the portal is still open and you are welcomed and encouraged to continue to submit and register for this conference (where we hope to see many of you). This link should work to get you there: https://icmsaust.eventsair.com/iucr-2023/portal-2 Best regards, Tom

1 0

Fully-funded PhD and two postdoc positions in structural bioinformatics
by Nicholas Pearce 22 Nov '22

22 Nov '22

Hi all, I am currently recruiting for 1 fully-funded PhD and 2 postdoc positions within my new research group at Linköping University in Sweden. Because this is an international board: the PhD position is a 4-year employed position with salary, healthcare coverage, pension, other employment benefits, etc. The starting salary for PhD researchers is 30 500 SEK/month (in 2022). The postdoc positions are initially for 2 years, and salaries for postdocs are negotiated on an individual basis. PhD Student in Structural Bioinformatics (Macromolecular Flexibility & Dynamics) I am looking for a PhD student to develop machine learning and data-science approaches to characterise heterogeneous/disordered regions of crystallographic structures from multi-dataset experiments (fragment screening/multi-temperature/time-resolved experiments), in order to study flexibility and dynamics of these systems. If you have a background in machine learning approaches, and are interested in applying these approaches to biological data, or a background in (computational) structural biology, and looking to further develop your data-science/programming skills, please get in touch! Read more and apply here: https://liu.se/en/work-at-liu/vacancies?rmpage=job&rmjob=20567&rmlang=UK Postdoctoral Researchers in Structural Bioinformatics (Macromolecular Flexibility & Dynamics) I am also looking for two postdoctoral researchers to 1) develop and deploy methods for quantifying and analysing flexibility in macromolecular structures using machine learning approaches, and 2) develop new modelling and refinement protocols for structures from multi-dataset experiments (fragment screening/multi-temperature/time-resolved experiments) that enable visualisation and quantitative analysis of weak features in multi-dataset macromolecular structural data. Once more, please don’t hesitate to get in touch if you have questions about the positions! Read more and apply here: Position 1: https://liu.se/en/work-at-liu/vacancies?rmpage=job&rmjob=20513&rmlang=UK Position 2: https://liu.se/en/work-at-liu/vacancies?rmpage=job&rmjob=20539&rmlang=UK About the research group In the Data-Driven Determination of Macromolecular Structures (d3ms) group at Linköping University, we develop data-driven methodologies for determining and analysing macromolecular structures, focussing on structural disorder and dynamics in the context of biomedical applications. One of our primary focuses is the development of multi-dataset and integrative approaches which take advantage of ever-increasing data-collection capacities in both crystallographic and cryoEM experiments. This subject area means we use a variety of statistical, data science & machine learning approaches. The group website can be found here: macromolecular.github.io<https://macromolecular.github.io/> We are based in the bioinformatics division within the department of Physics, Chemistry and Biology (IFM) at Linköping University. Our research group is part of the Data-Driven Life Sciences (DDLS) program and the SciLifeLab national network, providing access to national computational resources, expertise and training opportunities. The location of the Swedish national supercomputer centre on the Linköping university campus provides additional access to computational resources. The SciLifeLab and Wallenberg National Program for Data-Driven Life Science (DDLS) is a 12-year initiative funded with a total of 3,1 billion SEK (~300M€) from the Knut and Alice Wallenberg Foundation. The purpose of the program is to recruit and train the next-generation of data-driven life scientists and to create globally leading computational and data science capabilities in life science in Sweden. The program is coordinated by SciLifeLab, a nationwide research infrastructure and a hub for cross-disciplinary life sciences. The DDLS program promotes collaborative interdisciplinary work and engagement with industry, healthcare and other national and international partners, such as WASP, with the aim of bridging the life science and data science communities. Please feel free to forward this to anyone you think might be interested in the position, Thanks, Nick Nicholas (Nick) Pearce | Assistant Professor in Bioinformatics SciLifeLab Data-Driven Life Sciences (DDLS) Fellow Linköping University, Sweden nicholas.pearce(a)liu.se<mailto:[email protected]> | macromolecular.science<http://www.macromolecular.science/> or macromolecular.github.io<https://macromolecular.github.io/>

1 0

Isolate Protofilament from helical reconstruction
by Christian Tüting 09 Nov '22

09 Nov '22

Dear PHENIX mailing list, I have a question regarding a helical reconstruction, done in cryoSPARC. Usually, I work with "normal" symmetric particles, and there I can simply run phenix.map_box to isolate the asymmetric unit. This is somehow not possible with a helical map. As we also don't have an atomic model yet, we cannot just crop it with map_box. In our helical reconstruction, we have helical twist (in degree) and the helical rise (in Å) and a additional point group symmetry. We would like to isolate a single protofilament for further model building. Is this in principle possible in PHENIX? Additionally, is there a way to rebuild the helical structure, analogous to apply_ncs? Thanks Christian

2 1

Douse adding waters with overlapping residue number
by Adrián González López 02 Nov '22

02 Nov '22

Dear phenix developers, When I run phenix.douse it assigns the waters to the closest chain, but it also attributes them the residue number 0, 1, 2, 3, 4…. which overlaps with the protein residues. Is this a bug? My workaround is to run phenix.sort_hetatms right after and it renumbers them correctly. I am on phenix version 1.20.1-4487-000 Thanks! 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

1 0