Dear all,
On Mon, Jul 11, 2022 at 03:12:02PM +0000, Carrapa Nunes Dias, Joao Miguel wrote:
> I had a similar case and I solved it using the PDB tool pdb_extract from:
> https://pdb-extract.wwpdb.org/
> PDB Extract is a pre-deposition service for assembling structure files for
> wwPDB OneDep deposition .
That is an option, yes - you might need to check what exactly you are
trying to solve here: overcoming some warning message from the PDB
deposition software or ensuring that the correct, complete and well
annotated reflection data is deposited at the PDB (while obviously
satisfying the deposition system requirements at the same time).
If at all possible, one should always use the deposition-ready
PDBx/mmCIF files that are produced by the relevant
software. E.g. autoPROC/STARANISO will produce such a file
(Data_1_autoPROC_STARANISO_all.cif) for the processing
stage. Refinement programs will also create such files
(e.g. BUSTER_refln.cif for BUSTER): the "only" thing a user needs to
do then, is to combine those two reflection files (the one from
processing and the one from refinement) before deposition. In the end
we would all like to have the following data available for a PDB entry
(going backwards):
* the refinement results in terms of map coefficients: so we can see
what map the model is supposed to represent
* the data that went into refinement: so we can potentially (re)refine
* the original, scaled+merged reflection data (with isotropic or
anisotropic cut-off): in case some data selection happened during
refinement
* the original, scaled+merged reflection data without any cut-off:
to c heck if the applied cut-off could be improved
* the original, scaled+unmerged reflection data: to maybe improve
upon scaling and outlier rejection
If you were within the Global Phasing software package: we provide a
tool (aB_deposition_combine) to synchronise the refinement mmCIF with
the processing one and create a single reflection mmCIF file
containing all of the above.
(Ideally, the the raw diffaction images could be deposited too: to
enable users to redo the full processing).
> You have a pdb and you have a mtz file, then you should be able to
> convert them to the latest mmcif format.
There are various tools out there for such a conversion - but often
they concentrate on a single data block only. The result could be that
e.g. the MTZ file after refinement doesn't contain the original data
that was used for refinement, but a re-scaled version (maybe even with
some reflections rejected). Even if MTZ column names are identical,
the values might not be ("mtzdmp some.mtz -n 100" et al is your friend
here for checking).
> After that you can deposit your files in:
> https://deposit-1.wwpdb.org/deposition/
> https://validate-rcsb-2.wwpdb.org/
>
> Since you used anisotropic data and different software, the final
> R/Rfree will likely be different of the estimated during PDB
> validation, and you will have the opportunity to explain it to the
> person from the PDB that will help you during your deposition.
Ideally, the re-computed R/Rfree should actually be identical if using
the deposited Fobs and Fcalc values from the mmCIF file: this is only
a question of recomputing those statistics (see e.g. our "rvalue" tool
in BUSTER).
However, that recomputation usually involves an actual re-refinement
step (even if only a recomputation of bulk solvent contribution and
overall scaling parameters): so the label might be a bit
misleading. There will always be discrepancies due to differences in
parametrisation between different programs. If the same program (and
same version) is used on a deposition with the same set of parameters
(hydrogens, formfactors, TLS etc) you should end up with extremely
similar R/Rfree values.
Using e.g. STARANISO data at that stage of "R/Rfree computation" with
any program should not really create very different R/Rfree values:
those are only ever computed from the observations present, so missing
data doesn't play a role here. There could be differences in the outer
shell value due to different binning methods though ...
> Finally, if you are using PHENIX, BUSTER, REFMAC/CCP4, you can also
> run a last refinement step with the latest version of the software.
That might work: but make sure you are reporting the /actual/
refinement program that did the heavy lifting for you here
... otherwise all depositions will look like being refined with XYZ
just because it produces mmCIF files that the deposition software is
happy about (while program XYZ didn't do anything to actually arrive
at that final model).
Proper annotation of all used software is important: not necessarily
for users of your structure, but for us developers ;-)
> The latest version will ensure that the mmcif format is compatible
> with the PDB. Sometimes older versions of the software will give you
> that type of error.
Indeed: keep your software reasonably up-to-date ;-)
Cheers
Clemens
########################################################################
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/
