2
$\begingroup$

I am looking at the latest INCHI-1 software which supports molecules with 32 thousand atoms. I work with macro-molecules and want to use that to generate humongous InChIs. I've never used that INCHI-1 software before. I thought I could just throw in some SMILES and get InChI but I learned now that it only accepts MOLFILEs. I find this strange as the atom coordinates shouldn't matter when generating an InChI. I am inclined to write myself a SMILES to MOLFILE converter which just leaves the atom positions at zero, but then, I come to the problem of MOLFILE v2000 having a 999 atom limit. What is the simplest way to get atoms and bonds of 32 thousand atoms into the INCHI-1 system? Can I load an incorrect INCHI perhaps? Like I could just convert SMILES to a non-canonical INCHI. What is the way?

UPDATE: I have started trying this out. I generated a MOLFILE with all 0.0000 atom positions and INCHI-1 would correctly reproduce the atom and connection layers. My data source is actually my own InChI parser which generates an atom list and a link structure.

The problem with this approach is two-fold

  1. How do I reproduce the bond degree in the MOLFILE when all I have is atom symbol, connections, and hydrogenization from the InChI?
  2. The MOLFILE format just cannot put more than 999 atoms in because of the fixed column format having only 3 places for the atom numbers in the bond line.

If my input was SMILES I would have the bond degree at least. But the 999 atom limit of the MOLFILE seems hard.

I wonder if I should use the AuxInfo format as input? And when I tried doing that with all but the coordination "layer" of this AuxInfo format I get the error

Error 40 (no InChI; Missing atom coordinates data) inp structure #1.

Finally, I did find that there is an InChI2InChI mode and I tried that with a non-canonical connection path:

Starting with the canonical test InChI:

InChI=1S/C6H12N2O4S2/c7-3(5(9)10)1-13-14-2-4(8)6(11)12/h3-4H,1-2,7-8H2,(H,9,10)(H,11,12)

I walked the connections backwards:

InChI=1S/C6H12N2O4S2/c12-6(11)4(8)2-14-13-1-3(5(9)10)7/h3-4H,1-2,7-8H2,(H,9,10)(H,11,12)

and that created the same result as the canonical starting version (which I show directly below the output)

InChI=1S/C6H12N2O4S2/c7-3(5(9)10)1-13-14-2-4(8)6(11)12/h3-4H,1-2,7-8H2,(H,9,10)(H,11,12)
InChI=1S/C6H12N2O4S2/c7-3(5(9)10)1-13-14-2-4(8)6(11)12/h3-4H,1-2,7-8H2,(H,9,10)(H,11,12)

so this is good, I might just generate a mega-pseudo-InChI instead of a MOLFILE and use that as the input format.

Now I do another test to see if the stereo layer(s) are invariant given my backwards walk of the connections, after all, in SMILES your walking direction matters for stereo. In the following I put (1) original, (2) inverted connection table, (3) output, and (4) again original to check against the output all in one block:

InChI=1S/C6H12N2O4S2/c7-3(5(9)10)1-13-14-2-4(8)6(11)12/h3-4H,1-2,7-8H2,(H,9,10)(H,11,12)/t3-,4-/m0/s1
InChI=1S/C6H12N2O4S2/c12-6(11)4(8)2-14-13-1-3(5(9)10)7/h3-4H,1-2,7-8H2,(H,9,10)(H,11,12)/t3-,4-/m0/s1
InChI=1S/C6H12N2O4S2/c7-3(5(9)10)1-13-14-2-4(8)6(11)12/h3-4H,1-2,7-8H2,(H,9,10)(H,11,12)/t3-,4-/m0/s1
InChI=1S/C6H12N2O4S2/c7-3(5(9)10)1-13-14-2-4(8)6(11)12/h3-4H,1-2,7-8H2,(H,9,10)(H,11,12)/t3-,4-/m0/s1

and lo and behold, the stereo information is conserved. This is good.

So I might be answering my own question here, but would like the authoritative answer:

  1. MOLFILE v2000 has a 999 atom limit, syntactically there is no way to create larger MOLFILEs for input into INCHI-1
  2. the InChI2InChI mode can be used with non-canonical connection layer and it will be canonicalized. This would be the way to deal with humongous molecules.

UPDATE:

Some people were asking to see an InChI that goes toward the 32 thousand atom length. I had shown here (in a previous edit) a freshly from my InChI peptide chain condensation algorithm on the human insulin B-chain, the INCHI-1 software would take it and return another InChI which seemed to have been re-routed and normalized, but it was incorrect! There is a problem with INCHI-1 in the /InChI2InChI mode, I ran as:

