Dear Vincent,
Thank you for chipping in as you did, with so much useful feedback
about the difficulty of re-using PDB depositions containing anisotropic
data. It is a very useful picture of what is definitely a "bleeding edge" on
the "R" side of the wwPDB's "FAIR" ideal.
It would be most helpful if you could share with us (off-line) the
details of the specific problems you encountered and that led to the odd
recommendation that you should use a text editor to combine the contents of
mmCIF files.
It is interesting that you used the turn of phrase "huge anisotropy
combined with lack of completeness in high resolution shells" as if they
were two distinct evils that had conspired to combine in order to make your
life difficult. In reality, as you are of course well aware, they are one
and the same evil, as strong anisotropy will necessarily result in low
completeness in the *spherical* shell to the highest diffraction limit. The
diagram at the beginning of the page
https://staraniso.globalphasing.org/anisotropy_about.html
makes this totally obvious. The only way to have full completeness in the
outermost (spherical) shell is to have isotropic diffraction. Forgive me for
perhaps belabouring something you are perfectly aware of, but it provided an
opportunity to push back against "isotropic thinking" that is still so
deeply ingrained in the collective worldview.
With best wishes,
Gerard.
--
On Fri, Feb 16, 2024 at 09:59:59AM +0100, vincent Chaptal wrote:
> Hi Clemens and all,
>
> I've been following with a lot of interest of course, anisotropy has
> taken a lot of space in my membrane-protein crystallography life.
> I remember the many exchanges we've had with you and Global Phasing,
> as well as many other software developpers over the years.
>
> I would like to chip in to give the point of view of a user
> struggling with it, and since 6r72 was mentioned and I'm the
> author...
>
> 6r72 has been an epic battle experimentally, and afterwards with
> data processing as well. The huge anisotropy combined with lack of
> completeness in high resolution shells, and low resolution, made a
> cocktail for not so great electron density. But since this was all I
> got, I had to make something out of it. Since the quality of the
> data was what it was, I definitely wanted others to be able to
> re-investigate it with modern tools, or just see for themselves the
> map I had to make the choices in modelling.
> Remember, I asked for your help to combine all the data of the
> entry, and GlobalPhasing was very helpful to make the tool for this
> entry. I believe, this was the moment you created the deposition
> tool you mention below.
>
> The fact that the data is not easily retrievable is my point here.
> Pavel knows about this entry as we've been exchanging about it. I
> completely share with him the difficulty to parse through PDB
> entries, having performed several statistical analysis of the PDB to
> search for the root cause of anisotropy in membrane proteins myself
> (https://pubmed.ncbi.nlm.nih.gov/36206830/).
> I encountered the same issue for a recent entry (8qq7, soon
> available I hope) where we tried to combine the same files. I
> vaguely remembered the deposition tool you mention but I couldn't
> locate it (sorry), so we engaged in a dialog with the PDB who made
> us use text editors to merge the files basically. On the top of my
> head, I think we labelled the blocks "original_data", "modified_SA".
>
> A standardization of this deposition is basically what you all want,
> to perform all the different downstream analysis you want. This is
> not available at the moment. I've been going out of my way to
> combine the files, but it would have been much easier to just give
> the SA_modified file to the PDB. I thus encourage all of you
> software developpers, despite your different point of views, to
> design and agree on such a tool to be placed at OneDep.
>
> To finish, in case you want to reprocess a high-anisotropy, large
> difference in high-resolution limits, and low resolution, I have the
> images available for 6r72, 2y5y, and 8qq7 (all of which have the
> structure factors with original data, maps and modified data).
>
> All the best
> Vincent
>
> Le 15/02/2024 à 19:25, Clemens Vonrhein a écrit :
> >L'adresse mail de l'expéditeur est extérieure :owner-ccp...@jiscmail.ac.uk
> >En cas de doute : ne répondez pas, ne cliquez pas et signalez le message au
> >Support Informatique
> >
> >
> >Dear Pavel & CCP4bb readers,
> >
> >On Wed, Feb 14, 2024 at 08:28:03PM -0800, Pavel Afonine wrote:
> >>What follows below is not very specific to the particular program
> >>(STAIRSANISO) nor the original questions, but nonetheless, I believe it is
> >>relevant.
> >Thanks for joining the discussion: always good to have different viewpoints
> >or opinions made visible - especially for less knowledgeable users and
> >readers of the CCP4bb.
> >
> >And apologies to anyone getting tired of "another long post" here, but
> >some remarks do require follow-ups that hopefully will help keep the
> >discussion at a level useful to all readers.
> >
> >>In the past, performing any adjustments to the diffraction data intended
> >>for solving and refining atomic models was more or less considered taboo.
> >That is a very broad statement that I have trouble making sense of: what do
> >you mean with "adjustments" and what do you mean with "diffraction data"?
> >If we are truly looking at diffraction data as it comes out of our
> >experiment, we are looking at the raw images, right? Those are then
> >handled roughly as follows (as an example for MX):
> >
> > * initial integrated intensities (simplifying 3D pixel data)
> > * profile fitting of integrated intensities
> >
> > * scaling (with various parametrisation models)
> >
> > * selection of data (excluding image ranges due to radiation damage or
> > because a crystal moves out of the beam, excluding/handling ice-ring
> > contamination, selecting datasets in SSX etc)
> >
> > * adjustment of error model (to get "meaningful" error estimates,
> > i.e. sigma values)
> >
> > * outlier rejection (based largely on those sigmas)
> >
> > * merging (inverse-variance weighted)
> >
> >Maybe all those "adjustments to the diffraction data" are not what you are
> >referring to in your remark above? So let's assume you are referring to the
> >merged intensity data after all of the above steps as being "the
> >diffraction data" ... and what we are doing after that:
> >
> > * conversion from intensities to amplitudes (using different methods and
> > priors) which most often will include an adjustment of weak and
> > negative intensities (e.g. via the French & Wilson method [1]).
> >
> > * decision what reflections to use for subsequent steps
> >
> > - defined by geometric constraints (we can only use those that hit the
> > detector)
> >
> > - defined by some significance criterion
> >
> > resulting in an adjustment of the dataset (not the values themselves)
> > coming out of the raw diffraction data.
> >
> >Maybe this is still not what you are referring to as "adjustments to
> >the diffraction data"? Let's see what additional "adjustments to the
> >diffraction data" might happen further along ...
> >
> > * anisotropic scaling of the diffraction data /without/ the use of any
> > atomic model, as provided e.g. by
> >
> > - the UCLA Anisotropy Server [2,3], using the anisotropy analysis
> > from Phaser [4]
> >
> > - STARANISO [5], using its own analysis
> >
> > * relative anisotropic scaling of the diffraction data and the current
> > model in refinement, e.g. in
> >
> > - REFMAC [6,7]
> >
> > Note: this includes writing a set of observed amplitudes into the
> > output MTZ file that have been corrected using the model-based
> > overall anisotropy factors (as far we know and at least up to
> > version 5.8.0352). So any "structure factor" deposition using only
> > the output reflection data from such a run will have anisotropy
> > corrected observed observed data in the PDB archive. Our
> > aB_deposition_combine tool described below detects and undoes this
> > (when combining the reflection mmCIF data from processing with the
> > reflection data after refinement) to ensure that data exactly as
> > used as /input/ to the refinement program is deposited.
> >
> > - CCTBX [8] and Phenix [9,10]
> >
> > - SHELX [11,12,13]
> >
> > - BUSTER [14]
> >
> > * classification and rejection of model-based outlier reflections
> >
> > - in Phenix [15] (still default?)
> >
> > * DFc completion for missing observations in 2mFo-DFc electron density
> > maps
> >
> > - default in REFMAC (into single FWT/PHWT by default as far as we know)
> >
> > - default in Phenix (into an additional set of map coefficients?)
> >
> > - default in BUSTER (into two additional sets of map coefficients,
> > 2FOFCWT_iso-fill/PH2FOFCWT_iso-fill using a sphere and
> > 2FOFCWT_aniso-fill/PH2FOFCWT_aniso-fill using the anisotropic cut-off
> > information from STARANISO).
> >
> >Which of all of the above are you referring to as being "considered taboo"?
> >It would be helpful if you could clarify this so that we can then focus on
> >that particular point in our discussion.
> >
> >>When cryo-EM emerged as a competitor to x-ray crystallography, the paradigm
> >>began to shift. In cryo-EM, manipulations applied to the data (the map) are
> >>a standard practice. The map can be boxed, filtered (sharpened, blurred,
> >>etc.), modified (e.g., setting something outside the molecular region), and
> >>so forth; you name it. One might wonder why the same isn't done to x-ray
> >>data.
> >I don't think it is true that this "isn't done to x-ray data":
> >
> > * In small-molecule crystallography the "SQUEEZE" procedure [16] exists,
> > that does modify the diffraction data
> >
> > * Electron-density sharpening [17] is widely used/described [18,19]
> >
> >>Historical analogies include truncating data beyond 6-8Å resolution
> >>to avoid dealing with the bulk solvent
> >Maybe that should be rephrased from
> >
> > ... truncating data beyond 6-8Å resolution to avoid dealing with the bulk
> > solvent ...
> >
> >to
> >
> > ... truncating data below 6-8Å resolution because we couldn't deal with
> > the bulk solvent at the time (but once we could [20], there was no longer
> > a need for that) ...
> >
> >That's then a fairly normal evolution of science/methods: we do the best we
> >can at a given time with the tools at our disposal while trying to develop
> >better methods that might complement or replace those existing tools.
> >
> >>or default sharpening (a feature available in X-plor for some time,
> >>then removed for obvious reasons, AFAIK), choosing resolution limits
> >>(PAIRREF), and anisotropic data massaging by the UCLA server as a
> >>more recent example. STAIRSANISO is the leader in doing things along
> >>these lines as of today.
> >Your wording here makes it very difficult to take that serious: describing
> >the whole range of features provided by STARANISO (sic) as "massaging data"
> >takes us into the quicksands of polemics ... I'm sure we can do better than
> >that.
> >
> >Which component are you critisizing here exactly? Maybe by being a bit more
> >explicit we can have a scientific discussion about those items and come to
> >some understanding (or agree to disagree) that is useful to the average
> >reader of these CCP4bb threads. We have:
> >
> > (1) The analysis of anisotropy in the data (as also provided by
> > e.g. Phaser [4] or ctruncate [21])?
> >
> > (2) The selection of reflection data without an isotropic constraint (that
> > would be leading to a spherical cut-off)?
> >
> > ==> this can be switched off on the STARANISO server [22]
> >
> > (3) The anisotropic scaling/correction of the data according to the
> > analysis in (1)?
> >
> > ==> this can be switched off on the STARANISO server [22]
> >
> >We've chosen defaults in STARANISO (if run through autoPROC or through the
> >server) that we feel make the most sense in our hands and are based on a
> >lot of user feedback. We don't force users to stick with those defaults or
> >to use STARANISO in the first place.
> >
> >>Indeed, why not if this is helpful to solve the structure?
> >Exactly: up to the point where STARANISO provides reflection data, no
> >notion of a structural model has entered any of the computations. If a
> >particular method of processing the raw diffraction data (images) leads to
> >a model and electron density map that shows more information and allows for
> >better interpretation and correction of that model, it clearly suggests to
> >me that it provides a higher information content and is useful for that
> >purpose.
> >
> >This has to be seen obviously in the context of the methods, programs and
> >parametrisations we currently use: nothing is set in stone and new
> >developments will come along that make current approaches redundant at some
> >stage in the future ... it's called "progress" ;-)
> >
> >>However, it's important that the deposition clearly contains and
> >>annotates at least the following:
> >>
> >>- the original unmanipulated data;
> >>- modified data (by whatever method or program);
> >>- accessible information about the data that was used to obtain the final
> >>deposited atomic model.
> >Completely agree with you (even if I would choose "unmodified" instead of
> >"unmanipulated" here: choice of words matter and we should stay as neutral
> >as possible I think).
> >
> >That is exactly the reason why autoPROC/STARANISO is providing a
> >deposition-ready PDBx/mmCIF files by default since the March 2019 release
> >[23]. We are trying to explain the usage of those in great detail [24], but
> >users are often not aware of those files if dtheir data were auto-processed
> >at synchrotrons [25] (the presentation of autoPROC/STARANISO results/files
> >is not always complete and could be improved upon).
> >
> >There are several issues a normal user has to deal with when it comes to
> >PDB deposition:
> >
> > * There is often a significant time lag between data collection (and
> > probably processing) and deposition: this was on average about 2.5 years
> > the last time I checked this. Making sure that the model and reflection
> > data from the final refinement steps are correctly associated with the
> > original data processing can become tricky (which is why we provide the
> > "aB_deposition_combine" tool to help users, [24]).
> >
> > * Historical baggage that seems impossible to get rid of. I'm especially
> > thinking of the requirement (by the OneDep system, as far as I
> > understand) for the data quality metrics (i.e. those statistics that
> > describe the reflection data) to be part of the model mmCIF file. This
> > basically goes back to the time when deposition of "structure factor"
> > (sic) data was not compulsory (pre Feb 2008) and these items had to be in
> > the model file.
> >
> > With the use of mmCIF files for the model /and/ the reflection data
> > during deposition, that requirement should not be necessary anymore. It
> > would especially avoid the use of data-preparation tools that try and
> > extract some values from a variety of logfiles with the intrinsic
> > problems this entails:
> >
> > - these logfiles are by definition separate from the reflection file
> > with the danger of encountering mix-ups;
> >
> > - they are completely unstructured and could (and do) change at will -
> > while a mmCIF file is structured and can be validated (for format
> > mainly, but also somewhat for content) against an official mmCIF
> > dictionary;
> >
> > * The guidance - by documentation and deposition systems - concerning what
> > is the best to provide the correct information in the correct format to
> > the deposition software is too long, too scattered, not detailed enough,
> > confusing, contradictory etc. We could all do much better here I guess
> > and ensure that at deposition time users need to deal primarily with the
> > correct scientific content of a deposition and not with format and
> > format-validation questions. The latter often seem to end up forcing
> > users to deposit "something" - often under stress - as long as it goes
> > through those checks and they can move on.
> >
> > * The uncanny power of sloppy throw-away remarks. I remember the times
> > when everyone said "SHARP is slow and only needed as a last resort for
> > really difficult cases." (for the novice readers: SHARP is a program for
> > experimental phasing). Yes, it was slow back in the early 90s on SGI
> > workstations etc, because it does some pretty extensive
> > computations. For the last 20 years though, it is now usually running in
> > seconds on nearly all problems and is by far the fastest step during a
> > typical experimental phasing experiment (site detection, density
> > modification and automatic building are MUCH slower). But we still hear
> > the same old remarks ...
> >
> > Or we could look at the discussion about Rmerge (and how we still see it
> > in depositions and papers and have reviewers commenting on it being too
> > high) ... 25 years after the papers pointing out its flaws?
> >
> > Now we often hear questions about "can I deposit STARANISO data", with
> > extremely little scientific reasoning why one couldn't or shouldn't. It
> > all seems to be based on some fear that powerful referees, PIs or well
> > known experts will complain about this at some point. These don't seem
> > like very good reasons for doing or not doing something if it otherwise
> > seems sound to the actual user, but pushing back against that external
> > pressure as a new or one-off crystallographer is really hard. It is up
> > to us (so-called) "experts" to be aware of the power we wield here - and
> > use it wisely.
> >
> > By all means, have a scientific argument with us and show everyone why
> > some of our methods are not doing the right thing or is buggy. We'd be
> > the first to welcome any such comments because ultimately they lead to
> > improved methods and programs for everyone. But remarks like "data
> > massaging" or "manipulated" have a real negative impact without adding
> > anything to such a discussion ...
> >
> >The bottom line for our software [24]: it should be trivial to provide (a)
> >the deposition-ready model mmCIF file (coming from Phenix, REFMAC or
> >BUSTER) that contains the correct data quality metrics, and (b) a
> >deposition-ready reflection data mmCIF file including all the above
> >datablocks described by Pavel.
> >
> >>Note *accessible* above as this is the key for what follows below.
> >>
> >>Let's consider this example:https://files.rcsb.org/download/6R72-sf.cif ,
> >>which is representative of the class of problems I'm trying to convey here.
> >That is one example (but maybe not a good one, see below) - maybe a better
> >one would e.g. be 8ar7.
> >
> >>The file has everything, kudos to the authors: The original data, the
> >>manipulated data and a whole lot more.
> >>
> >>Are these data accessible?
> >>
> >>YES, if you download the file, open it in your favorite text editor, and
> >>carefully scroll and read through its 76,566 lines and use your best guess
> >>to infer what are the original data arrays, what are the modified data
> >>arrays and so on.
> >A mmCIF file is not something anyone would want to look at in a text
> >editor! So isn't that more a problem with the software you decided to use
> >for getting and looking at that data? BUSTER provides a simple tool
> >("fetch_PDB_gemmi") that will fetch a PDB entry and not only extract the
> >reflection data for each block, but also the explanations they carry. Here
> >is an excerpt of what it reports for the entry you picked (the full output
> >is a bit longer and I didn't want to make this email even less likely to be
> >read):
> >
> > ### merged data block #1 = r6r72sf
> >
> > data as used in refinement and resulting electron density maps.
> > Converted by gemmi-mtz2cif 0.2.0
> >
> > ### merged data block #2 = r6r72Asf
> >
> > merged and scaled data post-processed by for conversion from intensities
> > to structure factor amplitudes.
> >
> > ### merged data block #3 = r6r72Bsf
> >
> > merged and scaled data from AIMLESS without any post-processing and/or
> > data cut-off.
> >
> >The reason I mentioned that 6r72 is not a good example is visible
> >above: somehow the string "STARANISO" got lost in the description
> >(_diffrn.details) of the second data block ... you can see that by the
> >incomplete sentence and the double spaces. If you do the same for 8ar7
> >via
> >
> > fetch_PDB_gemmi 8ar7
> >
> >you get
> >
> > ### merged data block #1 = r8ar7sf
> > data as used in refinement and resulting electron density maps.
> >
> > ### merged data block #2 = r8ar7Asf
> > 2mFo-DFc map coefficients complemented for missing data (as defined by
> > SA_flag from STARANISO).
> >
> > ### merged data block #3 = r8ar7Bsf
> > 2mFo-DFc map coefficients complemented for missing data (within full
> > resolution range).
> >
> > ### merged data block #4 = r8ar7Csf
> > merged and scaled data post-processed by STARANISO for conversion from
> > intensities to structure factor amplitudes and anomalous data.
> >
> > ### merged data block #5 = r8ar7Dsf
> > merged and scaled EARLY (potentially least radiation-damaged) data
> > post-processed by STARANISO for conversion from intensities to structure
> > factor amplitudes - useful for radiation-damage detection/description maps
> > (as e.g. done in BUSTER).
> >
> > ### merged data block #6 = r8ar7Esf
> > merged and scaled LATE (potentially most radiation-damaged) data
> > post-processed by STARANISO for conversion from intensities to structure
> > factor amplitudes - useful for radiation-damage detection/description maps
> > (as e.g. done in BUSTER).
> >
> > ### merged data block #7 = r8ar7Fsf
> > merged and scaled data from AIMLESS without any post-processing and/or
> > data cut-off.
> >
> > ### unmerged data block #8 = r8ar7Gsf
> > unmerged and scaled data from AIMLESS without any post-processing and/or
> > data cut-off
> >
> >and a MTZ file for each of those data blocks. It should be very easy from
> >that to pick any datablock you like based on that description (which
> >unfortunately isn't based on a fixed vocabulary, but that could be added to
> >the mmCIF dictionary if needed).
> >
> >>NO, absolutely NO, if you parse data files in PDB automatically with a
> >>script, and attempt to extract particular data (eg., original unmanipulated
> >>data). And this is what I find problematic, especially given 215+k entries
> >>in PDB as of today.
> >>
> >>Hope someone does something about it!
> >Well, from our side I think we've done already a fair amount here through
> >
> > * our software (creating and combining deposition-ready mmCIF files from
> > processing+refinement and providing a tool to fetch archived PDB
> > entries),
> >
> > * tools like our "Table 1" server [27]
> >
> > * very useful discussions with e.g. the PDBj that has resulted in a much
> > enriched description for the data archived with a given entry [28], and
> >
> > * our work within the PDBx/mmCIF WG [29], especially the Processing
> > Subgroup [30]).
> >
> >If the software systems at your disposal don't provide adequate tools you
> >should probably discuss this with those developers ;-)
> >
> >Once you have defined the "something", the best "someone" is yourself - so
> >feel free to join in productively rather than disparagingly.
> >
> >Cheers
> >
> >Clemens
> >
> >
> >[1] French, S. and Wilson, K., 1978. On the treatment of negative
> > intensity observations. Acta Crystallographica Section A: Crystal
> > Physics, Diffraction, Theoretical and General Crystallography,
> > 34(4), pp.517-525.
> >
> >[2] Sawaya, M.R., 2014. Methods to refine macromolecular structures in
> > cases of severe diffraction anisotropy. Structural Genomics:
> > General Applications, pp.205-214.
> >
> >[3]https://srv.mbi.ucla.edu/Anisoscale/
> >
> >[4] McCoy, A.J., Grosse-Kunstleve, R.W., Adams, P.D., Winn, M.D.,
> > Storoni, L.C. and Read, R.J., 2007. Phaser crystallographic
> > software. Journal of applied crystallography, 40(4), pp.658-674.
> >
> >[5]https://staraniso.globalphasing.org/
> >
> >[6] Murshudov, G.N., Davies, G.J., Isupov, M., Krzywda, S. and Dodson,
> > E.J., 1998. The effect of overall anisotropic scaling in
> > macromolecular refinement. CCP4 newsletter on protein
> > crystallography, 35, pp.37-42.
> >
> >[7] Murshudov, G.N., Skubák, P., Lebedev, A.A., Pannu, N.S., Steiner,
> > R.A., Nicholls, R.A., Winn, M.D., Long, F. and Vagin, A.A.,
> > 2011. REFMAC5 for the refinement of macromolecular crystal
> > structures. Acta Crystallographica Section D: Biological
> > Crystallography, 67(4), pp.355-367.
> >
> >[8] Afonine, P.V., Grosse-Kunstleve, R.W. and Adams, P.D., 2005. A
> > robust bulk-solvent correction and anisotropic scaling
> > procedure. Acta Crystallographica Section D: Biological
> > Crystallography, 61(7), pp.850-855.
> >
> >[9] Afonine, P.V., Grosse-Kunstleve, R.W., Chen, V.B., Headd, J.J.,
> > Moriarty, N.W., Richardson, J.S., Richardson, D.C., Urzhumtsev,
> > A., Zwart, P.H. and Adams, P.D., 2010. phenix. model_vs_data: A
> > high-level tool for the calculation of crystallographic model and
> > data statistics. Journal of applied crystallography, 43(4),
> > pp.669-676.
> >
> >[10] Afonine, P.V., Grosse-Kunstleve, R.W., Adams, P.D. and
> > Urzhumtsev, A., 2013. Bulk-solvent and overall scaling revisited:
> > faster calculations, improved results. Acta Crystallographica
> > Section D: Biological Crystallography, 69(4), pp.625-634.
> >
> > Afonine, P.V., Grosse-Kunstleve, R.W., Adams, P.D. and
> > Urzhumtsev, A., 2023. Bulk-solvent and overall scaling revisited:
> > faster calculations, improved results. Corrigendum. Acta
> > Crystallographica Section D: Structural Biology, 79(7).
> >
> >[11] Shakked, Z., 1983. Anisotropic scaling of three-dimensional
> > intensity data. Acta Crystallographica Section A: Foundations of
> > Crystallography, 39(3), pp.278-279.
> >
> >[12] Pohl, E., Schneider, T.R., Dauter, Z., Schmidt, A., Fritz,
> > H.J. and Sheldrick, G.M., 1999. 1.7 Å structure of the stabilized
> > REIv mutant T39K. Application of local NCS restraints. Acta
> > Crystallographica Section D: Biological Crystallography, 55(6),
> > pp.1158-1167.
> >
> >[13] Sheldrick, G.M., 2012. Macromolecular applications of
> > SHELX. International Tables for Crystallography
> > (2012). Vol. F. ch. 18.9, pp. 529-533.
> >
> >[14] Blanc, E., Roversi, P., Vonrhein, C., Flensburg, C., Lea,
> > S.M. and Bricogne, G., 2004. Refinement of severely incomplete
> > structures with maximum likelihood in BUSTER–TNT. Acta
> > Crystallographica Section D: Biological Crystallography, 60(12),
> > pp.2210-2221.
> >
> >[15]https://phenix-online.org/documentation/faqs/refine.html#general ("Why
> > does phenix.refine not use all data in refinement?") and
> > https://phenix-online.org/pipermail/phenixbb/2010-December/016283.html
> >
> >[16] Spek, A.L., 2015. PLATON SQUEEZE: a tool for the calculation of
> > the disordered solvent contribution to the calculated structure
> > factors. Acta Crystallographica Section C: Structural Chemistry,
> > 71(1), pp.9-18.
> >
> >[17] DeLaBarre, B. and Brunger, A.T., 2006. Considerations for the
> > refinement of low-resolution crystal structures. Acta
> > Crystallographica Section D: Biological Crystallography, 62(8),
> > pp.923-932.
> >
> >[18] Liu, C. and Xiong, Y., 2014. Electron density sharpening as a
> > general technique in crystallographic studies. Journal of
> > molecular biology, 426(4), pp.980-993.
> >
> >[19] Terwilliger, T.C., Sobolev, O.V., Afonine, P.V. and Adams, P.D.,
> > 2018. Automated map sharpening by maximization of detail and
> > connectivity. Acta Crystallographica Section D: Structural
> > Biology, 74(6), pp.545-559.
> >
> >[20] Jiang, J.S. and Brünger, A.T., 1994. Protein hydration observed
> > by X-ray diffraction: solvation properties of penicillopepsin and
> > neuraminidase crystal structures. Journal of molecular biology,
> > 243(1), pp.100-115.
> >
> >[21]https://www.ccp4.ac.uk/html/ctruncate.html
> >
> >[22]https://staraniso.globalphasing.org/
> >
> >[23]https://www.globalphasing.com/autoproc/ReleaseNotes/ReleaseNotes-autoPROC_snapshot_20190301.txt
> >
> >[24]https://www.globalphasing.com/buster/wiki/index.cgi?DepositionMmCif
> >
> >[25]https://www.globalphasing.com/autoproc/wiki/index.cgi?RunningAutoProcAtSynchrotrons
> >
> >[26]https://www.globalphasing.com/buster/
> >
> >[27]https://staraniso.globalphasing.org/table1/
> > (e.g.https://staraniso.globalphasing.org/table1/ar/8ar7.html)
> >
> >[28]https://pdbj.org/mine/experimental_details/8AR7
> >
> >[29]https://www.wwpdb.org/task/mmcif
> >
> >[30]https://github.com/pdbxmmcifwg/mmcif-data-proc
> >
>
> --
>
> Vincent Chaptal, PhD
>
> Director of GdR APPICOM
>
> Drug Resistance and Membrane Proteins Lab
>
>
> MMSB -UMR5086
>
> 7 passage du Vercors
>
> 69007 LYON
>
> FRANCE
>
> +33 4 37 65 29 01
>
> http://www.appicom.cnrs.fr
>
> http://mmsb.cnrs.fr/en/
>
>
> ########################################################################
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?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/
########################################################################
To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?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/
