Repository navigation
Resolution lost in cryo-EM #1000
Description
Several entries have the resolution value set to 99 when obtained from PDB and 0 when obtained from mmCif.
Each was cryo-EM with resolutions in the range 3.35 - 3.8 Å.
4 examples are
(3j8h, 3jaj (available only in mmCIF).
6hu9, 7o3e (available as PDB files).
By experimenting, I found that
- The PDB entries have the resolution reported in REMAK 2 (not parsed at all) and in REMARK 3 (using a format not recognized by the
PDBFileParser). --> they are left as the default resolution value (99). - The mmCif entries have the
.value in the_refine.ls_d_res_highfield, which indicates that the value may be used to identify that there is no appropriate value for the item or that a value has been intentionally omitted (I don't know why omitted) --> when the period (.) is parsed intofloat, it is wrongly parsed as (0.0)
Activity
aalhossary commentedon Nov 27, 2021
Proposed solutions:
_refine.ls_d_res_highfield.) is dealt with in this field, unless this ZERO is an intended outcome. Is it?josemduarte commentedon Dec 2, 2021
One issue here is that the PDB format doesn't seem to be standardised regarding REMARK 3. See:
https://www.wwpdb.org/documentation/file-format-content/format33/remark3.html . So parsing it would be nice, but won't necessarily cover all cases. Anyway I suppose that's a problem of the legacy PDB format and another reason to continue decreasing its usage.
The real issue here is that there's a different field to get the resolution for cryoEM method:
_em_3d_reconstruction.resolution. So in principle the mmCIF parser should be using the resolution value from there if available (which would indicate that the method is EM). The field_refine.ls_d_res_highis for diffraction methods only.aalhossary commentedon Dec 6, 2021
I submitted a pull request to fix that.
However, a new question arises:
There are cases where the resolution is unknown (the
_em_3d_reconstruction.resolutionvalue is a?). In that case, should the default value be 0.0 or 99?Some examples include
josemduarte commentedon Dec 6, 2021
I suppose it'd be ok to stay with 99, since that's the expected behaviour looking at the code. The rationale behind it is that filtering on resolution would work as naturally expected (resolution<2 would filter out all the unknown resolution cases).
In any case, it'd be good to document it. Could you add a brief explanation to
PDBHeader.getResolution()?aalhossary commentedon Dec 7, 2021
Both done.
Add electron density and cryo-EM map fetching with a fallback chain
Add electron density and cryo-EM map fetching with a fallback chain
Add electron density and cryo-EM map fetching with a fallback chain