Okay, all three of these smiles strings resolve to the same inchi,
"O=[N+](C1=NC2=CC=CC=C2N=C1)[N-](=O)C1=NC2=CC=CC=C2N=C1"
"C1=CC=C2C(=C1)N=CC(=N2)N(=N(=O)C3=NC4=CC=CC=C4N=C3)=O"
"[O-][N+](c1cnc2ccccc2n1)=[N+]([O-])c3cnc4ccccc4n3"
even though to me they seem like different structures due to the specified
charges. Is this a limitation of inchi, or do I need to rethink my ideas
of what makes two chemical structures the same?
Jason Biggs
On Thu, Sep 14, 2017 at 12:38 PM, John Mayfield <john.wilkinson...@gmail.com
> wrote:
> InChI is an identifier and not a representation, you should not read
> InChIs... but we are beyond hope there so...
>
> The InChI string is correct and is the same if you roundtrip your
> preferred one with charge separated bonds and the 5 valent one.
>
> All toolkits will use the InChI library to read/write InChIs and it
> generates the representation with 5v nitrogens, cactus is either applying
> normalisation after reading or in this case (since it's the name resolved)
> doing a identifier lookup from an original SMILES used to generate this
> InChI:
>
> echo 'InChI=1S/C16H10N6O2/c23-21(15-9-17-11-5-1-3-7-13(11)19-
>> 15)22(24)16-10-18-12-6-2-4-8-14(12)20-16/h1-10H' | inchi -STDIO
>> -inChi2Struct -OutputSDF | obabel -imol -osmi
>
> c1ccc2c(c1)ncc(n2)N(=N(=O)c1cnc2ccccc2n1)=O Structure #1
>
> SDF also attached without going though Open Babel.
>
> - John
>
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
