OpenSMILES specification

This document formally defines an open specification version of the SMILES language, a typographical line notation for specifying chemical structure. It is hosted under the banner of the Blue Obelisk project, with the intent to solicit contributions and comments from the entire computational chemistry community.

SMILES was originally developed as a proprietary specification by Daylight Chemical Information Systems Since the introduction of SMILES in the late 1980’s, it has become widely accepted as a defacto standard for exchange of molecular structures. Many independent SMILES software packages have been written in C, C++, Java, Python, LISP, and probably even FORTRAN.

At this point in the history of SMILES, it is appropriate for the chemistry community to develop a new, non-proprietary specification for the SMILES language. Daylight’s SMILES Theory Manual has long been the "gold standard" for the SMILES language, but as a proprietary specification, it limits the universal adoption of SMILES, and has no mechanism for contributions from the chemistry community. We salute Daylight for their past contributions, and the excellent SMILES documentation they provided free of charge for the past two decades.

This document is intended for developers designing or improving a SMILES parser or writer. Readers are expected to be acquainted with SMILES. Due to the formality of this document, it is not a good tutorial for those trying to learn SMILES. This document is written with precision as the primary goal; readability is secondary.

Before defining the SMILES language, it is important to state the physical model on which it is based: the valence model of chemistry, which uses a mathematician’s graph to represent a molecule. In a chemical graph, the nodes are atoms, and the edges are semi-rigid bonds that can be single, double, or triple according to the rules of valence bond theory.

This simple mental model has little resemblance to the underlying quantum-mechanical reality of electrons, protons and neutrons, yet it has proved to be a remarkably useful approximation of how atoms behave in close proximity to one another. However, the valence model is an imperfect representation of molecular structure, and the SMILES language inherits these imperfections. Chemical bonds are often tautomeric, aromatic or otherwise fractional rather than neat integer multiples. Delocalized bonds, bond-centered bonds, hydrogen bonds and various other inter-atom forces that are well characterized by a quantum-mechanics description simply don’t fit into the valence model.

McLeod and Peters' quip captures the deficiencies of SMILES well: if you can’t build a molecule from a modeling kit, the deficiencies of SMILES and other connection-table formats become apparent.

This SMILES specification is divided into two distinct parts: A syntactic specification specifies how the atoms, bonds, parentheses, digits and so forth are represented, and a semantic specification that describes how those symbols are interpreted as a sensible molecule. For example, the syntax specifies how ring closures are written, but the semantics require that they come in pairs. Likewise, the syntax specifies how atomic elements are written, but the semantics determines whether a particular ring system is actually aromatic.

For this specification, the syntax and semantics are explained separately; in practice, the syntax and semantics are usually mixed together in the code that implements a SMILES parser. This chapter is only concerned with syntax.

Atoms that are adjacent in a SMILES string are assumed to be joined by a single or aromatic bond (see Aromaticity). For example:

Double, triple and quadruple bonds are represented by '=', '#', and '$' respectively:

A single bond can be explicitely represented with '-', but it is rarely necessary.

Note: The remaining bond symbols, ':\/', are discussed in later sections.

An atom with three or more bonds is called a branched atom, and is represented using parentheses.

Branches can be nested or "stacked" to any depth:

The SMILES branch/chain rules allow nested parenthetical expressions (branches) to an arbitrary depth. For example, the following SMILES, though peculiar, is legal:

In a SMILES string such as "C1CCCCC1", the first occurrence of a ring-closure number (an "rnum") creates an "open bond" to the atom that precedes the ring-closure number (the "rnum"). When that same rnum is encountered later in the string, a bond is made between the two atoms, which typically forms a cyclic structure.

If a bond symbol is present between the atom and rnum, it can be present on either or both bonded atoms. However, if it appears on both bonded atoms, the two bond symbols must be the same.

Ring closures must be matched pairs in a SMILES string, for example, C1CCC is not a valid SMILES.

It is permissible to re-use ring-closure numbers. Once a particular number has been encountered twice, that number is available again for subsequent ring closures.

Note that the ring number zero is valid, for example cyclohexane can be written C0CCCCC0.

Two-digit ring numbers are permitted, but must be preceded by the percent '%' symbol, such as C%25CCCCC%25 for cyclohexane. Three-digit numbers and larger are never permitted. However, note that three digits are not invalid; for example, C%123 is the same as C3%12, that is, an atom with two rnum specifications.

