<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&#39;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">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">        </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::object, boost::python::numeric::array)</div><div>    __init__(boost::python::api::object, boost::python::tuple)</div><div>    __init__(boost::python::api::object, boost::python::list)</div><div>    __init__(boost::python::api::object, std::vector&lt;double, std::allocator&lt;double&gt; &gt;)</div><div>    __init__(boost::python::api::object, scitbx::af::const_ref&lt;std::string, scitbx::af::trivial_accessor&gt;)</div><div>    __init__(_object*, scitbx::af::shared_plain&lt;double&gt;)</div><div>    __init__(_object*, unsigned long)</div><div>    __init__(_object*, unsigned long, double)</div><div>    __init__(_object*, scitbx::af::flex_grid&lt;scitbx::af::small&lt;long, 10ul&gt; &gt;)</div><div>    __init__(_object*, scitbx::af::flex_grid&lt;scitbx::af::small&lt;long, 10ul&gt; &gt;, 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&#39;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>