<div dir="ltr">Dear Edwin,<div><br></div><div>Thank you for pointing it out!</div><div><br></div><div>It was oversight in procedure for creating internal model representation from mmCIF files in cctbx library. I'm happy to report that this has been fixed and newer versions of Phenix (after 3254) and cctbx library should behave as expected.</div><div><br></div><div>Cctbx uses its own tools to parse mmCIF, so I don't know if this corner-case could be an issue for other libraries/software.</div><div><br></div><div>Best regards,</div><div>Oleg Sobolev.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 5, 2018 at 1:35 PM, Edwin Pozharski <span dir="ltr"><<a href="mailto:pozharskibb@gmail.com" target="_blank">pozharskibb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">There appears to be a bug in phenix.cif_as_pdb. I am looking at a bunch of files that contain very few atoms. When it's more than one, mmcif contains multiple HETATM records in a loop. However, single atom entries seem to encode atomic coordinates in a different way, like so<div><br></div><div><div>#</div><div>_atom_site.group_PDB HETATM</div><div>_<a href="http://atom_site.id" target="_blank">atom_site.id</a> 4905</div><div>_atom_site.type_symbol CA</div><div>_atom_site.label_atom_id CA</div><div>_atom_site.label_alt_id .</div><div>_atom_site.label_comp_id CA</div><div>_atom_site.label_asym_id L</div><div>_atom_site.label_entity_id<span style="white-space:pre-wrap"> </span> 5</div><div>_atom_site.label_seq_id .</div><div>_atom_site.pdbx_PDB_ins_code .</div><div>_atom_site.Cartn_x 0.394</div><div>_atom_site.Cartn_y -6.965</div><div>_atom_site.Cartn_z 18.775</div><div>_atom_site.occupancy 1</div><div>_atom_site.B_iso_or_equiv 2</div><div>_atom_site.pdbx_formal_charge ?</div><div>_atom_site.auth_atom_id CA</div><div>_atom_site.auth_comp_id CA</div><div>_atom_site.auth_asym_id A</div><div>_atom_site.auth_seq_id 701</div><div>_atom_site.pdbx_PDB_model_num 1</div></div><div><br></div><div>This does not include _loop statement and instead lists parameters directly. If I try to convert this to pdb, cif_as_pdb fails like so (and I suspect that pretty much any cif-file read would fail)</div><div><br></div><div><div> Python argument types in</div><div> double.__init__(double, str)</div><div>did not match C++ signature:</div><div> __init__(boost::python::api::<wbr>object, boost::python::numeric::array)</div><div> __init__(boost::python::api::<wbr>object, boost::python::tuple)</div><div> __init__(boost::python::api::<wbr>object, boost::python::list)</div><div> __init__(boost::python::api::<wbr>object, std::vector<double, std::allocator<double> >)</div><div> __init__(boost::python::api::<wbr>object, scitbx::af::const_ref<std::<wbr>string, scitbx::af::trivial_accessor>)</div><div> __init__(_object*, scitbx::af::shared_plain<<wbr>double>)</div><div> __init__(_object*, unsigned long)</div><div> __init__(_object*, unsigned long, double)</div><div> __init__(_object*, scitbx::af::flex_grid<scitbx::<wbr>af::small<long, 10ul> >)</div><div> __init__(_object*, scitbx::af::flex_grid<scitbx::<wbr>af::small<long, 10ul> >, double)</div><div> __init__(_object*)</div></div><div><br></div><div>This has nothing to do with how many atoms are there, obviously - in fact, removing all HETATM records but one from a cif file that has _loop statement does not produce this bug.</div><div><br></div><div>The obvious guess is that the bug is somewhere in mmdb (I am assuming here that phenix relies on it for cif read/write). </div><div><br></div><div>This is not a big deal, of course - in most scenarios, a structure contains more than one atom. It does not interfere with me either - I am discarding single atom cases in this analysis anyway (so it is actually serves as an unintentional filter). </div><div><br></div><div>Still, it looks like a bug. I am not an expert in mmcif format, but iiuc, there is no strict requirement for atom_site category to have a _loop. If there is (I can't find any such syntax requirement), then the source of the data files (PDBe coordinate server) would be at fault for not structuring the data properly.</div><div><br></div><div>Cheers,</div><div><br></div><div>Ed.</div></div></div></div>
<br>______________________________<wbr>_________________<br>
phenixbb mailing list<br>
<a href="mailto:phenixbb@phenix-online.org">phenixbb@phenix-online.org</a><br>
<a href="http://phenix-online.org/mailman/listinfo/phenixbb" rel="noreferrer" target="_blank">http://phenix-online.org/<wbr>mailman/listinfo/phenixbb</a><br>
Unsubscribe: <a href="mailto:phenixbb-leave@phenix-online.org">phenixbb-leave@phenix-online.<wbr>org</a><br></blockquote></div><br></div>