Major bug: SMILES and radicals in Marvin 3.5.0

In Marvin 3.5.0, when I try to convert a structure with a radical into any of the SMILES formats, I get an error message saying it can't convert the structure. For example, try this one:

Code:

Marvin  11160414342D   2  1  0  0  0  0            999 V2000    -1.8750   -0.1875    0.0000 C   0  3  0  0  0  0  0  0  0  0  0  0    -1.0500   -0.1875    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0   1  2  1  0  0  0  0 M  CHG  1   1   1 M  RAD  1   2   2 M  END

The inability to convert the structure happens at the Javascript level, too, but apparently only in Explorer on a PC. The getmol("smiles") function called on the structure above generates an empty string. In EPOCH, we call the getmol("smiles") function on a submitted answer. When I submit the structure above, the error message is returned only on a PC (Explorer), not in Safari on the Mac.

I went through the Daylight documentation and found no rules for dealing with radicals. However, when I asked Daylight about it, I got this response:

Quote:

Bob, Yes you are correct C[CH2] represents the ethyl radical and is handled correctly, as such, in our software. See for example the message reported when you enter C[CH2] in the window of http://www.daylight.com/daycgi/depict. Clearly we cannot take responsibility for other vendors failure to parse the SMILES properly. However it may be that we should include an explicit example in our documentation to illustrate the fact. Thank you for pointing it out, John

So there you go. If the number of H atoms is specified but is below the expected number, the atom is a radical.





P.S. Don't feel too bad; ChemDraw doesn't translate radicals to or from SMILES properly either.

Hi Bob,

Quote:

So there you go. If the number of H atoms is specified but is below the expected number, the atom is a radical.

Good idea! We will discuss it.


Have you tried the link?


I get the following error:

Quote:

SMILES error message(s): NOTE: Atom has low valence 3 (normal 4), possible radical (dy_rmbord) C[CH2] ^^^^^

So my only problem with this solution, what if the SMILES string is erroneous?


Right now we correct it, but if we allow radicals in plain SMILES we loose this nice feature :-(


What dou you think about implementing it in cxsmiles?





Andras

I asked him about that error message, actually. He said that the message was more an alert than an error. In their internal code, Daylight deals with radicals as I suggest.





As for correcting the user's SMILES string, seems to me if the user takes the trouble to specify a subnormal number of H atoms, she has a reason for doing so.

In this case we surely implement it.


Do you think they use divalent radicals? Like: C[CH]


As far as I know divalent radicals has importence in photochemical reactions.


Do you know some rules how to determine if it is a singlet or triplet.

I don't know whether they deal with divalent radicals. You can surely contact Daylight and ask them. Since Marvin deals with divalent radicals, it seems reasonable for you to implement them the way you suggest.





There is no reliable way to determine whether a divalent radical is triplet or singlet in its ground state. Usually divalent radicals are generated as singlets, so I think you can make the singlet the default.

Thank you for your comments. We will implement it in the near future (in 2 month) like this:


Radicals until divalent will be implemented other cases will be corrected, singlet will be the default case.


We may should select which atoms can have radicals.


Probably it is easier to tell which cannot. Noble gases should be excluded.


Other suggestions?

volfi wrote:

Thank you for your comments. We will implement it in the near future (in 2 month) like this: Radicals until divalent will be implemented other cases will be corrected, singlet will be the default case. We may should select which atoms can have radicals. Probably it is easier to tell which cannot. Noble gases should be excluded. Other suggestions?

We use the following algorithm for computing the value of the radical flag (0, 1, or 2) in our program that calculates the products of structures and electron-flow arrows.

Code:

If atomnumber < 10 then valelectrons = atomnumber - 2; Elseif atomnumber < 18 then valelectrons = atomnumber - 10; Elseif atomnumber < 22 then valelectrons = atomnumber - 18; Elseif atomnumber < 30 then valelectrons = -1; Elseif atomnumber < 36 then valelectrons = atomnumber - 28; Elseif atomnumber < 40 then valelectrons = atomnumber - 36; Elseif atomnumber < 48 then valelectrons = -1; Elseif atomnumber < 54 then valelectrons = atomnumber - 46; Elseif atomnumber < 58 then valelectrons = atomnumber - 54; Elseif atomnumber < 80 then valelectrons = -1; Elseif atomnumber < 86 then valelectrons = atomnumber - 78; Elseif atomnumber < 90 then valelectrons = atomnumber - 86; Else valelectrons = -1; If atomnumber == 1 then    radicalflag = 1 - bondcount - abs(charge); Elseif valelectrons <= 0 then    radicalflag = 0;   //transition metals and noble gases don't have radical flags set Elseif valelectrons > 4 then    radicalflag = 8 - valelectrons - bondcount + charge; Elseif valelectrons == 4 then    radicalflag = 8 - valelectrons - bondcount - abs(charge); Else    radicalflag = valelectrons - bondcount - charge; EndIf If radicalflag < 0 then    radicalflag = (-radicalflag) % 2;   //% is the remainder operator Endif

Obviously, if no H's are specified, you set radical flag = 0 and let your existing code calculate the appropriate number of implicit H's.





By the way, this discussion impinges on a previous one we had about having the value of the radical flag depend on the charge and number of bonds of an atom.

We implemented this feature in SMILES import / export.


The next Marvin release will contain this feature.