suggestion for changing how Marvin handles radicals

The way that Marvin denotes radicals has caused some problems for us in our calculations of products indicated by curved electron-flow arrows.





Currently, you denote radicals as being off, monovalent, or divalent (singlet, triplet, or unspecified). I think it makes much more sense simply to denote the number of unshared valence electrons any atom has. If the number is odd, it is a radical. If the number is even, it is not. If a user wants to know whether an atom is a carbene, nitrene, etc., they can calculate it: a neutral atom with two fewer bonds than usual is a "divalent radical". Atoms are flagged as having a disallowed valence status when (number of valence electrons in atomic state) – (number of bonds) – (number of unshared electrons) ? (charge).





(Of course, this scheme won't distinguish between singlet and triplet carbenes.)

Setting the number of unshared electrons certainly would make sense, but we choose the current implementation of radicals owing to compatibility reasons with the various molfile formats.

Gyuri wrote:

Setting the number of unshared electrons certainly would make sense, but we choose the current implementation of radicals owing to compatibility reasons with the various molfile formats.

I can understand why you do that. But first, you have your own XML format now, so you are free from the MOL restrictions. And second, the flag is an awkward representation of the chemical reality (the number of unshared electrons and bonds), when the chemical reality can much more easily be represented in a different way.





I should mention that the representation of lone pairs, which has also come up in this forum, would also be considerably easier to implement if the number of unshared electrons were a property of any atom.





Think about it.

You are right, we are free now to get rid of the restrictions of other drawing tools, but being compatible is still value for us. Thus, we would like to keep the existing way of setting charges and radicals.





I suppose, however, that it would be possible to provide an alternative approach by setting the number of valence electrons (or unshared valence electrons) and it would be reflected in the charge and radical values. Is that what you need?

Gyuri wrote:

You are right, we are free now to get rid of the restrictions of other drawing tools, but being compatible is still value for us. Thus, we would like to keep the existing way of setting charges and radicals. I suppose, however, that it would be possible to provide an alternative approach by setting the number of valence electrons (or unshared valence electrons) and it would be reflected in the charge and radical values. Is that what you need?

Yes, I think that would work. Make the radical flag dependent on the value of "unshared valence electrons", number of bonds, and charge. If a user changes the radical flag manually, the number of unshared valence electrons can be changed correspondingly, or vice versa. Redundant, but it keeps compatibility with previous versions. It also allows the user to set the "divalent radical" to singlet or triplet.

I don't know whether you're still considering setting up an unsharedElectrons field within MolAtom, but if you are, here is how it's calculated:

Code:

int unsharedElecs = getValenceElecs(atom)          - atom.getCharge() - atom.getImplicitHcount();       for (int j=0; j<atom.getBondCount(); j++)          unsharedElecs -= atom.getBond(j).getType();          atom.setUnsharedElecs(unsharedElecs);

And if you change unsharedElecs() for an atom, here is how the radical state changes:

Code:

int sumBondOrders = atom.getImplicitHcount();       for (int j=0; j<atom.getBondCount(); j++)          sumBondOrders +=             atom.getBond(j).getType();       int elecDeficiency = getMaxOuterElecs(atom)          - (2*sumBondOrders + atom.getUnsharedElecs());       int radState = ( (unsharedElecs[i] < elecDeficiency) ?          unsharedElecs[i] : elecDeficiency );       int ChemAxonRadState = getChemAxonRadicalConstant(radState);       atom.setRadical(ChemAxonRadState);

Auxiliary functions needed:

Code:

// returns the number of valence electrons of an atom // = column for columns 1 to 10, column - 10 for columns 11 to 18 (except He) // lanthanides & actinides = 3 + f electrons except the last column = 3    private static int getValenceElecs(MolAtom atom) {       int atno = atom.getAtno();       if (atno <= 2) return atno;  // H to He       else if (atno <= 10) return atno-2;  // Li to Ne       else if (atno <= 18) return atno-10;  // Na to Ar       else if (atno <= 28) return atno-18;  // K to Ni       else if (atno <= 36) return atno-28;  // Cu to Kr       else if (atno <= 46) return atno-36;  // Rb to Pd       else if (atno <= 54) return atno-46;  // Ag to Xe       else if (atno <= 70) return atno-54;  // Cs to Yb       else if (atno <= 78) return atno-68;  // Lu to Pt       else if (atno <= 86) return atno-78;  // Au to Rn       else if (atno <= 102) return atno-86;  // Fr to No       else return atno-100;  // Lr up    } // getValenceElecs // returns the number of electrons required to fill an atom's outer shell    private static int getMaxOuterElecs(MolAtom atom) {       int atno = atom.getAtno();       if (atno <= 2) return 2;  // H to He       else if ( (atno <= 18)  // Li to Ar          || inRange(atno, 31, 36)  // Ga to Kr          || inRange(atno, 49, 54)  // In to Xe          || inRange(atno, 81, 86) )  // Tl to Rn          return 8;  // periods 2-3 and columns 13-18       else return 18;  // periods 4+, columns 1-12    } // getMaxOuterElecs    private static int getChemAxonRadicalConstant(int electrons) {       switch (electrons) {          case 1: case -1: return MolAtom.RAD1;          case 2: return MolAtom.RAD2_SINGLET;          case 3: return MolAtom.RAD3_DOUBLET;          default: return 0;       }    } // getChemAxonRadicalConstant    private static boolean inRange(int value, int min, int max) {       if ( (value >= min) && (value <= max) ) return true; else return false;    } // inRange

Thank you for the sent code!


We will not add this to the upcoming release, since the code is already frozen. I need to discuss it with my collegues to decide that we will add it to the next version or not. I will respond you soon.

After consulting with some of my collegues we all agreed, that implementing this feature in Marvin would not be interesting for most of the users (though I understand that it would be important for you), so we will not add it in the near future. We need to focus on other, more burning development topics.


However, if other customers join this request for setting the number of unshared electrons "manually", we will reconsider our opinion.