inchi-1 /InChI2InChI /STDIO`:

InChI version 1, Software v. 1.06 (inchi-1 executable)
Windows 64-bit Build (MS VS 2015) of Dec 18 2020 20:44:49

[MORE UPDATE]I thought I had found out that I cannot feed it molecules with more than 1024 atoms in that mode. If I do I get a "syntax error". But that was an error on my part. There is even a flag /LargeMolecules but even with 1400 atoms now I do not trigger any syntax errors any more.[/UPDATE]

But it gets worse!

I found the INCHI-1 software does not properly re-organize incorrect InChIs. This is quite disturbing. I make a long story short (details deleted from earlier edits to this post), even if I get all the hydrogenation right, subtly and correctly sharing the remaining H in the peptide bond between the -C(=O) and the -NC(R)-, as shown in line 1 below, still INCHI-1 does not re-route the connection path correctly and gives me line 2 below while it should be line 3!

 1 InChI=1S/C5H10N2O3/c1(6)2(8)7-4(3)5(9)10/h4H,1,6H2,3H3,(H,7,8)(H,9,10)
 2 InChI=1S/C5H10N2O3/c3-4(5(9)10)7-2(8)1-6/h4H,1,6H2,3H3,(H,7,8)(H,9,10)
 3 InChI=1S/C5H10N2O3/c1-3(5(9)10)7-4(8)2-6/h3H,2,6H2,1H3,(H,7,8)(H,9,10)

So I'm back to square-1, meaning, I cannot use the INCHI-1 software feeding it any non-MOLFILE input hoping to get out a correctly normalized InChI connection layer, even if I have all the hydrogenation exactly correct.

So, my question remains: how can I use the INCHI-1 software with > 999 atoms getting it to produce a correct InChI?

I know there is this API, but it too wants atom positions. I do not have atom positions.

Improve this question
$\endgroup$
9
  • $\begingroup$ May you share / link to one of your 32k+ atoms input file? Converting many small molecules' format into an other might differ to work with few, but large ones this large. Still, why is OpenBabel (documentation) offering multiple input formats (including SMILES) to yield InChi/truncated InChi/Inchikey (entry) and APIs (e.g., to Python, C) not suitable? Or the complementary RDKit? $\endgroup$
    – Buttonwood
    Commented Mar 17, 2021 at 4:42
  • 1
    $\begingroup$ @Buttonwood, I will not say that OpenBabel or RDKit is not suitable, only that I abhor dependencies on libraries I don't use much or are way besides my main scope. I am a bit of a purist with a touch of NIH syndrome. But more objectively in this case, I am tracking Igor's innovations of INCHI quite closely, and so my focus is on his code, until such time that there is a real InChI specification (not just a user guide) which then would get me to implement my own InChI walker. Incidentally I am writing a pseudo-InChI serializer just now. 32k atoms is for creating full protein models. $\endgroup$
    – Gunther Schadow
    Commented Mar 17, 2021 at 17:29
  • 1
    $\begingroup$ PS: I'm working on a presentation for next week: cactus.nci.nih.gov/presentations/NIHInChI_2021-03/NIHInChI.html where I want to show how I "parse" a massive molecule finding the various protein chains and modifications. :) $\endgroup$
    – Gunther Schadow
    Commented Mar 17, 2021 at 17:32
  • 1
    $\begingroup$ This comment changes the context of your question quite a bit. And it is understood, you don't want to state a superficial «generally speaking, program x works good enough for me», but rely on validated benchmarks including knowledge of the «the anatomy» (and limitations) of the program. $\endgroup$
    – Buttonwood
    Commented Mar 17, 2021 at 21:23
  • 2
    $\begingroup$ You do know that for proteins things like .pdb and FASTA are used? Using smiles doesn't strike me a reasonable idea. $\endgroup$
    – Mithoron
    Commented Mar 18, 2021 at 21:55

1 Answer 1

Reset to default
2
$\begingroup$

How to do this

First, I'll address the how of this problem. Although the MOL format is limited to 999 atoms in V2000, it seems like the limit for V3000 is 999999 (for all objects)? See also this link about the MOLfile format. Anyway, I can use openbabel on 1aho :

obabel -ipdb top500H/1ahoH -omol -Otmp.mol

then with:

inchi-1 ~/Data/tmp.mol -Key -LargeMolecules

I get a ridiculously long InChI, with InChIKey=SALBUZGTRUOYKX-NQUMBTFPSA-N. Note that my copy of 1aho has hydrogen atoms, so goes over the 999 limit.

Why do this

Obviously using a line notation like SMILES or InChI for macromolecules is possible, although stretching a system designed for small molecules. I take your point that post-translational modification, non-standard amino acids and so on could make it useful.

There might be more suitable formats for macromolecules, such as "HELM: A Hierarchical Notation Language for Complex Biomolecule Structure Representation"

Canonicalisation

Of course, to be a unique identifier for a modified polypeptide, a line notation would have to be canonical. InChI are by default, of course, but will be affected by tautomers.

Another possibility would be to ask Roger and Noel, who have done work on this : https://nextmovesoftware.com/blog/2014/11/26/introducing-new-formats-for-handling-macromolecules-smiles-and-inchi/

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.