The digit(s) representing a ring-closure are interpreted as a number, not a symbol, and two rnums match if their numbers match. Thus, C1CCCCC%01 is a valid SMILES and is the same as C1CCCCC1. Likewise, C%00CCCCC%00 is a valid SMILES.

A single atom can have several ring-closure numbers, such as this spiro atom:

Two atoms cannot be joined by more than one bond, and an atom cannot be bonded to itself. For example, the following are not allowed:

Hydrogens in a SMILES can be represented in three different ways:

All three forms are equivalent. However, some situations require that one form must be used:

A hydrogen that meets one of the following criteria must be represented as an explicit atom:

It is permissible to use a mixture of an atom h-count and explicit hydrogen. In such a case, the atom’s hydrogen count is the sum of the atomic h-count property and the number of attached hydrogens. For example:

The dot '.' symbol (also called a "dot bond") is legal most places where a bond symbol would occur, but indicates that the atoms are not bonded. The most common use of the dot-bond symbol is to represent disconnected and ionic compounds.

The dot can appear most places that a bond symbol is allowed, for example, the phenol example above can also be written:

The second example above is an odd, but legal, use of parentheses and the dot bond, since the syntax allows a dot most places a regular bond could appear (the exception is that a dot can’t appear before a ring-closure digit).

Although dot-bonds are commonly used to represent compounds with disconnected parts, a dot-bond does not in itself mean that there are disconnected parts in the compound. See the following section regarding ring digits for some examples that illustrate this.

The dot bond cannot be used in front of a ring-closure digit. For example, C.1CCCCC.1 is illegal.

A SMILES string is terminated by a whitespace terminator character (space, tab, newline, carriage-return), or by the end of the string.

Other data or information, such as a name, properties, registration number, etc., may follow the SMILES on a line after the whitespace character. SMILES parsers will ignore this data, although applications that use the SMILES parser will often make use of it.

OpenSMILES is designed to facilitate exchange of chemical information. To achieve that goal, it SMILES parsers should impose as few limits as possible on the language.

There is no formal limit to the length of a SMILES string; SMILES of over 1 million characters have been assembled for various purposes. There is no requirement that a SMILES parser must be able to parse these exceptionally long SMILES, but as a guideline, all implementations of SMILES parsers should, at a minimum, accept and correctly parse SMILES strings of 100,000 characters. If a SMILES parser encounters a string that is too long to parse, it should generate a relevant error message.

A SMILES parser should accept at least four digits for the atom class, and the values 0 to 9999.

There is no formal limit to the number of rings a molecule can contain. There are only 100 ring-closure numbers, but since numbers can be reused, a molecule can potentially have more than 100 rings. SMILES parsers should accept and correctly parse molecules with at least 1000 rings; it is preferable to place no limits on the number of rings a molecule can contain.

Branches (parentheses) can be nested to an arbitrary depth. Some SMILES strings in standard databases contain over 30 levels of branches, and much deeper nesting is possible. A general purpose parser must handle at least 100 levels; it is preferable to place no limits on nesting depth for parentheses.

There is no formal limit on the number of bonds an atom can have. SMILES parsers should allow at least ten bonds to each atom; it is preferable to place no limits on the number of bonds to each atom.

There is no limit to the number of "dot-disconnected" fragments in a SMILES. A SMILES of 100,000 atoms could in principle contain no bonds at all; SMILES parsers should place no limits on the number of fragments allowed (except that it is limited to the number of atoms the parser can manage).

Programmers are strongly encouraged to provide detailed and clear error messages. If possible, the error message should show exactly which character or "phrase" of the SMILES string triggered the error message.

A wide variety of SMILES strings are acceptable as input. For example, all of the following represent ethanol:

However, it is desirable to write SMILES in more standard forms; the first two forms above are preferred by most chemists, and require fewer bytes to store on a computer. Several levels of normalization of SMILES are recommended for systems that generate SMILES strings. Although these are not mandatory in any sense, they should be considered guidelines for software engineers creating SMILES systems.

The simplest "normalization" is no normalization. SMILES can be written in any form whatsoever, as long as they meet the rules for SMILES. Some examples of systems that might produce un-normalized SMILES are:

