Dear all,
On Mon, Jun 01, 2020 at 11:48:41PM +0200, vincent Chaptal wrote:
> since I've been contacted off line several times about this, I'm
> posting here the protocol to combine maps with 2 mtz files of
> original and truncated data.
If this is of wider interest (and since some of our tools for doing
this were mentioned), maybe we can also give a bit of additional
background information and provide some outlook.
> I went through this procedure as I wanted to include the maps, and
> this was the tricky part of the procedure in my hands. This way,
> everyone can look at the same maps when critically assessing a
> structure (especially in the context of redo-ing and severe
> anisotropy).
I think it is a very good idea to also include into the deposition the
maps that were used/seen during model building/refinement. After all,
these were the basis for the interpretation that produced the final
model and the conclusions drawn fom it in a publication. Of course,
one can always re-create similar maps through some external
(re-)refinement approach (be that PDB-REDO or manually using your own
favourite program). Those maps might be similar, better, worse or just
different, perhaps providing added value and additional information -
but it can be difficult to get the exact same maps as seen by the
depositor, due e.g. to different program versions, or to not using the
exact commands and/or parameter settings etc.
Then there is the question of the handling of missing data in 2mFo-DFc
maps (ignoring it, filling it with DFc up to the highest spherical
diffraction limit, or filling it only within the ellipsoidal model of
anisotropy given by STARANISO). BUSTER will create a single mmCIF file
containing all those different map coefficients in separate data
loops. Other programs are most likely to be doing the same. The
important point is that current refinement programs should generate a
single mmCIF file containing all reflection data (and meta-data)
available at the point of refinement - something we are all working
hard at within the PDBx/mmCIF working group. So the task (as described
below) is then to combine this set of reflection data (all nicely
self-contained from model refinement) with the full set of reflection
data (and meta data) from data processing. There are various caveats
and traps one has to consider here (different indexing possibilities,
different cell settings and conventions, enantiomorphs, initially
unassigned screw axes, C2 vs. I2, H3 vs. R3, etc).
Ideally we want an application that takes the two (self-contained)
mmCIF files from data-processing and model refinement, and combines
them in a consistent way, robustly taking care of all of the above
potential issues. Because there often is a large time-gap between
original data-processing and final structure deposition, a lot of
additional checks need to be in place to avoid picking up the wrong
files by accident. This is precisely what we are currently working on
and hope to provide in one of our next releases: a tool working
ideally directly on mmCIF files produced by any data processing
package and any refinement program, that will combine these in a
consistent and validated manner. We hope that will become useful - not
only to users of autoPROC/STARANISO and BUSTER, but also to people who
use multiple different packages in their workflow.
Cheers
Clemens
> In a new directory, put all 3 mtz files (original Intentisties, merged
> staraniso reflections, maps from buster)
>
> /PATH_TO-DIR/BUSTER/Refine45/autoPROC/.
>
> aP_deposition_prep -p combine -r maps.mtz -f staraniso_output.mtz -a
> Original_Intensities.mtz >aP_deposition_prep.log
>
> It creates combine_all.cif
>
> This file has everything but it has a “refln” naming issue.
>
> To fix the “refln” issue:
>
> cat combine_all.cif | sed -e "s/refln.F_sigma /refln.F_meas_sigma /g" -e
> "s%[ ]* #.*from dataset.*%%g" | awk
> '/^#/{if(s){print;next};c++;a[c]=$0;next}/^data/{print;if(s)next;s=1;for(i=1;i<=c;i++){print
> a[i]}next}{print}' > combine_all_refln_fixed.cif
>
> DONE.
>
>
> Best
> Vincent
> ps: again, the credit of this script goes to the globalphasing team who
> kindly helped when I asked them for help with it.
>
>
>
> Le 01/06/2020 à 11:47, Clemens Vonrhein a écrit :
> > Dear all,
> >
> > On Sat, May 30, 2020 at 03:40:53PM +0100, Eleanor Dodson wrote:
> > > My pennysworth. If you find your maps look better after the
> > > anisotroy correction use it, but it may be helpful to those wo want to
> > > mine
> > > your data if you deposit the whole sphere..
> > Agree (which is what e.g. we provide when using STARANISO via autoPROC
> > [1]).
> >
> > And in the same vein: those depositing isotropically truncated data
> > should consider also providing data to a higher diffraction limit to
> > give a potentially more accurate picture (if there is even a slight
> > indication of anisotropy - which there often is).
> >
> > I find it very helpful even looking at an idealised (and therefore
> > simplified) picture of anisotropy as in
> >
> > http://staraniso.globalphasing.org/anisotropy_about.html
> >
> > We can consider
> >
> > (1) for refinement:
> >
> > (1a) green+red, i.e. spherical (i.e. isotropically) truncated
> > data
> >
> > (1b) green+blue, i.e. anisotropycally truncated data
> >
> > (2) for deposition:
> >
> > (2a) green+red => full sphere, but dropping real observations
> > (blue)
> >
> > (2b) green+blue => all observations, but not providing
> > insignificant/weak data (red) in all directions
> >
> > (2c) a sphere to the "tip" of blue (i.e. anisotropic diffraction
> > limit) => all observations and all insignificant/weak data
> >
> > Cheers
> >
> > Clemens
> >
> > [1] https://www.globalphasing.com/autoproc/ - which gives a mmCIF file
> > with (2a), (2b) and (2c) ready for deposition.
> >
> >
> > > eleanor
> > >
> > > On Sat, 30 May 2020 at 09:36, Robbie Joosten <robbie_joos...@hotmail.com>
> > > wrote:
> > >
> > > > Hi Everyone,
> > > >
> > > > I've been looking at some recent PDB entries that have much lower
> > > > spherical) completeness than reported in the coordinate file. One reason
> > > > for this is that the data were anisotropicly truncated, another reason
> > > > is
> > > > some mess-up with the deposition of the reflection data. There is a lot
> > > > of
> > > > discussion about the former practice and I don't want to go in to that,
> > > > but
> > > > the second one is obviously an error. Now how do I distinguish these
> > > > cases?
> > > >
> > > > Sometimes, you can look at the reported number of reflections and
> > > > compare
> > > > that to the deposited reflection file and you will find that something
> > > > has
> > > > clearly gone wrong. However, the reported number of reflections is not
> > > > entirely reliable because of other issues so I'd rather not use it. If
> > > > you
> > > > use PDBpeep (e.g. for 6rjy) you can see something is wrong, but that is
> > > > completely visual. Is there a tool in CCP4 that reports both spherical
> > > > and
> > > > ellipsoidal completeness (on merged reflection data)? That would make it
> > > > easy to distinguish such cases.
> > > >
> > > > Cheers,
> > > > Robbie
--
*--------------------------------------------------------------
* Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com
* Global Phasing Ltd., Sheraton House, Castle Park
* Cambridge CB3 0AX, UK www.globalphasing.com
*--------------------------------------------------------------
########################################################################
To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list
hosted by www.jiscmail.ac.uk, terms & conditions are available at
https://www.jiscmail.ac.uk/policyandsecurity/
