Rolf, let's work on this. > I am not ready to jump for this. What code is producing this file? I'm > > guessing you are usurping the mmCIF format for your own purposes, right? > I > > think it is very clever to use _atom_site.auth_seq_id for these purposes, > > and we could consider that, though it cannot be a default to read this > data > > block, since it is not the same as CONECT, and it is not consistent with > > Jmol's standard autobonding business. > > > It is true that the example mmCIF file here is generated within Jmol for > pseudoatoms. But I tried to make it similar to the mmCIF files used by > the PDB. And as far as I have seen they use the '_struct_conn' record to > provide bonding information like they provide it in the 'CONECT' records > in the PDB format (see example below).
Except, in fact, it doesn't work that way. It seems to be a completely different set of information. For example: 1blu.pdb, with two SF4 components, shows all connectivity: CONECT 59 615 CONECT 81 616 CONECT 102 614 CONECT 133 621 CONECT 271 623 CONECT 293 624 CONECT 363 622 CONECT 392 613 CONECT 613 392 618 619 620 CONECT 614 102 617 619 620 CONECT 615 59 617 618 620 CONECT 616 81 617 618 619 CONECT 617 614 615 616 CONECT 618 613 615 616 CONECT 619 613 614 616 CONECT 620 613 614 615 CONECT 621 133 626 627 628 CONECT 622 363 625 627 628 CONECT 623 271 625 626 628 CONECT 624 293 625 626 627 CONECT 625 622 623 624 CONECT 626 621 623 624 CONECT 627 621 622 624 CONECT 628 621 622 623 but 1blu.cif shows only inter-group connections: loop_ _struct_conn.id _struct_conn.conn_type_id ... _struct_conn.pdbx_value_order metalc1 metalc ? B SF4 . FE1 ? ? ? 1_555 A CYS 53 SG ? ? A SF4 101 A CYS 53 1_555 ? ? ? ? ? ? ? 2.189 ? metalc2 metalc ? B SF4 . FE2 ? ? ? 1_555 A CYS 14 SG ? ? A SF4 101 A CYS 14 1_555 ? ? ? ? ? ? ? 2.297 ? metalc3 metalc ? B SF4 . FE3 ? ? ? 1_555 A CYS 8 SG ? ? A SF4 101 A CYS 8 1_555 ? ? ? ? ? ? ? 2.285 ? metalc4 metalc ? B SF4 . FE4 ? ? ? 1_555 A CYS 11 SG ? ? A SF4 101 A CYS 11 1_555 ? ? ? ? ? ? ? 2.195 ? metalc5 metalc ? C SF4 . FE1 ? ? ? 1_555 A CYS 18 SG ? ? A SF4 102 A CYS 18 1_555 ? ? ? ? ? ? ? 2.220 ? metalc6 metalc ? C SF4 . FE2 ? ? ? 1_555 A CYS 49 SG ? ? A SF4 102 A CYS 49 1_555 ? ? ? ? ? ? ? 2.221 ? metalc7 metalc ? C SF4 . FE3 ? ? ? 1_555 A CYS 37 SG ? ? A SF4 102 A CYS 37 1_555 ? ? ? ? ? ? ? 2.360 ? metalc8 metalc ? C SF4 . FE4 ? ? ? 1_555 A CYS 40 SG ? ? A SF4 102 A CYS 40 1_555 ? ? ? ? ? ? ? 2.335 ? Thus, the CIF version has switched to a mode of only showing connections between groups, not full hetero bonding. And the CIF will indicate odd things like covalent bonds to sodium or calcium. So that's pretty useless. > And about 80% of the PDB entries > contain 'CONECT' records. So if Jmol should still be usable consistently > as a viewer for structure database sites like the PDB or JenaLib/Jena3D > in a few months (when no PDB format files will be provided any more) it > should be able to read '_struct_conn' records as default. > > > Bob, I thought we had discussed this here in a thread on the mmCIF > format earlier this year and you agreed to it. But I seem to have > misunderstood this. > > I will contact RCSB and find out why they have dropped the CONECT bonding and also find out if our PDB links will fail. I think they will not, but I will make sure. Bob
------------------------------------------------------------------------------
_______________________________________________ Jmol-users mailing list Jmol-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jmol-users