The "standard form" of a SMILES is designed to produce a compact SMILES, and one that is human readable (for smaller molecules).

In addition, a normalized SMILES has the important property that it matches itself as a SMARTS string. This is a very important feature of normalized SMILES in cheminformatics systems.

Note: In the example below, the "Wrong" SMILES examples are all valid SMILES, but are "wrong" in the sense that they are not the preferred form for standard normalization.

A Canonical SMILES is one that follows the Standard Form above, and additionally, always writes the atoms and bonds of any particular molecule in the exact same order, regardless of the source of the molecule or its history in the computer. Here are a few examples of Canonical versus non-Canonical SMILES:

The primary use of Canonical SMILES is in cheminformatics systems. A molecule’s structure, when expressed as a canonical SMILES, will always yield the same SMILES string, which allows a chemical database system to:

Canonical SMILES should not be considered a universal, global identifier (such as a permanent name that spans the WWW). Two systems that produces a canonical SMILES may use different rules in their code, or the same system may be improved or have bugs fixed as time passes, thus changing the SMILES it produces. A Canonical SMILES is primarily useful in a single database, or a system of related databases or information, in which all molecules were created using a single canonicalizer.

The rules (algorithms) by which the canonical ordering of the atoms in a SMILES are generated are quite complex, and beyond the scope of this document. There are many chemistry and mathematical graph-theory papers describing the canonical labeling of a graph, and writing a canonical SMILES string. See the Appendix for further information.

Those considering Canonical SMILES for a database system should also investigate InChI, a canonical naming system for chemicals that is an approved IUPAC naming convention.

SMILES file consists of zero or more SMILES strings, one per line, optionally followed by at least one whitespace character (space or tab), and other data. There can be no leading whitespace before the SMILES string on a line. The optional whitespace character and data that follows it are not part of the SMILES specification, and interpretation of this data is up to applications that use the SMILES file. Each line of the file is terminated by either a singe LF character, or by a CR/LF pair of characters (commonly called the "Unix" and "Windows" line terminators, respectively). A SMILES parser must accept either line terminator. A blank line in the SMILES file, or a line that begins with a whitespace character, should be completely ignored by a SMILES parser.

It is an unfortunately common misconception that a Canonical SMILES does not contain stereochemistry (Minkiewicz et al. 2017) or alternatively that all SMILES must be canonical (Sykora and Leahy, 2008). SMILES flavors as described by Daylight are summarised below.

These terms can be confusing and should be avoided due to conflicting definitions between vendors and toolkits. For example ChemAxon use the term Isomeric SMILES to mean a non-canonical SMILES with stereochemistry and isotopic information specified (see SMILES, ChemAxon Documentation). OEChem use the term Isomeric SMILES to mean a canonical SMILES with stereochemistry and isotopic information specified (see OECreateIsoSmiString), Absolute SMILES to mean a non-canonical SMILES with stereochemistry and isotopic information specified (see OECreateAbsSmiString), and Canonical SMILES to mean a canonical SMILES without stereochemistry and isotopic information specified (see OECreateCanSmiString).

In general the properties encoded in a SMILES can be chosen by a program to suit a particular purpose. You may have the option to independently include or omit stereochemistry, isotopes, or atom map/class in a generated SMILES. When referencing a particular SMILES flavor confusion can be avoided by including the toolkit, version, and options used.

Daylight proposed, and OpenEye actually implemented, an extension that specifies bonds to external R-groups. An external R-group is specified using ampersand '&' followed by a ring-closure specification (either a digit, or '%' and two digits). However, unlike ring-closures, the bond is to an external, unspecified R-group. Example: n1c(&1)c(&2)cccc1 - 2,3-substituted pyridine.

Daylight (Weininger) proposed, but never implemented, an extension for crystals and polymers. Daylight also used the ampersand '&' character, (which may conflict with the R-group proposal, above), but with the added rule that if a number appears more than once, it creates a repeating unit.

The directional '/' and '\' marks for cis/trans bonds seem simple on the surface but are problematic for complex systems. The issue is that in conjugated systems one directional bond can be used in defining the configuration of two double bonds. When assigning the directional bonds the existing labels must be considered or rewritten. In a long series of conjugated double bonds, changing the configuration of one bond can require rewriting dozens of bond symbols.

