Atom indexing on small molecules seems to be incorrect

[spadavec]

I have a small molecule that I'm loading into a viewer, which according to rdkit, has the following numbering scheme:

However, this is the atomMap thats reported by picking the atom:

atomMap: Jc dict: C1|C: 0 C4|C: 3 C5|C: 4 C6|C: 5 C7|C: 6 C9|C: 8 C10|C: 9 C11|C: 10 C13|C: 12 C15|C: 14 F8|F: 7 N3|N: 2 N14|N: 13 N16|N: 15 N17|N: 16 O2|O: 1 O12|O: 11

I'm getting the above via:

stage.signals.clicked.add((pp: any) => {
          const atom = pp.atom;
          const atomIndex = atom.index;
          const atomNumberDict = atom.atomMap.dict;
          console.log(atomNumberDict);

There are some pretty disparate differences between the numbering schemes; am I not going about this the right way?

[ppillot]

I don't know how you've loaded the molecule in NGL. I suspect that you might have used SDF/MOL v2000 format which does not contain atom names. When this type of file is loaded in NGL, atom names are created by combining the element name and the number of the line of the atom in the atom block of the file. To check this, you could inspect the content of the SDF file and try to find if indeed RDkit has written the atoms in a different order than the numbering displayed in the depiction.

[spadavec]

thank you @ppillot ; I am indeed locally hosting .sdf files and loading them into NGL. I looked into this right as you posted this thinking the same thing and found that the numbering/ordering in the file matches what rdkit reports (no surprise there, I guess). However, when loaded into NGL, the elementname + number is incorrect.

Here's another example file that should replicate this issue: ITX-SDEAADCF.zip

in the case you dont want to download/inspect, here are the contents:

 RDKit          3D

 17 18  0  0  0  0  0  0  0  0999 V2000
    2.8648    2.1759    1.3062 C   0  0  0  0  0  0  0  0  0  0  0  0
    2.7106    0.7329    1.7229 C   0  0  0  0  0  0  0  0  0  0  0  0
    1.6380    0.6138    2.7794 C   0  0  0  0  0  0  0  0  0  0  0  0
    2.4565   -0.1479    0.5713 C   0  0  0  0  0  0  0  0  0  0  0  0
    3.3383   -1.0778    0.1902 N   0  0  0  0  0  0  0  0  0  0  0  0
    2.7125   -1.6691   -0.9133 O   0  0  0  0  0  0  0  0  0  0  0  0
    1.5196   -1.0219   -1.0797 C   0  0  0  0  0  0  0  0  0  0  0  0
    0.7245   -1.4391   -2.0886 N   0  0  0  0  0  0  0  0  0  0  0  0
   -0.4750   -0.6501   -2.2756 C   0  0  0  0  0  0  0  0  0  0  0  0
   -1.6679   -1.3864   -1.7075 C   0  0  0  0  0  0  0  0  0  0  0  0
   -1.7802   -1.1469   -0.2172 C   0  0  0  0  0  0  0  0  0  0  0  0
   -2.5188    0.0568    0.0673 N   0  0  0  0  0  0  0  0  0  0  0  0
   -3.8757    0.1671    0.1180 C   0  0  0  0  0  0  0  0  0  0  0  0
   -4.0916    1.4825    0.4701 C   0  0  0  0  0  0  0  0  0  0  0  0
   -2.9003    2.1468    0.6487 N   0  0  0  0  0  0  0  0  0  0  0  0
   -1.9667    1.2507    0.4194 C   0  0  0  0  0  0  0  0  0  0  0  0
    1.3113   -0.0874   -0.1807 N   0  0  0  0  0  0  0  0  0  0  0  0
  1  2  1  0
  2  3  1  0
  2  4  1  0
  4  5  2  0
  5  6  1  0
  6  7  1  0
  7  8  1  0
  8  9  1  0
  9 10  1  0
 10 11  1  0
 11 12  1  0
 12 13  1  0
 13 14  2  0
 14 15  1  0
 15 16  2  0
  7 17  2  0
 17  4  1  0
 16 12  1  0
M  END
$$$$

and here is the atomMap reported for the same molecule:

C2|C: 1 C5|C: 4 C7|C: 6 C8|C: 7 C9|C: 8 C10|C: 9 C11|C: 10 C12|C: 11 C14|C: 13 C15|C: 14 C17|C: 16 N1|N: 0 N3|N: 2 N6|N: 5 N13|N: 12 N16|N: 15 O4|O: 3

The atommap seems to indicate that the numbering starts on a nitrogen, but it shouldnt. I'm guessing this is a weird issue specific to .sdf files?

[ppillot]

here is what I got with the same file in the viewer.

It corresponds to the order in the SDF file you have pasted previously

[spadavec]

@ppillot hm, peculiar. Is there any way you can share the code you used to get this result?

[ppillot]

@spadavec I did the screenshot using the label representation with the nil viewer web application