More importantly, there is a theoretical flaw with the use of '/' and '\'. It is possible to write valid SMILES for the molecule cyclooctatetraene by alternating directional assignments for the cis configurations. However, as shown below attempting to change one configuration is not possible. Reassigning the directional labels for adjacent double bonds will not work as it reassignment propagates around the ring and the conflict is not resolved.

Including directional labels to explicit hydrogen atoms is a possible resolution but does not follow standard-form and complicates the assignment procedure.

The proposed syntax for double bond configurations uses the '@' and '@@' atom-based specification. For example:

Interpretation of '@' and '@@' follows the tetrahedral convention: The atoms, as encountered in the SMILES string, are either in anticlockwise '@' or clockwise '@@' order as viewed on the page. Since cis/trans configurations are planar, they can also be "viewed from underneath the page", which results in the two valid SMILES shown for each compound, above.

As with the other atom-bases specifications one must consider the relative position of implicit atoms. It is not always true that a trans form has opposite "clock-ness" ('@','@@' or '@@','@'), and the cis form has the same "clock-ness" ('@','@' or '@@','@@').

Atom-based '@' and '@@' for the stereo-specification of double bonds does not suffer from the theoretical flaw illustrated with cyclooctatetraene. The assignments are not-shared and adjacent configurations do not need to be considered. This is more flexible and and simplifies generation of canonical SMILES.

Note that the first stereo-specification carbon must be represented as '@' since the '1' follows the H, whereas the rest of the carbons use '@@' to characterize the cis configuration of each bond. Since this is a specification on the atom, rather than the single bond, no conflict arises at the ring-closure bond.

This section needs considerable work. The following text is courtesy Chris Morley, who commented: "I guess the last paragraph doesn’t look too good in a formal specification. There are two reasons for the frailty: lack of proof that the radical and aromatic uses can always be unambigous (I doubt anybody has tried); and a known deficiency in the parser." However, it is a good starting point…

A single lowercase symbol is interpreted as a radical center. CCc is an alternative to CC[CH2] and is the 1-propyl radical; CcC or C[CH]C is the 2-propyl radical, Co is the methoxy radical. An odd number of adjacent lowercase symbols is a delocalized conjugated radical. So Cccccc is CC=CC=C[CH2] or CC=C[CH]C=C or C[CH]C=CC=C Lowercase 'c' or 'n' can be used in a ring: C1cCCCC1 is the cyclohexyl radical.

The use of the non-aromatic lowercase symbol is a shorted form with improved intelligibility that allows the use of implicit hydrogen in radicals. However it is intended only for simple unambiguous molecules and is not reliable when combined with aromatic atoms.

An interesting extension that specifies conformational information via bond dihedral angles and bond lengths was proposed by McLeod and Peters:

Blue Obelisk

http://blueobelisk.sourceforge.net/

Daylight

http://www.daylight.com/dayhtml/doc/theory/theory.smiles.html

The most-referenced definition of SMILES on the web.

http://www.daylight.com/meetings/mug01/Sayle/m4xbondage.html

Article by Roger Sayle about converting PDB files to SMILES with thorough treatment of aromaticity.

OpenEye

http://www.eyesopen.com/docs/html/pyprog/TheSMILESLineNotation.html

http://www.eyesopen.com/docs/html/pyprog/DaylightSMILES.html

OpenBabel

http://openbabel.sourceforge.net/wiki/Radicals_and_SMILES_extensions

http://openbabel.sourceforge.net/wiki/SMILES

Wikipedia

http://en.wikipedia.org/wiki/Simplified_molecular_input_line_entry_specification

OpenBabel

http://openbabel.sourceforge.net/wiki/Main_Page

The Chemistry Development Kit

http://cdk.sourceforge.net/

Marvin

http://www.chemaxon.com/marvin/doc/user/smiles-doc.html

RDKit

http://www.rdkit.org/

Frowns

http://frowns.sourceforge.net/frowns.html

PerlMol.org

http://search.cpan.org/\~itub/Chemistry-File-SMILES-0.45/SMILES.pm

InChI

http://www.iupac.org/inchi/

http://inchi.info/

http://en.wikipedia.org/wiki/International_Chemical_Identifier